Category Archives: Desarrollo de Software

Sistemas de Mensajes Encolados (MQ)

Hace poco me he encontrado con un problema. Tengo un entramado de servidores y comunicaciones entre cada uno de ellos. Cada servidor puede notificar, ya sea vía SOAP, HTTP, XMPP o mediante cualquier otro protocolo, un evento o una información a otro servidor del entramado, con lo que cada servidor se configura de una forma específica, con una serie de nombres de dominio o IPs.

El problema viene al querer aplicar escalabilidad al proyecto. Cuando no solo hay un equipo implicado, sino que existen dos o tres, los cuales hay que configurar bajo ciertas circunstancias.

Lo primero que pensé, es que, si le puedo notificar a la red de que sucede un evento en concreto, ya sea a una sola máquina o conjunto definido de estas (pero para todos los equipos la misma configuración), facilitaría la puesta en producción. Con lo que me puse a buscar y encontré MQ, message queue.

El encolado de mensajes

La comunicación de los equipos informáticos se basa en mensajes, en eventos, que deben de poder transmitirse de unos a otros cuando sucedan (si es que se quiere tener la máxima fiabilidad en la información que se trata).

Una forma es comunicar directamente al implicado, lo cual resulta un poco tedioso si los implicados son muchos y muy distintos.

Otra forma es mediante un sistema JMS o un MQ, como RabbitMQ.

El encolado de mensajes es un sistema que permite que un elemento perteneciente a un sistema de información, pueda comunicar un estado, evento o mensaje informativo o imperativo a otro conjunto de elementos dentro del sistema, para que interactúe con él.

Por ejemplo, si tenemos un servidor web, una interfaz, que controla un conjunto de máquinas encargadas realizar llamadas salientes, rastrear páginas de la web para almacenar información para un buscador o similar, y la interfaz quiere enviar parámetros nuevos de configuración a estas, puede hacerlo mediante el envío de un mensaje generalizado a ese conjunto de máquinas, y estas máquinas recibirán el mensaje en el momento que lo soliciten.

Esta utilidad es igualmente buena para cuando una interfaz web, por ejemplo de un estudio fotográfico, carga imágenes desde la web, las retoca con algún tipo de efecto, ajuste, etc. y más adelante permite su descarga. El sistema web puede enviar el evento al sistema de retocado de que hay una imagen disponible, y cuando la imagen ya está disponible, el sistema de retocado puede enviar otro mensaje de vuelta diciendo que ya está.

Quizás esto último podría hacerse mejor con una base de datos, pero con el sistema de mensajería, se eliminan los datos en el momento que ya no se necesitan, mientras que con la base de datos, esos datos podrían permanecer ahí de forma indeterminada.

Conclusiones

Los sistemas de encolado de mensajes tienen su utilidad, sobre todo, en sistemas formados por varias máquinas, con roles bien definidos y en las que se quiere afinar lo que son las conexiones y comunicaciones entre las máquinas.

Cuánto cuesta un Proyecto de Software

Hoy ya hace unas semanas que en la empresa en la que trabajo se ha comenzado un movimiento positivo en favor de medir lo que cuesta realizar desarrollos de software, dentro del departamento de desarrollo, lo cual es positivo desde el punto de vista del desarrollador, del programador y de los directivos.

Hay que tener siempre presente que, cuando se realiza un trabajo, ya sea el que sea, si lo realiza una persona ajena, no de la empresa, se paga una factura por sus servicios, en los que viene detallado, normalmente, la mano de obra, que suele cobrarse en factor de tiempo empleado.

El coste asociado de emplear a una persona que está en nómina, dentro de la propia empresa, puede ser menor, pero no cero. Si un empleado cobra en bruto unos 2000 euros mensuales y le mandamos hacer un trabajo para lo cual gasta todo un mes, es de lógica pensar, que ese trabajo me ha costado esos 2000 euros, ya que es lo que ha hecho el empleado. Si el proyecto al final solo hace ingresar a la empresa 200 euros, la empresa ha perdido con ese desarrollo 1800 euros.

En el caso de que un proyecto se desarrolle en dos semanas de ese trabajador, por redondear, damos que son 1000 euros el coste y se consiguen 1200 euros. La empresa ha conseguido con su labor 200 euros… pero si el desarrollo ha sido deficiente, por el poco tiempo empleado, y el programador tiene que ir invirtiendo horas, que al final resultan ser días (en suma) y llegan a ser otras dos semanas, tendremos que esos 200 euros se convierten en 800 euros de pérdidas.

El las metodologías ágiles se hace hincapié a dar valor, es decir, realizar el desarrollo por iteraciones, siempre haciendo lo que más valor dé al cliente. Por ejemplo, si tenemos 10 requisitos en un proyecto, impuestos por el cliente, pero los más importantes son los 2 primeros, podemos negociar con el cliente el hacer esos dos primeros, valorarlos con el tiempo que toma el realizarlos y, en caso de querer el resto de requisitos, o algunos más, volver a realizar otra petición.

¿Qué conseguimos con esto?

  • Que el cliente pida lo que necesita, únicamente.
  • Que el precio que se pague sea el justo y necesario, e incluso no muy desorbitado para el cliente.
  • Que la estimación de tiempo sea más ajustada a la realidad, siendo los plazos de desarrollo más cortos.
  • Que el cliente consiga su producto, su valor, antes.

Por lo que recomiendo a todos los que trabajan en nómina en una empresa, y su jefe (o siendo jefes) no se lleven el cómputo de horas invertidas en proyectos, incidencias, etc., que lo hagan, porque es una moneda de cambio muy útil para cuando se quieren conseguir cosas importantes, dentro de la empresa.

Manifiesto Ágil

El manifiesto ágil fue fruto de una reunión que se mantuvo en Salt Lake City en marzo de 2001. Diecisiete críticos de los modelos de mejora del desarrollo del software basado en procesos, convocados por Kent Beck, padre del Xtreme Programming, escribieron el siguiente manifiesto:

Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:

  • A los individuos y su interacción por encima de los procesos y las herramientas.
  • El software que funciona por encima de la documentación exhaustiva.
  • La colaboración con el cliente por encima de la negociación contractual.
  • La respuesta al cambio por encima del seguimiento de un plan.

Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda.

Entre estas diecisiete personas estaban: Kent Beck, uno de los tres creadores del Xtreme Programming; Alistair Cockburn, padre de los Crystal Methods; Martin Fowler, gran defensor de la Refactorización; Ward Cunningham, estudioso de los patrones y antipatrones de diseño del software y otro de los creadores de Xtreme Programming; Ron Jeffries, otro de los creadores del Xtreme Programming; Jeff Sutherland, gran promotor de Scrum.

Individuos y su Interacción sobre Procesos y Herramientas

No hay que malentender estas palabras tomándolas en su sentido más radical. La expresión de esta frase se refiere que se valora más la comunicación humana, las reuniones y lo que una persona pueda transmitir a otra, que las herramientas.

Así mismo, se considera más importante la valía de la persona, del programador y del diseñador, que los procesos establecidos en sí.

Software que funciona sobre Documentación exhaustiva

Es lógico que, si tengo un software que no funciona como quiero, da igual lo grande que sea la documentación. Es más útil un programa intuitivo, que hace única y exclusivamente lo necesario y tiene una calidad interna alta (código limpio, claro y con comentario concisos) que un software enrevesado que necesita un manual de no menos de 100 páginas para poder entenderlo.

Colaboración con Cliente sobre Negociación Contractual

La firma de un contrato ata a ambas partes a realizar un cierto desarrollo en un determinado tiempo con un gasto prefijado, solo que estos valores son solo estimados.

El contrato debe de existir, pero hay que colaborar con el cliente en realizarlo de forma más flexible, es decir, que los desarrollos sean de períodos cortos y vayan dando valor al cliente, de modo que, con esas cortas entregas, el cliente pueda decidir el curso a seguir entre iteraciones con sus peticiones y los desarrolladores realizar solo el esfuerzo necesario.

Respuesta al cambio sobre Seguimiento de un plan

Como comentaba, salvo para administraciones públicas, los desarrollos que se realizan a vista de un año o más, no suelen aportar valor al cliente hasta terminado ese período de espera. Una empresa que necesita un software, normalmente no puede dar unos requisitos fijos que, a lo largo de los siguientes meses, no cambien debido a un cambio externo o una necesidad de la propia empresa.

Por este motivo, la respuesta al cambio es vital y muy necesaria y, como indicaba el punto anterior, el hecho de poder hacer iteraciones y dar valor al cliente cada poco tiempo es lo que se persigue con el desarrollo ágil.

Conclusión

Esto se produjo en marzo de 2001, desde entonces ninguno de los diecisiete, más otros igualmente grandes, como Mary Poppendieck o Mike Cohn, no han parado de aportar bibliografía sobre el tema y métodos o matizaciones de los métodos ya existentes.

En este sentido, se puede decir que el desarrollo del software es un terreno vivo, donde no paran de descubrirse y crearse métodos y técnicas, para poder abarcar de una forma más exacta el desarrollo de un proyecto de software.

Lenguajes Funcionales para el Desarrollo Web

La web concurrente, a prueba de fallos y distribuida ya va siendo más fácil de desarrollar gracias a dos iniciativas paralelas. Una de ellas es Erlyweb, el entorno desarrollado por Yariv Sadan que permite realizar de forma fácil sitios web en lenguaje Erlang. La otra es Lift, un framework de desarrollo web para otro lenguaje funcional: Scala.

¿Lenguaje funcional para la web?

Muchos se harán esta misma pregunta, si de siempre, los lenguajes imperativos han sido empleados para el desarrollo de aplicaciones web (Java, PHP, Ruby, Perl, C#, …), ¿por qué emplear un lenguaje funcional como Scala o Erlang?

Las ventajas son las siguientes:

  • El lenguaje funcional obliga a pensar lo que se programa, realmente, en este tipo de lenguajes también es posible cometer errores y hacer barbaridades, pero en menor medida. Por regla general, lo que se programa en un lenguaje funcional, suele ser meditado, pensado y puede ser probado de mejor forma.
  • Obliga a organizar el código, ya que todo gira en torno a crear funciones que se llamen unas a otras y a sí mismas, así como tener el código separado en módulos o bloques funcionales. Por ejemplo, en Erlang, para emplear OTP (gen_server, gen_event, gen_fsm…) se debe de crear un módulo para cada uno de ellos, con lo que todo queda bien organizado.
  • El código resultante es más corto y más legible, ya que el código funcional no reutiliza variables, se basa en listas y tiene menos estructuras de control que los lenguajes imperativos, sí, resulta más fácil de comprender el lenguaje en sí y el código, una vez se va leyendo.
  • Tienen ventajas cuando se habla de concurrencia, tiempo real y tolerancia a fallos. Obviamente, si no se permite la reasignación, no se permite cambiar el valor de un dato ya asignado y, por tanto, no hay cabida para la memoria compartida, con lo que la concurrencia se simplifica de forma sorprendente. Por otro lado, estos lenguajes han sido pensados y desarrollados para distribuirse en varios nodos y/o equipos, pudiendo migrar sus procesos entre nodos y sustituir al nodo principal en caso de no estar operativo.

En lo que respecta al lenguaje en sí, se ve claro y, hasta muchos pensarán: ¡mierda!, he perdido el tiempo aprendiendo y usando PHP (o Perl, o Ruby, o Java…); pero no hay que ser tan radical, estos lenguajes son muy útiles y ofrecen muchas ventajas a los lenguajes tradicionales web y, gracias a los frameworks desarrollados, las mejoras son increíbles.

Si tan bueno es… ¿por qué no se usa?

Seamos sinceros, la razón de uso de un sistema u otro se basa, íntegramente, en la popularidad, la costumbre y los malos usos. Cuando en tu entorno hasta 3 personas dicen que PHP es bueno para la web, ya sabes que es lo que hay que aprender si quieres hacer web, pero eso no debería de ser lo único a calibrar, y sobre todo si el conocimiento que se adquiera de PHP se usará para el desarrollo profesional de aplicaciones.

Erlang lleva muchos años usándose en el terreno de las telecomunicaciones y Yariv, el creador del framework Erlyweb, integra servicios desarrollados en Erlang para Facebook, con lo que, los grandes de Internet, ya se han dado cuenta de que hay que dar un paso hacia adelante. Por otro lado, Scala es usado en otros sitios como Twitter.

Ahora de verdad, ¿por qué usarlos?

El desarrollo de entornos web conlleva el uso de varias tecnologías que se usen de forma coordinada y limpia. Desarrollar un software en cualquier lenguaje mezclado con SQL y código en HTML con CSS incrustado y código JavaScript repartido por todos lados hace que el código sea difuso. Difícil de entender.

Sin embargo, con C# y Java se comenzaron a emplear soluciones que han ido trascendiendo a lenguajes de scriptting como Ruby, Python o PHP, en los que ya no se dejan ver consultas SQL, sino el uso de objetos y funciones, el código de presentación queda almacenado por separado con etiquetas especiales, helpers y otros añadidos, los códigos HTML validados, los CSS en sus respectivos ficheros aparte y agregados desde la sección pertinente e incluso el uso del JavaScript no intrusivo.

Llegados a este punto, nos encontramos con que, desarrollar web es, tan solo, desarrollar. Realizar el programa en un solo lenguaje y de forma fácil. Pero aún así, volvemos a encontrar lo que ya había tiempo atrás, nuestro lenguaje imperativo puede contener fallos lógicos y, si es un lenguaje de scriptting muy permisivo, algunos de esos fallos son difíciles de perseguir.

El uso de un framework como lift o erlyweb facilita el seguimiento de fallos, desarrollar en erlang y scala facilita el desarrollo propio de la aplicación y agrega factores determinantes de crecimiento de la misma, así como estabilidad, ¿qué más se puede pedir?

Planificación de Póker

Leyendo un artículo de una página de una empresa suiza (Crisp), he visto a lo que se refiere la planificación de póker. Voy a traducir gran parte del artículo para explicarlo.

Introducción

La estimación es una de las actividades del núcleo de Scrum y otros procesos ágiles. Este proceso se refiere a darle una duración a cada historia, p.ej. ¿cuánto tiempo tomaría?, ¿cuánto trabajo tiene su implementación?, ¿cómo de caro es?, o cualquier otra cosa que quieras poner.

En Scrum, la estimación es una actividad de equipo. Para cada historia, todo el equipo participa en el proceso de estimación.

La planificación de póker (a veces llamada Scrum Póker) es simple, pero una potente herramienta que hace la estimación de equipo más rápida, más precisa y más divertida. El término fue acuñado por James Grenning y popularizado por Mike Cohn.

Estimación sin Planficación de Póker

Aquí hay un problema típico con las estimaciones de equipo. Cuando estamos en la planificación de un sprint y el Dueño del Producto dice:

Vale, chicos, ¿cuánto tiempo necesitáis para esta historia?

El equipo comienza a pensar acerca de la duración de la historia (en el caso ideal de hombres-día)…

El participante A cree que el sabe exáctamente lo que necesita para hacerse, así que él piensa que puede tomar 3 días. Los participantes B y C son más pesimistas. Los participantes D y E están fuera de la conversación. El participante A dice “3 días”.

Esto hace que los participantes B y C queden confusos. Comienzan a dudar de sus propias estimaciones. El participante E despierta y no sabe realmente qué está siendo estimado. El participante D está aún dormido.

El dueño del producto pide al resto del equipo su estimación.

Como se puede ver, el resto del equipo ha sido fuertemente influenciado por el participante A, solo porque él habló primero. ¡Esto es muy arriesgado!, Tanto B como C pensaron que podría tomarse mucho más de 3 días, ¡sus dudas deberían ser aireadas!

Estimación con Planificación Póker

Ahora imagina que cada miembro de equipo tiene una baraja de cartas, conteniendo las siguientes cartas:

Vamos a rehacer la estimación. El dueño de producto dice:

Vale, chicos, ¿cuánto tiempo necesitáis para esta historia?

Una vez de nuevo, el equipo comienza a pensar sobre el tiempo que tomaría la historia.

Esta vez, nadie dice nada. En lugar de eso, todos tienen que presentar una carta, bocaabajo, conteniendo su estimación. Todo el mundo tiene que tener presente una carta, así que los participantes D y E despiertan. El participante D admite que estaba durmiendo y pide que se le repita la historia. Es difícil evadirse cuando se estima de esta forma :-)

Cuando están todos, todas las cartas se destapan simultáneamente, revelando las estimaciones de todos.

¡Oooops! Gran divergencia. El equipo, en particular los participantes A y C, necesitan hablar sobre esta historia y el porqué sus estimaciones son tan diferentes. Después de la charla, el participante A dice que había olvidado algunas tareas importantes que necesitan incluirse en la historia. El participante C dice que, con el diseño que el participante A presentó, la historia parece ser más pequeña de 20.

Después de la charla (3 minutos en total) hacen otra ronda de estimación para la misma historia.

¡Convergencia! Vale, no hay una convergencia completa, pero están de acuerdo en que una estimación de 5 puede ser lo suficientemente cercana. Siguiente historia.

¿Por qué la extraña serie de números?

El más alto de los números tiene menos granularidad. ¿Por qué?, ¿Por qué no hay 21, por ejemplo?

Por varias razones:

  • Acelera el proceso de estimación limitando el número de opciones (p.ej. número de cartas).
  • Elimina una falsa sensación de precisión para estimaciones altas.
  • Potencia al equipo a partir historias grandes en otras más pequeñas.

Una estimación alta (mayor de 20, por ejemplo) normalmente quiere decir que la historia no se entendió bien en detalle. Podría ser una pérdida de tiempo discutir si la historia tiene 19, 20 ó 22,5. Esta es, simplemente, una historia grande y un 20 debería reflejar eso. Si deseas entrar en detalle, rompe la historia en varias historias más pequeñas. Las pequeñas historias pueden ser estimadas en gran detalle.

Cartas Especiales

La carta cero significa esta historia está hecha o la historia es tan corta que se puede hacer en muy pocos minutos de trabajo.

La carta del signo de interrogación significa No tengo ni idea. Debería de ser rara. Si esta carta es usada demasiado frecuente, el equipo necesita hablar las historias más e intentar alcanzar un mejor conocimiento.

La carta del café significa Estoy demasiado cansado para pensar. Vamos a tomar un descanso.

Conclusión

Después de leer el artículo completo, saco en conclusión que, algo como es la capacidad de comunicación, es algo que hay que intentar potenciar en los equipos de desarrollo, a modo de que, no solo todos y cada uno se puedan expresar, sino emplear técnicas como esta para que su expresión no sea opcional, sino parte del juego.

Es importante que la opinión de un miembro del equipo no se vea afectada por la de otro, a menos, hasta poner toda la información sobre la mesa, que es cuando ambos, deben de afectarse por la información del resto del equipo, y llegar a un punto de comunicación e información que le dé consistencia a la estimación.

Lo justo y lo estándar

Desde hace unos meses, he estado envuelto en algunos proyectos, en los que he intentado dar un enfoque basado en patrones y estándares, para facilitar y simplificar los problemas. Solo que, hay patrones y sistemas, o frameworks, que son algo incompatibles entre sí.

Por ejemplo, el uso de un sistema BPM, puede ser compatible con un sistema REST como Ruby on Rails, mientras se mantenga la idea de REST… en cambio, si se modifica por intentar realizar un poco interoperatibilidad entre otros sistemas, a los cuales no se les quiere cambiar mucho la forma… se convierte en un infierno.

Al final, lo mejor, es mirar la piezas con las que queremos contar, por ser afines a los resultados que queremos obtener y, emplear única y exclusivamente, los patrones que se puedan ajustar bien a esas piezas.

En este caso, por ejemplo, Ruby on Rails, combina bien con sistemas BPM que sean REST, e incluso con bases de datos que sean REST, pero le quita características bastante deseables que sí tiene otro patrón como ActiveRecord, ante lo cual, se establece un sistema de preferencias y prioridades… ¿REST o ActiveRecord?… como es lógico, optando por ActiveRecord, desaparece BPM como tal, ya que ActiveRecord está hecho para su acceso directo a base de datos.

Pero al final, la base de datos, bien mirada, termina siendo nuestro sistema BPM y, con ayuda de procedimientos almacenados, triggers, usuarios y demás… es un sistema, no tan potente como otros, pero sí lo suficiente como para cumplir con las especificaciones básicas.

Bueno, al final, me doy cuenta de que, al igual que cuando se programa, se debe de decidir bien la estructura, los elementos a emplear, la forma y demás… cuando se desarrolla, se ha de tener especial cuidado con las metodologías, patrones de diseño y estándares, puesto que hay que comprobar que coordinen bien entre sí.

De Programador a Desarrollador

Cuando tenía doce años, comencé a programar en Basic, en un ZX Spectrum de 128K… en esos momentos, y los años siguientes, hacer un programa, para mi, era sentarme delante de mi ordenador, durante unas cuantas horas, incluso echando noches en vela, para al final ver el resultado… un pequeño programa de gestión de contactos, un juego de puzzle, tetris, plataformas 2D… y eso, a lo largo de los años… y de los lenguajes, pasando por Basic, C, C++, Modula-2, Pascal, Java, Perl, PHP, Python, Ruby, Erlang…

La programación se convierte, en mi vida, en mi tiempo libre y, después, en mi trabajo, en una forma de realizar programas de ideas que me surgen, de forma heróica, y sin una fuerte organización que me permita ver el resultado de mi esfuerzo, ni las horas que voy a invertir, ni si merece la pena hacerlo de una cierta forma u otra.

Como programador, disfruto de la programación sin orden, anárquica, programo lo que quiero, como quiero y todo el tiempo que quiero. Me encuentro con los problemas típicos de haber abordado un problema del modo equivocado, y tener que reescribir una y otra vez el mismo código para alcanzar una forma óptima de lograrlo… pero no es óptimo y muchas veces aburre, ¿cuál es el siguiente paso?

Desarrollar es tener una idea en mente, darle forma hasta conseguir una idea completa y organizada, o al menos creíble, de un producto software conseguible mediante algún camino que se pueda tomar. Es decir, que si programo el código de una cierta forma, conseguiré lo que me propongo, ya que, mediante un diseño previo, he podido analizar las posibilidades de que no me ocurra el encontrarme ante un callejón sin salida.

Pero no es solo saber de antemano donde nos metemos al comenzar a programar, sino también, poder distribuir el trabajo en un equipo de desarrollo, un equipo de programadores. El análisis del problema nos permite ver qué hay que desarrollar exactamente, detecta las necesidades para que, después, el diseño nos diga el cómo podemos abarcar el problema para su resolución. Y ese cómo incluye la división del trabajo.

Como desarrollador, y viendo la programación como una parte del conjunto de hacer un proyecto de software, he podido aprender que, para poder realizar de forma más óptima un proyecto, hay dos caminos:

  • predictivo / por procesos: cuando se ha desarrollado ya bastante software del mismo tipo, es fácil poder estimar y cerrar requisitos, es fácil tener una especificación del problema a resolver, realizar el análisis, el diseño y la programación del mismo. Es fácil predecir cuánto tiempo se puede tardar en cada fase y realizarlo sin problemas. En este sentido, es bastante fácil tomar un modelo de procesos como el CMMI, SPICE o Metrica-3, y seguirlo para conseguir nuestro objetivo, consiguiendo además, la máxima documentación útil sobre el proyecto.
  • ágil / por iteraciones: si el proyecto que se quiere conseguir es sobre una tecnología que no se domina, plataforma nueva, o requisitos cambiantes, lo mejor es emplear una metodología ágil, que nos permita agregar flexibilidad para el cambio de requisitos, mediante entregas cortas, periódicas y agregando valor cada vez al proyecto a desarrollar, mediante la continua liberación de versiones. Las metodologías más usadas son Scrum, XP, Lean, FDD, DSDM, Crystal, Kanban, …

En conclusión, el siguiente paso ha sido convertirme en desarrollador. Conocedor de las metodologías predictivas y ágiles y poder dar a cada proyecto la orientación necesaria para poder llevarlo a cabo de la mejor forma posible.

La liebre y la tortuga

En este cuento voy a intentar explicar lo que significa programar rápido y lo que significa programar de forma ágil. La primera forma sería la que se considera comenzar lo antes posible, para terminar lo antes posible… pero ciertamente, sin planificación, dar palos de ciego a ciertos niveles de implementación, es más lento que planificar la estrategia de desarrollo a priori. Vamos a verlo con el cuento de…

La liebre y la tortuga

En Silicon Valley, había un programador tan rápido que podía escribir cientos y miles de líneas de código en cuestión de pocas horas, trabajaba rápidamente y, por ello, era conocido como la liebre. Aunque era un poco alocado, se lanzaba directamente a programar y no planificaba bien los proyectos.

No obstante, todos lo admiraban por lo rápido que hacía aparecer código en tan poco tiempo.

Por otro lado, estaba otro programador, algo más lento, que planificaba en papel y lentamente todos sus desarrollos, con lo que en un día obtenía muy pocas líneas de código. Este programador era conocido, por esto mismo, como la tortuga.

La liebre y la tortuga trabajaban en la misma empresa y, ante la fuerza que la admiración del resto ejercía sobre el primero, por su característica totalmente opuesta a la del segundo, la liebre instigaba e intentaba siempre perjudicar a la tortuga.

En la sala de trabajo, un día, cuando la tortuga ya se cansó de tanta hostilidad, aprovechó la oferta de un trabajo de programación importante, con un nivel de desarrollo importante y grande, para retar a la liebre: tú que eres tan rápido, te desafío a desarrollar este programa más rápido que yo.

Toda la sala quedó estupefacta, salvo el director de proyectos, que disimuladamente sonrió, agregando: sería interesante verlo. A lo que el resto de la sala agregó más risas.

El director de proyecto se dirigió a la liebre y le preguntó: ¿serías capaz de desarrollar este proyecto en menos tiempo que la tortuga? A lo que la liebre respondió sin dudar: ¡claro que sí! Pues os doy a ambos una semana para el desarrollo del proyecto, quien antes lo termine cumpliendo con los requisitos especificados, será el ganador.

La liebre comenzó a reir, aceptó el trato, al igual que la tortuga y fue a seguir riendo con sus compañeros durante largo rato mientras la tortuga marchó a su puesto de trabajo. La tortuga analizó el proyecto e inmediatamente localizó una serie de patrones claros que seguir, tomó los requisitos y trazó los diagramas que le harían cumplir con los mismos de la mejor forma, para seguir con una planificación ajustada al tiempo que tenía para cumplir con el proyecto. Se puso manos a la obra y comenzó el diseño.

Mientras tanto la liebre, se tomaba su tiempo y, mientras hablaba con sus compañeros decía: si ya sé cómo lo voy a hacer, es una chorrada de proyecto, ¡muy fácil!

En el segundo día, la tortuga terminaba su diseño con diagramas de UML, marcaba la división y los patrones que integrarían cada una de las clases, así cómo los detalles del diseño de interfaz y otras características a tener en cuenta en diagramas de secuencia.

Al tercer día, la liebre comenzó a codificar, en poco tiempo, tenía un trozo de código que cumplía los primeros requisitos y reía a gusto creyendo saber que conseguiría su propósito. Mientras, la tortuga, acababa de sentar el esquema de clases y la estructura básica, la arquitectura de soporte y preparaba todo para comenzar la codificación al día siguiente.

En el cuarto día, la liebre comenzó a encontrarse los primeros problemas, algunos requisitos chocaban directamente con muchas de las partes ya desarrolladas y en funcionamiento, así como datos ya implementados en la base de datos, con lo que se veía obligada a rehacer la estructura de datos, eliminar todo el código que no le servía y volver a escribir código nuevo. La tortuga comenzaba la codificación con la estructura de clases autogenerada por las herramientas CASE que usaba y trazaba las líneas de código de acceso a datos y lógica de negocio, escribía las pruebas unitarias para asegurar que todo salía bien y seguía adelante.

El quinto día, para la liebre, comenzaba el stress, la desesperación, se acerca el final del proyecto, aún no están todos los requisitos y se han vuelto a encontrar problemas. Como no hay una visión global, no sabe cuantos problemas más puede llegar a encontrar y, para los ya encontrados, la recodificación es algo pesada. Con lo que parece que solo lleva, de forma constante la mitad del proyecto. Por otro lado, la tortuga ha terminado la parte de lógica de negocio y manejo de datos, así como la parte de seguridad y acceso, el controlador, con lo que solo le restan las vistas, con las pruebas funcionales para acabar el proyecto.

El sexto día, cuando se había previsto la entrega del proyecto, la liebre había pasado toda la noche en su puesto de trabajo, intentando, con chapuzas, terminar a tiempo el proyecto, haciéndolo de forma muy deficiente y sin probarlo. Sin embargo, la tortuga, ya acababa la vista, haciendo siempre la ejecución de las pruebas de regresión para probar la integración de cada una de las partes, junto con las funcionalidades pedidas y el entorno en sí.

A la entrega del proyecto, la liebre presentó un proyecto con fallos, que no terminaba de funcionar y que tenía implementados los requisitos solicitados de forma dudosa, mientras que la tortuga entregaba un proyecto bien pensado, con un resultado limpio y funcional.

Ante los resultados, el director de proyectos se dirigió a la liebre y le dijo: no es cierto que es más rápido quien más rápido programa, sino quien, con menos código y menos trabajo, consigue hacer lo mismo en menos tiempo; y con ello, la tortuga ha demostrado, que es más rápido que la liebre.

Conclusión: usar metodologías ágiles acelera realmente el desarrollo, porque optimiza el proceso de creación.

Reia: Ruby sobre Erlang

Al igual que en Java se pueden ejecutar lenguajes scripting tales como Ruby (JRuby), Python (Jython), Groovy… es posible hacer esto mismo en otros lenguajes, como C y Erlang.

Erlang, es un lenguaje funcional, del que ya hablé en otro artículo, lo cual tiene sus ventajas para ciertos algoritmos… pero también sus inconvenientes para otro tipo de algoritmos, por lo que el poder combinarlo con lenguajes de scripting tan potentes como Ruby, es una forma de poder acelerar nuestros desarrollos… allanamos el camino quitando todas las piedras :-)

El sistema que hace esto es Reia. Este sistema, escrito en erlang y reia (casi la misma sintaxis que Ruby), da las capacidades de un lenguaje dinámico sobre un lenguaje funcional, dando la posibilidad de escribir código tanto en erlang como en reia e ir alternando. El resultado siguen siendo los archivos beam que la máquina de Erlang interpreta y ejecuta sin problemas.

ETL: Extracción, Transformación y Carga

Este término, ETL, se acuña a la mayoría de transformaciones de datos que deben de realizar empresas para compatibilizar sus datos con los de sus proveedores y/o clientes.

Este sistema se basa en los tres pasos de los que salen sus siglas:

  • Extration: la extracción se refiere a obtener datos. Si tenemos una fuente de datos como puede ser un fichero CSV, o un fichero Excel (lo más típico en muchas empresas), el trabajo comienza por configurar ese fichero como origen de datos. También hay posibilidad, según la complejidad del sistema o lo avezado del programador, de poner otros orígenes de datos más originales, como son: base de datos relacionales, jerárquicas (o directorios), conjuntos de ficheros, conexiones HTTP, FTP, POP3 o IMAP, etc.
  • Transformation: la transformación se refiere a, con los datos tomados de las fuentes específicas, realizar las transformaciones oportunas para obtener los datos que se requieren. Estas transformaciones se pueden realizar en múltiples lenguajes de script. Normalmente, en muchas plataformas, se usan lenguajes como JavaScript, otros tienen una interfaz gráfica desde la que se configuran las transformaciones.
  • Loading: la carga de datos consiste en tomar los datos procesados, una vez terminada la operación de transformación, y depositarlos donde se indique, ya sea una base de datos, un conjunto de ficheros o un fichero, en el directorio especificado o enviado a través de FTP, HTTP POST o SMTP… etc.

El sistema es simple y, por lo tanto, como todo lo simple, tiene una gran cantidad de aplicaciones que facilitan, entre otras cosas:

  • Automatización de tarifas, ya que si el proveedor nos envía sus tarifas en formato de fichero o en un email formateado de alguna forma, se pueden obtener esos datos y cargarlos en nuestro sistema de base de datos, hacer las transformaciones precisas e, incluso, enviar los resultados a nuestros clientes en formato PDF por email.
  • Comunicación con el cliente, en modo de que, tomando los datos de nuestras base de datos con referencia a saldos, ingresos, tarifas o cualquier información que interese al cliente, pueden ser también ofertas o productos marcados como rebajados, se envíe esta información en formato PDF con una presentación predefinida a cada uno de nuestros clientes.
  • Generación automática de informes. Por supuesto, estos ETL que se creen se pueden ejecutar cuantas veces se quiera y de forma programada, por lo que, pueden servir para generar, por ejemplo, ficheros HTML estáticos (o incluso con código PHP) que nos muestren información referente a datos de nuestra base de datos.
  • Simplificar datos. Otra forma de usarlos es para crear lo que se conoce como tablas resumen, son tablas que tienen un conjunto de datos representados por la suma de sus campos, como por ejemplo el gasto de un cliente, se puede representar, además de por las líneas de detalle, por una sola tupla que sume todas esas líneas y se presente solo una por mes, e incluso en otra fuente de datos, una por año.

En cuanto más se adentra uno en este mundo de la acumulación e integración de datos, más funcionalidades se le pueden dar a estos sistemas ETL.

Sistemas ETL disponibles hay:

  • Benetl: un software algo simple, escrito en Java, que presenta las posibles transformaciones a través de pantallas. Ofrece bastantes características, pero se ve algo limitado.
  • Barracuda Integrator: tiene la pega, para mi gusto, de que es software propietario y que parece que solo funciona en Windows, pero hay que admitir que tiene buenas características y tiene una serie de presentaciones en las que se puede apreciar su uso, fácil y sencillo, y su potencial. El lenguaje para transformaciones es Visual Basic.
  • Clover ETL: este software es gratuito, no libre y, la parte negativa, es que la interfaz (Clover GUI) es de pago. No obstante, ofrece un sistema intuitivo, ágil y fácil de usar. Se ejecuta sobre varias plataformas, no solo Windows, y el lenguaje de transformación implementado (además de la posibilidad de uso gráfico) es propio: CTL; basado en C.
  • Pentaho Data Integration: es un software libre escrito en Java que permite tomar información de muchos y diversos orígenes de datos, hacer la transformación en lenguajes como Javascript y hacer la “entrega” de datos en distintos destinos.

Por tanto, considero el sistema ETL a tener en cuenta y usar software específico, una forma de acelerar los procesos más pesados en lo que respecta la informatización de tareas en las empresas.