¿Es rentable una migración desde cero?

Uno de los impulsos más difíciles de reprimir para un programador es el de ver un código antiguo, de esos que los años han ido degradando, y no caer en la tentación de rehacer esa funcionalidad que se nota que tiene ñapa sobre ñapa, que se hace de manera ineficiente, que tiene cincuenta mil ifs anidados…

Por otra parte, cada cierto tiempo, las empresas se plantean realizar migraciones de aplicaciones antiguas a una tecnología más nueva. Los motivos esgrimidos suelen ser aprovechar una infraestructura que ha ido mejorando con el paso del tiempo, que puede soportar un mayor número de usuarios, o mayor carga de trabajo.

Sin embargo, el software de dichas empresas puede no haber crecido a la par, por ejemplo porque cuando se desarrolló la aplicación no había esas necesidades, y no se incluyeron como requisitos no funcionales.

Ese es el momento en el que, armados con todas las herramientas estupendas que tenemos a día de hoy, te encuentras con la “fácil” tarea de realizar la migración. Y ya que estamos, como hacer esa migración es “tan sencillo”, pues ya aprovechamos y tenemos que incluir cierta funcionalidad que no tenía la aplicación original. Como todos sabemos, una migración es algo que “no produce valor añadido” – dicen – y claro, puede tener un cierto coste que, elevado o no, hay que justificar. Y de ahí el hecho de meterle “algo nuevo”.

¿Quién no se ha encontrado con una situación así?

Tras realizar la migración, el resultado habitual, y que sorprende a muchos clientes, es el siguiente:

  • La aplicación migrada suele tener más bugs que la original. Normalmente suele ser porque ese código tan feo suele cubrir los cincuenta millones de casos especiales que se presentan durante el proceso que cubre, y al que nadie hace caso en el momento de plantear la nueva solución. Generalmente, no es posible bajar al nivel del código para todo el sistema antiguo cuando se diseña el nuevo.
  • El rendimiento de la nueva aplicación suele ser menor. Esto pasa más a menudo de lo que pudiera parecer, por ejemplo cuando se migra una aplicación en entorno host (cobol) a tecnologías actuales (Java – .NET). Cierto, la tecnología moderna te proporciona mucha más funcionalidad de base, pero a un cierto precio. Acelera el desarrollo, pero no necesariamente el rendimiento.

De ahí que surja la pregunta: ¿realmente es rentable hacer una migración de una aplicación desde cero?

Mi opinión es que depende. Hay situaciones en las que puede interesar migrar. Pero en la mayoría de los casos, puede ser interesante pensar en la reutilización de ese sistema, por ejemplo aplicando una arquitectura orientada a servicios. La nueva funcionalidad se puede desarrollar con otra tecnología más actual, y ciertas partes del sistema antiguo se pueden ir migrando paulatinamente.

Y vosotros, ¿qué opináis?

P.D.: Al hilo, un artículo muy interesante.

Publicando aplicaciones ClickOnce en web (sin IIS)

Bueno, bueno, bueno…


En un proyecto en el que se querían ahorrar unas pelillas unos eurillos (esa cabeza…) en licencias (y gastarse muchas muchos más en gente de sistemas, supongo…) me pidieron evaluar la posibilidad de crear una aplicación que se pudiese actualizar automáticamente, de forma sencilla. Por mi deformación profesional, mi cabeza pensó directamente en ClickOnce. Claro, si publicar con ClickOnce está chupado, y cada vez que se publica una nueva versión, la aplicación se puede actualizar automáticamente! (depende de cómo lo configures, claro…).


Pero luego me dí cuenta de un pequeño problema. Para poder tener esa aplicación disponible necesito un IIS para que las aplicaciones puedan comprobar si hay una nueva versión… O no?


Pues no.


Empecé a pensar un poco sobre cómo debería funcionar ClickOnce. El cliente se descarga un fichero .application desde una URL, que no es más que un fichero XML firmado que le indica, entre otras cosas, qué manifiesto de aplicación es el que tiene que procesar para obtener los ficheros de la aplicación actual. Así que pide al servidor web dicho fichero (un .manifest). Este fichero vuelve a ser un XML firmado donde aparecen una lista de ficheros etiquetados, con el hash de cada fichero.


Para cada fichero, el cliente comprueba si ya tiene el fichero (en el caso en el que se haya instalado otra versión previamente). Si lo tiene calcula el hash del fichero en local, y si coincide con el que le indica el manifiesto, no se lo descarga. Si difiere o no lo tiene, le pide el fichero al servidor, lo descarga, calcula el hash del fichero, y si coincide con el que indica el manifiesto continua con el proceso (y si no coincide, no deja continuar la instalación). Por lo tanto… ¿cuál es el papel del servidor en todo este trajín? No es más que un repositorio de ficheros. El cliente es el que realmente realiza todo el trabajo y le va pidiendo los ficheros que necesita para instalar o actualizar la aplicación.


Por lo tanto… Esto debería funcionar con cualquier otro servidor web… ¿O no?. Decidí hacer una prueba rápida con un Apache. Coloqué los resultados de una publicación en un directorio virtual, y abriendo un Internet Explorer le indiqué la URL del fichero .application. Y claro, no funcionó. No funcionó porque el Apache no tenía los tipos mime configurados correctamente. Es decir, para que el Internet Explorer sepa cómo tiene que procesar el fichero .application, es necesario que el servidor web le indique de qué tipo es el fichero que le está enviando. Es como cuando queremos volcar un PDF directamente por el stream de salida del objeto response, que tenemos que poner las cabeceras apropiadas.


Así que, creamos un fichero de texto con el nombre .htaccess, que contenga las siguientes líneas:


AddType application/x-ms-application application
AddType application/x-ms-manifest manifest

AddType application/octet-stream deploy


Y listo! Funciona de maravilla!


Por cierto… Sobre cómo solucionar problemas de ClickOnce, podéis ver más información aquí.


 


Saludos!


P.D.: Muchas gracias a Daniel Celemín (Lord Fred) por la estupenda caricatura 🙂

ISV Tour – Madrid

Muy buenas!


Hace mucho, mucho tiempo, en una galaxia muy lejana… Esto… Bueno, que hace demasiado tiempo desde mi último post. Demasiados cambios y muy poco tiempo para contarlos. Pero vamos a lo que vamos…


Ayer tuve el placer de asistir al Innovation Days en Madrid, donde José Murillo, Isabel Gómez, César de la Torre, Daniel López, Miguel Ángel Ramos (en sustitución de Alejandro Mezcua) y Unai Zorrilla nos estuvieron mostrando las novedades que vamos a poder disfrutar en breve, (bien sea con Longhorn, Orcas o Silverlight), además de poder ver un poco de ASP.NET AJAX y una interesante charla sobre SaaS.


Las charlas, como siempre, me dejaron con ganas de más. Y es que sólo un día para tratar sobre todos estos temas es demasiado poco… Pero en fin, que te despiertan el gusanillo para cacharrear.


Saludos!

Entrada rápida…

¡Hola a todos!

 Estoy en proceso de mudanza. Me he cambiado de casa (aún de alquiler, pero todo llegará…) y en la casa nueva no tengo internet, con lo que me es difícil hacer las cosas habituales (es decir, actualizar este blog y el de historias de un consultor).

Aun así, estoy aprovechando un poco el tiempo leyéndome el libro CLR via C#, que me ha llegado de Amazon hace bien poquito, junto con otro libro menos conocido, el Programming Challenges de Steven S. Skiena y Miguel A. Revilla. Muy recomendable para repasar conceptos de estructuras de datos, y aprender a pensar un poco más al estilo de Programancia101.

Aprovechad ahora los que estéis en zona Euro, que como el Euro está fuerte, los libros en Amazon salen tirados!!! (los dos por poco más de 60€) 

Saludos!!!

Desarrollo de aplicaciones ASP.NET 2.0 en tres capas

Bajo la apariencia de una página muy sencillita, en el MSDN tenemos disponible una serie de tutoriales bastante completos sobre cómo realizar aplicaciones en tres capas utilizando ASP.NET 2.0.

Elige tu sabor favorito (C# o VB.NET), y prepárate para aprender en 17 tutoriales cómo organizar una aplicación como dios manda.

Saludos!

¡Me lo estoy pasando pipa en casa! (con C# 2005 Express)

Hola a todos,


Sigo con mis proyectos en casa, para el desarrollo de un juego (y de varias herramientas). En http://cezgs.computeremuzone.com/ estamos desarrollando cositas (top secret hasta que se publiquen, sorry), y alguna vez desarrollo alguna herramienta interna.


Ahora mismo estoy enfrascado con un tracker que permita componer melodías para ordenadores de 8 bits. De momento está enfocado al chip AY que traían los CPC (todos) y Spectrum de 128kb.


Así que buscando por la red, encontré una librería que emulaba el comportamiento de dicho chip, escrita en C. En Windows no compilaba (hasta que añadí un #define en un fichero .h), y cuando lo tuve funcionando, la migré a C#.


La verdad es que mientras la migraba me sorprendí de lo sencillo que era. Y podéis descargar el código fuente de dicho emulador, en C#, haciendo click aquí.


Saludos!

Mis experiencias con Visual C++ 2005 Express

Hola a todos!

Desde hace bastante tiempo estoy desarrollando un juego en PC usando C++ y OpenGL. (¡No, no me tiréis piedras, no usar DirectX tiene una explicación!). Así que este fin de semana, después de desesperarme con el Dev-CPP, decidí cambiarme y usar el Visual C++ 2005 Express.

La razón de no usar DirectX es que para dominar el mundo conseguir la mayor distribución posible necesito que el juego sea multiplataforma. De ahí que use OpenGL, SDL y C++. 😛

Ya tenía experiencia con el Visual C++ 6 y con el Visual C++ 2003, así que sabía que lo que me iba a encontrar era conocido, y probablemente podría aumentar mi productividad.

También tenía algunas dudas sobre si hacer el cambio o no, sobre todo después de leer los posts de Rafael Ontivero, pero como este proyecto es propio, consideré que no corría riesgos por probarlo.

A la hora de configurar el entorno de desarrollo, todo ha ido como la seda. Directorios para includes, librerías, etc… Estupendamente. Terreno conocido. 🙂

Hay un par de cosas que no me han gustado de esta versión:

  • A la hora de compilar, siempre genera la versión Release.
  • Cuando pulsas F5, siempre genera la versión Debug.
  • No he visto forma humana de hacer refactoring.
  • El Intellisense funciona cuando quiere, y sólo sobre lo que hubiese ya compilado al cargar el proyecto. Posteriores compilaciones añadiendo métodos, propiedades, etc, etc, no hacen que se refresque el Intellisense (o eso me ha parecido).

Si lo pienso fríamente, tiene sentido. Pero no me deja elegir. El combo para elegir la configuración de generación de assemblies está deshabilitado, y la verdad es que no se si está capado para la versión Express (en cuyo caso, sería mejor que no apareciese en absoluto) o que soy un zote y no he encontrado aún la forma de habilitarlo (esto será lo más probable…)

En cuanto al rendimiento de la aplicación, no he notado mejora alguna, pero tampoco pérdida alguna… Teniendo en cuenta que el trabajo duro lo hace OpenGL, es lo razonable 😉

Pero claro, el poder disponer de una herramienta como ésta, y gratuita, es algo muy, muy interesante. A aquellos frikis como yo que quieran usar C++ para proyectos personales, se lo recomiendo encarecidamente. Pero sólo en el caso de que sean aplicaciones no .NET, ya que la productividad de C# sigue estando a años luz que la de C++ (al menos para mí).

Saludos!

Cómo evitar la limitación de anchura en los formularios Windows (o poner la tuya propia)

En el blog de Metaemotion hay un artículo interesante (en castellano) en el que se detalla cómo se puede eliminar la restricción de tamaño mínimo que tienen impuestas por defecto las ventanas de Windows.

Lo que no se comenta en ese artículo es que podemos aprovechar esa misma técnica para cambiar la restricción de tamaño mínimo cuando esta esté entre 0 y 112 píxeles (para el resto de tamaños se puede usar la propiedad MinimumSize de la clase System.Windows.Forms.Form).

La lectura es más que recomendable 😉

Saludos!

Creando un sistema de reglas sencillo, pero flexible (IA)

Hola!

Curioseando un poco por la red, he encontrado un artículo muy interesante en #flipcode, en el que el autor comenta cómo se puede crear un sistema de reglas utilizando .NET que tome decisiones basándose en una máquina de estados.

Realmente esto no es novedoso, pero me ha llamado la atención el sistema tan sencillo que ha creado el autor para componer reglas básicas (lo que en el artículo llama primitivas).

Así que si tenéis que hacer una máquina de estados, os recomiendo que lo peguéis una ojeada.

Saludos!

UPDATE: Obviamente, esto no os será interesante si estáis utilizando Workflow Foundation… Pero por desgracia no todo el mundo puede usar .NET 3.0 😉

Invocando páginas ASP.NET con procesos pesados y no morir en el intento (y II)

A petición de espinete escribo una segunda parte del artículo, en el que adjunto el código fuente de ejemplo con lo que se proponía en el artículo anterior.

En el código adjunto se pueden ver las siguientes clases:

  • Trabajador: Esta clase es la que tiene implementado el proceso pesado. En nuestro caso, simplemente irá desde un número especificado como mínimo hasta el máximo, esperando un segundo en cada iteración.
  • GestionTrabajadores: Esta clase es el singleton al que se refiere el artículo anterior. Se encarga de gestionar una tabla hash en la que las instancias de la clase Trabajador se identifican mediante un Guid.

Además, podemos ver que hay tres páginas en el proyecto Web:

  • Inicial.aspx: En esta página se crea una instancia de la clase Trabajador, se la inicializa, y se la añade a la clase GestionTrabajadores, tras haber creado un Guid para identificarla. Posteriormente se reenvía al usuario a la siguiente página, pasando el Guid de la petición actual.
  • EnProceso.aspx: En esta página se muestra el progreso de la petición actual. Si se detecta que la petición ha finalizado, se reenvía al usuario a la siguiente página.
  • Terminado.aspx: En esta página simplemente se muestra un mensaje que indica que el procesamiento ha finalizado.

Obviamente, las mejoras que se le pueden hacer a este ejemplo son innumerables, pero aquí dejo un par de ideas, a ver si alguien se anima y las realiza, aportándolas para la comunidad:

  • La página Inicial.aspx, en vez de notificar el GUID de la petición, podría enviarnos a la página EnProceso.aspx, y en esta página que se muestren los diferentes trabajos que hay en curso. Para ello bastaría con proporcionar un enumerador a la clase GestionTrabajadores para recorrer la tabla hash.
  • La página EnProceso.aspx podría utilizar AJAX para no tener que refrescarse cada dos segundos.

Bueno, pues esto es todo por hoy.

Saludos!