Category Archives: Desarrollo de Software

ETL: revisando el software

Hace ya más de un año que escribí una entrada sobre ETL, donde comentaba los principios que lo fundan y algún que otro software disponible para realizar ETL. Revisando la entrada, me he dado cuenta de que el software que entonces encontré, ha cambiado bastante, incluso uno de ellos ha desaparecido como tal.

Por ello, aprovecho para que, los que sigan interesados en el mundo del bussiness intelligence puedan ver más tipos de software, algunos de ellos mucho más avanzados de lo que cabría esperar:

  • Pentaho Data Integration: es quizás el que mejor se mantiene de todos los software medio libres que existen en este ámbito. Las versiones más antiguas de Pentaho están abiertas para la comunidad sin necesidad de pagar ninguna licencia, mientras que las nuevas versiones solo son de pago. No obstante, las herramientas propias de Pentaho para realizar las transformaciones han evolucionado de forma que son más flexibles, potentes y simples al mismo tiempo.
  • Benetl: después de haberlo visto durante bastante tiempo, no sé si llamarlo concretamente ETL, ya que su misión específica consiste en la carga de ficheros de tipo txt, csv o xls, a una base de datos que, tan solo, puede ser PostgreSQL o MySQL. Esto hace que sea un sistema muy limitado, pero no obstante bueno si tus necesidades se adaptan a la tarea en concreto.
  • Talend Open Studio: es un sistema que me ha convencido realmente, en cómo debe de ser un buen sistema ETL. Aparte de ser un sistema open source, es un sistema visual muy completo que no solo permite generar tareas ETL en Java (como hacen muchos), sino también en Perl. Tiene un vídeo de demostración el cuál aconsejo encarecidamente, ya que muestra ampliamente varios ejemplos de uso de la herramienta.

¿Conocéis más herramientas o incluso las profesionales que se usen en entornos bussiness intelligence?, ¿qué opnión os merecen? ¡echad un comentario! :-)

Propiedad del Código

Cuando comencé a leer libros sobre Extreme Programming, me llamó la atención una de las propiedades de esta metodología de desarrollo, que era la propiedad del código.

Por mi parte he sido siempre muy comunista con respecto al código, no tengo el menor reparo en mirar, ampliar y corregir código de otras personas y dejo que los demás vean, opinen y corrijan y/o agreguen cosas a mis códigos… es la mentalidad del software libre.

Pero en las empresas ocurre lo contrario. Es muy normal, yo diría que incluso enfermizo, llegar a ver cómo cuando entras en una empresa en la que hay más de tres programadores, cómo cuando algo falla, cuando hay que hacer una nueva mejora, ampliación, adaptación, siempre dice uno en voz alta: ese código es de fulanito; indicando que ni lo va a ver, ni lo piensa modificar.

Concepto de Propiedad del Código

Eso es a lo que se refieren muchos de los autores de las metodologías ágiles. El hecho de que un código sea de alguien, es nocivo, perjudicial, para el desarrollo conjunto de aplicaciones.

Si se quiere desarrollar una aplicación, normalmente, llega hasta el programador (o programadores) que comienzan a escribir el código que hará que esa aplicación funcione. Si nos ponemos en el caso de una aplicación comercial de gestión de clientes, que se separa en modo MVC, y tenemos tres programadores que, se han segmentado y trabaja cada uno de forma autónoma en cada una de las capas, tendremos que entre ellos se comunicarán para hacer peticiones del tipo: Necesito que el modelo valide este dato; No puedo seguir hasta que la interfaz no la termine mi compañero; …

Inconvenientes y Perjuicios

Como he mencionado antes, crear parcelas en una aplicación en desarrollo, cuando es muy normal que se tengan que hacer modificaciones que influyan en todas las partes, hace que cada cambio esté guiado por conversaciones aisladas con gente del equipo que opina que eso no es suyo, que hables con otra persona que es la que lo ha hecho, etc.

Esta actitud crea incertidumbre de vistas hacia arriba, ya que un arquitecto, analista, jefe de proyecto, o director técnico, puede pensar que su desarrollo está demasiado atado a una persona, que puede irse de vacaciones durante dos semanas quedándose todo el trabajo parado, o incluso irse de la empresa, teniendo que hacer herencia de ese código a otros que tendrán que comenzar a estudiarlo.

Desde el punto de vista del programador, realmente y visto en frío, con esta actitud está solo. Es decir, ante cualquier trabajo que haya que realizar nuevo sobre su área, cada error que se produzca, cada tarea o incidencia que caiga en el trozo de código que tiene en propiedad es responsabilidad suya y solo suya, no pudiendo aprovechar la visión conjunta que puede aportar un equipo multidisciplinar.

Propiedad Comunitaria del Código

El hecho de que un código sea de un grupo (no de un individuo) hace que el código sea creado, modificado y ampliado por un equipo, por más de una cabeza pensante, por lo que dará más riqueza al código y se evitarán muchos errores, al ser más ojos los que ven ese código.

En principio, de cara a la alta esfera de la compañía, se ve al equipo de programación como un todo, cada uno puede realizar el trabajo sobre el código que se le diga que debe trabajar (por asignación), ya que es parte del equipo o grupo que lo ha creado.

Puede rotarse la delegación de su tarea (por vacaciones, marcha de la compañía, o baja laboral) en cualquier momento, puesto que sus compañeros saben lo que hacen y sobre qué lo está haciendo.

Ante un error o una incidencia, hay un grupo, un equipo, que puede revisar el código y corregirlo.

Conclusiones

Es sentido común el pensar que esto debería de ser así en todas las compañías, pero aún queda bastante en tema de educación el hacer ver a muchas personas que las cosas que hacen no son suyas, sino que son de la compañía para la que trabajan y en esa misma compañía, junto a ellas, han contratado a compañeros para hacer el trabajo más llevadero, más rápido y más profesional. Si esto no se aprovecha, entonces, no se ganará del intercambio de conocimiento entre personas que sepan más de un campo concreto, ni de la riqueza a la que puede llegar un software cuando se programa por un equipo, no por un individuo.

Resolviendo Shikaku

Esta es una práctica que realicé (y comenté) en diciembre de 2008 para la asignatura de Programación III de la UNED.

La práctica se basaba en realizar un sistema para resolver tableros de shikaku, mediante el algoritmo de vuelta atrás. Mi solución es óptima pero no del todo correcta desde un punto de vista académico, ya que el uso del algoritmo (de backtracking) es menos usado de lo que debería.

Para poder ver el código, este puede descargarse a través de un cliente de Subversion, en sistemas Unix/Linux es tan fácil como:

svn co http://project.bosqueviejo.net/svn/shikaku/trunk

Explicación del código

Bueno, tengo que reconocer que, después de algo más de un año de haberlo hecho, he tenido que releer y revisar de nuevo todo para acordarme (y reaprender) cómo hace lo que hace.

Por ello, voy a escribir una documentación básica sobre el código en sí, para tenerla como referencia, cuando tenga que volver al mismo otra vez, y para que sirva a todos aquellos que lo necesiten.

En principio, el código se divide en las siguientes clases:

  • shikaku.tablero.Combinacion: esta clase se encarga de almacenar combinaciones. Una combinación es un rectángulo que se sitúa ocupando un espacio de X*Y=N. La combinación debe de tener en alguna de sus casillas el número contenido, por lo que se almacena también la ordenada de N para comprobaciones.
  • shikaku.tablero.Ordenada: es cada uno de los números que aparecen en el tablero. Se almacena su posición dentro del tablero y la representación numérica del mismo.
  • shikaku.tablero.Tablero: almacena las dimensiones del tablero, la lista de combinaciones fijas (las que solo tienen una combinación válida detectada) y la lista de soluciones posibles para el tablero.

Una ejecución de shikaku tiene los siguientes pasos:

  1. Entra en main de la clase shikaku, donde se detecta el origen de datos, hasta saber de donde se va a cargar el tablero.
  2. En run se crea una instancia del tablero, y se ejecuta, para cada punto del tablero, el generador de la clase Combinacion.
  3. El generador se encarga de buscar combinaciones válidas para el punto dado, dentro del tablero y validando su posición dentro del tablero (es decir, que no haya parte del rectángulo fuera) y con respecto al resto de puntos (que no tenga contenido nada más que el punto del que tiene que hacer la combinación).
  4. El último paso para la resolución, es llamando a buscaSoluciones, de la clase Tablero, que se encarga de realizar el algoritmo de vuelta atrás para buscar las soluciones al tablero.

Estos son los pasos más importantes dentro del código para resolver el tablero de shikaku.

La depuración

Uno de los motivos por los que el algoritmo no es del todo de tipo vuelta atrás, es precisamente por el uso de tres algoritmos voraces que se ejecutan antes que el último, de vuelta atrás. Estos algoritmos realizan una criba sobre las combinaciones basándose en tres premisas que debe cumplir cada combinación para ser válida:

  1. Que no haya nada fuera del tablero: esto se realiza mediante una simple validación a la hora de generar las combinaciones. Es simple y rápida, y quita mucho procesamiento al algoritmo final.
  2. Combinaciones con un solo número: esto se refiere a que dentro del rectángulo que conforma la combinación, solo esté contenido el número objeto de la combinación y ningún otro. Esta validación también está incluida a la hora de generar las combinaciones, para lo que se necesita, en el generador, pasar todos los puntos del tablero.
  3. Eliminar combinaciones imposibles: imposibles, además de las que se descartan en los puntos anteriores, son las que colisionan con todas y cada una de las combinaciones posibles de otro número vecino. Si la combinación de un número colisiona con todas las combinaciones posibles de otro número, como es lógico, no podrá ser posible.

Ciertamente, con estos algoritmos se llega a resolver un alto porcentaje de los tableros básicos, sin necesidad de realizar el algoritmo de vuelta atrás. Solo los tableros grandes y con dificultad alta, necesitan, además de estos algoritmos voraces, el de vuelta atrás.

Mejoras

En sentido académico, teniendo en cuenta uno de los requisitos que se pide, que es que sea un algoritmo de vuelta atrás, quizás sea más correcto que la depuradora actúe solo a nivel de rama y no en profundidad.

Hay que tener en cuenta que esto penalizaría el rendimiento y empeoraría en lo que a gestión de memoria se refiere, pero prima más cumplir con los requisitos ;-)

Calidad Interna

el tema de la calidad ha llenado páginas y páginas de la literatura informática en todos los idiomas. Es tal la necesidad de la búsqueda de la calidad, que hay estudios, técnicas y departamentos dentro de empresas, e incluso empresas, que se dedican en cuerpo y alma a establecer parámetros de calidad a los productos y proyectos que se realizan en las empresas de desarrollo de software.

Dentro del tema de la calidad, visto como un amplio abanico de elementos que la conforman, nos topamos con uno bastante confuso y complejo al principio: la calidad interna.

¿Qué es la calidad interna?

Cuando se desarrolla un software, se desarrolla con una calidad medida según sus requisitos que pueden determinar su alto grado de calidad, midiendo una serie de parámetros. Pero estos parámetros no reflejan ni tienen en cuenta la calidad del proceso de creación del software en sí, ni la calidad del software escrito, solo la calidad externa, es decir, la función que realiza el software.

La calidad interna, sin embargo, mide y tiene presente la forma en la que se ha desarrollado el código de modo que pueda mantenerse (corregirse, ampliarse y adaptarse) de forma rápida y sencilla, gracias a un diseño e implementación limpia, simple y clara.

La importancia que tiene este tipo de calidad se muestra de manifiesto en varios textos como Scrum y XP desde las trincheras (de Henrik Kniberg) y algunos blogs como el de José Manuel Beas, Joseba Enjuto, una entrada de Diego Gómez en la web Dos Ideas, o incluso en el propio estándar ISO/IEC 9126.

¿Por qué es tan importante?

Para un desarrollador, la calidad interna es tan o más importante que la calidad externa, puesto que si un software hace lo que debe, pero una de cada 1000 veces no funciona, puede deberse a un fallo interno difícil de detectar que, pueda incluso verse agravado por la mala calidad con la que se ha desarrollado (diseñado o implementado) el sistema en sí.

En base a tiempo, un software desarrollado con una calidad baja o nula, puede ser desarrollado en un tiempo muy pequeño, ya que no se tiene en consideración muchos aspectos necesarios y útiles, como por ejemplo, una buena orientación a objetos, modularización del código, reutilización, algoritmos excesivamente complejos u ofuscados, etc.

Cuando, por un fallo (mantenimiento correctivo) hay que volver al código para corregir un defecto, y se detecta un error de diseño, modificar un código mal oliente, es más complicado que corregir un defecto en un código que está mejor desarrollado en base a patrones y reglas básicas de análisis, diseño o codificación.

En otras palabras: un programa con calidad interna baja es un programa que generará deuda técnica.

Deuda técnica

mi amigo Guillermo me remitió un email hace poco en el que detallaba un concepto que ya conocía hace tiempo, pero que no había visto tan bien explicado hasta el momento (sí, tenía que haber leído antes a Cunningham :-P ), el tema era: La deuda técnica en scrum, en un resumen de cómo lo enunció Ward Cunningham:

Hacer código de mala calidad a toda prisa, es como pedir un crédito: puede que obtengamos un beneficio a corto plazo pero si tenemos que seguir desarrollando ese código, tarde o temprano tendremos que pagar todo el tiempo que nos habíamos ahorrado y los intereses. Refactorizar código mal escrito es siempre más difícil que escribirlo bien desde el principio.

Creo que se ve claro que, programar rápido no significa hacerlo bien, en la mayoría de los casos, es raro hacerlo rápido y bien. Por otro lado, lo que puede haber funcionado (incluso de milagro) en una ocasión, si necesita mejoras o cambios, puede dejar de funcionar, teniendo que invertir mucho más tiempo del que habría costado hacerlo bien desde el principio.

¿Hacerlo bien significa gastar muchas más horas? No realmente. Si llevásemos un cómputo de las horas invertidas en hacer un proyecto de forma rápida, a priori, podría parecer que se han invertido pocas horas y el trabajo está hecho. El problema viene después, cuando toca corregir los errores de cualquier índole que no se han tenido en cuenta, o simplemente, por la rapidez, se han cometido.

Normalmente, las horas invertidas en mantenimiento, superan con creces las horas invertidas en un desarrollo basura. La comparación con el haberlo hecho bien, es que el tiempo de desarrollo planificado crece, pero el de mantenimiento es nulo o muy, muy pequeño. Por lo que, a la larga (o al medio plazo) compensa.

Gestión Documental en Blog

Hace tiempo, en reuniones mantenidas por todo el departamento técnico, sobre todo la parte de I+D, de la empresa en la que trabajo, mi compañero Juan Sebastián me comentó: podemos hacer la documentación en un blog.

Después de haber empleado métodos tradicionales como MS Word, OpenOffice Writer, LaTeX, DocBook… y otros más dinámicos como el wiki, aquella idea sonaba extraña, pero con cierto sentido.

Tras revisar el proyecto Knowledge Tree (árbol de conocimiento), llegué a ver más claro lo que comentaba mi compañero y comencé a verlo mucho más útil que toda la pila de documentación general que se realiza normalmente.

Los problemas

Cuando se realiza documentación, generalmente, se realiza un documento con una serie de apartados bien definidos y completados de la forma más completa posible.

El primer problema viene cuando hay que escribir el documento, el soporte. ¿Se hace en Internet a través de una página tipo wiki para que todo el mundo colabore?, ¿se hace en un sistema tipo foro para que se establezca en plan discusión?, ¿se hace en un sistema de control de incidencias para documentar tarea a tarea lo que llegue?

Este planteamiento deriva en otros muchos problemas. Cada uno, tiene el problema individual de que, cuando el nivel de información crece, la forma de buscar entre sus tripas para encontrar lo que se busca se hace más complejo y tedioso. Este sería el segundo problema de estos sistemas.

En el caso de que se haga una documentación formal. Tienes la posibilidad de imprimirlo cada vez que se haga una revisión del documento y dejarlo encuadernado y visible para uso de cada persona de la empresa o en un directorio compartido al que puedan tener acceso. Volvemos al principal problema de la búsqueda de la información dentro del documento, así como, cuando las personas vean que el documento excede de 20 páginas, seguramente lo mirarán con miedo.

El tercer y mayor problema… ¿quién lo mantiene?, en el caso de un documento wiki, hay que ir revisando sus páginas, al igual que en el documento formal escrito en formato de libro y es un trabajo que, una vez que el documento se extiende más allá de las primeras 20 páginas, se hace cada vez más dificultoso.

¿Y el blog lo soluciona todo?

Bueno, no es una panacea. Eso hay que tenerlo claro. Como comenté antes, el sistema Knowledge Tree tiene de bueno que comparte similitudes con los blogs, pero tiene la carencia de que los documentos escritos, siguen siendo los convencionales de procesador de textos, o cualquier editor que genere un PDF.

Por sus características, un blog tiene las siguientes ventajas:

  • Los blogs tienen artículos. Pueden constituir recetas en las que poner datos necesarios que se vean importantes para proporcionar información al resto de la empresa.
  • Un blog tiene categorías donde se agrupan todos los artículos escritos. En este caso, las categorías podrían delimitar áreas técnicas como: web, sistema, explotación, infraestructura, atención al cliente, administración, dirección…
  • Cada artículo puede contener una o varias etiquetas (tags). Estas etiquetas pueden ser esenciales para localizar documentos que tengan que ver con temas tan diversos como: altas de clientes, facturación, despliegue, desarrollo, entorno de trabajo…
  • Los artículos se escriben rápidamente y desde cualquier sitio, pueden contener media (imágenes, vídeos, presentaciones, audios…), que puede ayudar mucho a la documentación en sí.
  • Los artículos tienen la posibilidad de agregar comentarios. Esto es muy útil porque se pueden agregar actualizaciones pequeñas por otras personas, o preguntas frecuentes que no se hayan recogido en el propio artículo.
  • Los pingbacks o trackbacks, son referencias que hace un artículo contra otro cuando es referido por él. Esto es muy útil cuando queremos tener relaciones entre artículos, que quedan almacenadas en los mismos, a través de enlaces. E incluso actualizaciones a través de nuevos artículos.

Por todo ello, un buen sistema de blog puede ser empleado como sistema de gestión documental fácil de llevar a producción y fácil de implementar entre los trabajadores, sobre todo en el entorno de programadores, administradores de sistemas y similares.

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?