Herramientas para un grupo de trabajo

En este post quería dar mi opinión sobre las herramientas que un grupo de trabajo formado por varias personas debería tener en un desarrollo de software. Como no me gustan los posts demasiado genéricos voy a concretar en un desarrollo que o bien sea PHP o Java. También voy a dar los nombres de algunos productos para cada tipo de herramienta.

A modo de resumen algunas de las piezas que un grupo de trabajo debería tener son las siguientes:

• Un framework. O bien uno desarrollado por la propia empresa o bien uno existente.
• Un buen IDE (o RAD)
• Un sistema de control de versiones
• Un sistema de gestión de incidencias o bugs
• Una wiki empresarial
• Varios entornos de desarrollo: desarrollo, integración, preproducción y producción
• Tests y un servidor de integración continua

Sin querer he hecho una ordenación de las herramientas a utilizar que quizás sea bastante acertada. Por partes.

Framework

La primera pregunta es, ¿qué es un framework? Seguro que hay muchas definiciones en Internet pero voy a tratar de explicarlo de otra forma. Una librería se podría decir que es un conjunto de ficheros de código que te ayudan a resolver un problema. Por ejemplo, una librería para enviar correos electrónicos como Java Mail o SwiftMailer o una librería para hacer peticiones HTTP como Apache HttpClient o curl. Estas librerías se pueden utilizar en proyectos muy diversos (aplicación web, aplicación de escritorio, líneas de comandos,...) y no imponen muchas restricciones en cuanto al proyecto en el que se usan. Su API suele ser lo más sencilla posible para que pueda incorporarse a cualquier programa. El problema que resuelven suele ser muy concreto y común en muchos proyectos.

¿Un framework entonces es una librería? No. un framework es mucho más. Además de aportar una serie de ficheros de código un framework impone una serie de normas para el proyecto donde se encuentra. Muchas veces un framework suele ser un conjunto de librerías como las mencionadas anteriormente más esa serie de normas. Algunos ejemplos posibles de normas:
- Para poder crear una nueva acción hay que crear un fichero con extension .class.php y añadir su definición a un fichero XML.
- Los parámetros de conexión con la base de datos tienen que ir en el fichero databases.xml que se encuentra en la carpeta conf
- Si se quiere definir un interceptor para las peticiones HTTP este interceptor tiene que implementar la interfaz ServletListener

Estas normas pueden tener sus ventajas y desventajas. Hay muchos críticos de los frameworks en general que rechazan la imposición de estas normas que hacen estricto el desarrollo y que reducen el peso que tiene un programador en el producto final.

Sin embargo me gustaría diferenciar el uso de los frameworks en el uso individual y en el uso en un grupo de trabajo. Bajo mi punto de vista considero fundamental el uso de un framework en un entorno de trabajo y sobretodo cuanto más grande sea este grupo. También importante para aquellas empresas que piensen que un futuro pueden ampliar su equipo de trabajo y que las nuevas incorporaciones pueden trabajar en proyectos anteriores. En las siguientes líneas voy a tratar de explicar el por qué.

Como bien he comentado anteriormente un framework impone una serie de normas. Estas normas lo que obligan finalmente es que un proyecto tenga una estructura estandard. Esto es muy importante pues los integrantes del grupo de trabajo saben donde hay que crear las clases, dónde definir la conexión con la base de datos, cómo interactuar con ella, dónde y cómo crear la mayor parte del código. No es necesario reinventar la rueda. Si pensais en un proyecto que hace 6 meses que no se toca y que un buen día tienes que retomar te darás cuenta de lo importante que es tener una estructura ya definida. Además los integrantes del grupo de trabajo no hace falta que se pongan de acuerdo con dicha estructura. Ya está creada. Y normalmente tiene muchos casos de éxito que denotan que funciona.

Además estos frameworks están muy documentados. Tres ejemplos serían J2EE, Symfony o Spring. Muchos de ellos inclusos con libros con más de 1000 páginas con todo lujo de detalles.

Y si un nuevo integrante tiene que entrar en el proyecto no es necesario que conozca una nueva forma de hacer las cosas cada vez. Está ahí en la documentación. Seamos sincerios, a los informáticos no nos gusta documentar. Por lo menos el framework ya tiene algo.


Un buen IDE o RAD

Todavía recuerdo mis primeras andaduras con los lenguajes de programación en la universidad. Pascal, C, C++, Python, LISP, Cobol... Quizás el peor recuerdo que tengo de todas ellas es tener que programar con Emacs o Vi. Por favor, eso es una tortura en toda regla.

Un IDE ahorra diariamente muchas horas de trabajo. Organiza todo el código, te permite hacer búsquedas en todos los ficheros del proyecto. Te permite ejecutar, debuggear, documentar, ejecutar scripts,... todo desde una misma herramienta. Además se integra con sistemas de control de versiones, sistemas de gestión de bugs,... Te permite arrancar y parar tus servidores de forma automática. Me hizo gracia una frase de Rafa Gaitán en los segundos encuentros de programadores Java que se celebraron en la Uji. Un IDE es como sistema operativo. Cuánta razón tiene.

Como he comentado un buen IDE es una herramienta clave para el desarrollo. Es como una navaja suiza que te simplifica tu trabajo diario. Al integrar todo lo necesario para el desarrollo aumenta la eficiencia y la eficacia de forma considerable.

Para Java y PHP recomiendo sin duda Eclipse. Llevo utilizando este IDE desde hace más de 7 años y estoy muy satisfecho. Se dio a conocer por su editor de Java integrado. Desde hace unos pocos años cuenta también con un editor de PHP, PDT. Debido a su plataforma modular se han desarrollado muchos plugins que permiten extender su funcionalidad. De hecho el editor de Java y el de PHP son plugins sobre la base de Eclipse (que se llama Equinox). Algunos de los plugins que recomiendo:

• Sublicpse. Para utilizar subversion desde el propio editor
  
• Eclipse Mylyn. Programación orientada a tareas. Te permite conectar Eclipse con sistemas de gestión de incidencias
• Oxygen XML. Un editor XML con infinitas utilidades
• MyEclipse: Un paquete con multitud de plugins para trabajar con J2EE, HTML, CSS, XML, bases de datos,...

Para .NET desde luego recomendaría Visual Studio.


Un sistema de control de versiones

Es un sistema que te permite guardar un historial de todos los cambios realizados al código fuente de un programa. Tiene dos funciones principales:

• Mantener registro de cambios: Gracias a que se guardan todas las versiones de los ficheros es posible comparar un fichero con sus antiguas revisiones. Cuando se encuentran errores en la aplicación es muy común consultar las últimas versiones de cada fichero para averiguar cuándo se introdujo el error.
  
• Sincronizar a un grupo de trabajo: Cuando es utilizado por más de una persona el uso de estos sistemas tiene un segundo propósito y es el de sincronizar los ficheros que forman el proyecto. Al estar todos los ficheros almacenados en un servidor común (además de la copia que tiene cada usuario en su máquina) el sistema de control de versiones permite que varios integrantes del grupo trabajen con los mismos ficheros. Realmente cada usuario trabaja con su copia local pero existe siempre una copia común a todos (la que está en el servidor). Al sincronizar sus ficheros locales con los del servidor se puede saber si ese fichero ha sido modificado o no por otro usuario, qué cambios introdujo dicho usuario y gracias a un buen editor, si los cambios introducidos por el usuario que va a subir los cambios entran en conflicto con los anteriores.

No quiero entrar en mucho más detalle en este post pero quien no esté muy familirizado con el uso de estos sistemas, después de aprender su funcionamiento básico, debería investigar el uso de ramas. Las ramas permiten tener varias versiones no de un fichero sino de un proyecto versionadas a la vez. Siempre hay una principal (o trunk) y tantas ramas como se quieran crear. Estas ramas te permiten seguir versionando tu código pero sin necesidad de que entre en conflicto con los ficheros principales. Esto es muy común cuando por ejemplo se desea incorporar al proyecto una funcionalidad pero no antes de incluirla definitivamente se quiere probar extensamente. Se abre una rama del proyecto, se trabaja con dicha rama, se hacen las pruebas, y cuando ya está todo afianzado se hace el merge de la rama con la rama principal.

Hay varios sistemas de control de versiones. El primer gran conocido fue CVS, seguido por Subversion. Estos sistemas se instalan en un único servidor. Ahora se tiende a sistemas de control de versiones distribuidos como git pero no es el propósito de este post.

Eclipse cuenta con varios plugins para CVS y Subversion. De Subversion recomendaría Subclipse. Todos estos plugins te permiten consultar el historial de todos los ficheros, sincronizar todo un proyecto de forma que se pueda saber rápidamente todos los cambios que se han efectuado,... Consultar la documentación para más detalles


Un sistema de gestión de incidencias o bugs

Los sistemas de gestión de incidencias o bugs permiten centralizar en un servidor todas las tareas, mejoras, bugs de una aplicación. Es muy común entre los desarrolladores contar con una libreta donde se va apuntando todas las tareas que te faltan por hacer, errores que has ido encontrando, apuntes puntuales,... Esto es muy útil pero lo sería más si esa libreta fuera compartida por todos los integrantes del grupo de desarrollo. Si esa libreta la informatizamos y hacemos que todos puedan apuntar en ella lo que estaremos programando es el sistema de control de incidencias.

Los beneficios que aporta el sistema son tremendos. Gracias a tener centralizados toda la información referente a errores y mejoras el director de proyecto puede ir asignando la resolución de estas tareas a los desarrolladores. Esto permite que no se solapen en la faena. También permite desacoplar al equipo de desarrollo. Cuando se encuentra un error se guarda en el sistema, si un cliente propone una mejora se registra sin necesidad de que dicha información tenga que ser comunicada de inmediato, ni de apuntarlo en un postit o enviarlo por correo electrónico.

Estos sistemas permiten también priorizar las tareas, indicar para qué versión de la aplicación van a estar solucionadas, guardar la información de la resolución del error...

Toda la información registrada en el sistema permite a los responsables del proyecto tener fotos diarias de todo el trabajo que se está realizando, las tareas resueltas por cada integrante del grupo, informes automáticos de las nuevas mejoras de cada nueva versión,...

Habitualmente estos sistemas vienen con una interfaz web. Pero también se puede integrar dentro de Eclipse. Para ello se utilizar el plugin Eclipse Mylyn. Mediante el plugin se podrán crear las tareas (mejoras/incidencias/bugs), consultarlas,... y todo sin salir del editor.

Pero Mylyn es mucho más que eso. Mylyn es un plugin de Eclipse para la programación orientada a tareas. Como tarea entender la mejora, la incidencia o el bug del que se ha hablado en líneas anteriores. Con Mylyn en todo momento indicas sobre qué tarea estás trabajando. Cuando inicias la tarea Eclipse cierra todos los editores abiertos y crea un contexto vacío. Si estamos trabajando en la tarea crearemos ficheros y modificaremos los existentes. Todos estos ficheros se guardan en el contexto. Así, si tenemos que iniciar una nueva tarea y posteriormente volver a la primera sólo con indicar a Mylyn que activamos la primera tarea se abrirá automáticamente los ficheros de su contexto. Este contexto puede ser incluso compartido por varios usuarios. No es de extrañar que las tareas sobre las que se trabaja son las registradas en el sistema de control de incidencias. Tareas compartidas con el resto de integrantes del equipo.

Pero su punto de integración llega incluso al extremo de que si subes cambios al sistema de control de versiones, como comentarios de la subida te pone automáticamente la referencia a la tarea sobre la que estás trabajando. Eclipse - Sistema de control de versiones - Sistema de control de incidencias. Es un triángulo clave en el desarrollo.

Hay muchos sistemas de gestión de incidencias. Yo destacaría sin duda Atlassian Jira. En opciones Open Source tendríamos bugzilla o Trac pero son muy inferiores en cuanto a facilidad de uso y prestaciones.


Wiki empresarial

En muchos casos el propio sistema de control de incidencias, si se hace público, se suele utilizar como fuente clave para la documentación pero es también muy aconsejable tener un sistema wiki empresarial en el equipo de desarrollo.

En este sistema se almacenan todas las notas, manuales y tutoriales que el equipo va generando con el paso del tiempo. Centralizando toda la información cualquier integrante del grupo puede encontrar en la wiki respuesta a problemas que otros ya han encontrado previamente. También nuevas incorporaciones al grupo pueden encontrar en esta wiki una fuente de conocimiento.

No quiero extenderme mucho más en este punto pues es un tema más conocido por todos debido a la wikipedia, aunque raramente utilizado en entornos de desarrollo.

De nuevo hay muchas wikis. Yo recomendaría Atlassian Confluence. Aunque hay otras opciones interesantes como Alfresco. Si queréis utilizar MediaWiki (el utilizado en la Wikipedia) o similares mucho ánimo. No están preparados para los requerimientos de una empresa.


Varios entornos de desarrollo: desarrollo, integración, preproducción y producción

Un buen proyecto suele tener varios entornos de desarrollo. Esto es, distintas máquinas o servidores por los que pasa antes de ser instalado en el servidor real. De forma sencilla se podrían distinguir cuatro:

• Desarrollo: Cada desarrollador tiene un entorno funcionando en su máquina
• Integración: Servidor, normalmente alojado en las propias oficinas del equipo y que se utiliza para probar cambios realizados por varios miembros del grupo
• Preproducción: Entorno con características casi similares al entorno real y para hacer las últimas pruebas para estar completamente seguro de que todo va a funcionar
• Producción: El servidor real

Para pasar de un entorno a otro es muy importante contar con herramientas para hacer el despliegue (deploy) de forma automática. Así, pasar de un entorno a otro no debería ser más complicado que hacer doble click en un .bat, .sh o un fichero de ant. Merece la pena invertir horas de trabajo en automatizar este proceso pues a la larga siempre se obtiene un buen rendimiento


Tests y un servidor de integración continua

Por último resaltaría la necesidad de contar con una batería de tests en el proyecto. Los tests ayudan a mantener la estabilidad del código, a asegurar que no se introducen errores en su ciclo de vida. En la medida de lo posible hay que evitar el testeo manual.

Simplificando podemos distinguir dos tipos de tests:

• Test unitarios: Testean piezas individuales de código. Por ejemplo una clase que valida DNIs.
  
• Tests funcionales: Cubren varias clases y su cometido es comprobar que capas superiores de la arquitectura de la aplicación funcionan. Por ejemplo probar que una transferencia bancaria funciona correctamente.
  

Los patrones del TDD (Test Driven Development) llegan a decir que los tests tienen que cubrir el 100% del código y que tiene que haber un test unitario por cada pieza de código desarrollada. Yo usualmente sólo desarrollo tests funcionales pues hacer tests unitarios lleva muchísimo tiempo y creo que es muy complicado realizarlos correctamente.

En Java recomendaría JUnit o TestNG. En PHP yo utilizo un framework propio de Symfony aunque PHPUnit también es muy completo.

También comentar que Eclipse tiene plugins para los anteriores por lo que de nuevo no hay que salir fuera de él para ejecutarlos.


Los servidores de integración continua automatizan el despliegue de una aplicación y la ejecución de los tests asociados. Sus ejecuciones se suelen programar, por ejemplo, para cada tres horas. Poniendo un ejemplo, un servidor de estos se podría configurar para que se descargara del sistema de control de versiones la última versión del proyecto, la instalara en el servidor de integración y ejecutara uno por uno todos los tests. El informe de los resultados se guardaría y podría ser consultado en todo momento. Estos servidores obligan al equipo a hacer integraciones continuas y tener un ciclo de desarrollo de software iterativo.


Conclusión

En resumen, hay multitud de herramientas disponibles para el uso de un equipo de desarrollo. Un buen uso de estas herramientas mejora rápidamente la eficiencia del equipo y asegura una mejor calidad del producto final.

Un sistema de control de versiones para almacenar todo el código de los proyectos y permitir el trabajo en paralelo.

Un sistema de control de incidencias para centralizar todas las tareas que se realizan y asignar prioridades y miembros a cada una de las tareas

Un wiki para guardar la documentación generada y que los miembros actuales equipo y sobretodo los que están por llegar encuentren de forma rápida la información requerida.

Una batería de tests para asegurar que los cambios realizados en el código no afectan a otras partes del código.

Y poniéndonos en plan literario "y un IDE para gobernarlos a todos".

Iniciador Castellón - Bernardo Hernández

Ayer viernes 25 de Septiembre se celebró el segundo Iniciador Castellón en el Aula Magna de la ESTCE de la Uji. Para esta segunda edición se contaba con la participación de Bernardo Hernández, director mundial de Marketing de Google y participante en proyectos como idealista.com, floresfrescas, 11870, tuenti, planetaki y stepone.

La charla empezó bastante floja con un breve repaso de la evolución tecnológica. Su mensaje se centraba como es lógico en el lado más comercial, comparando el rápido impacto de Internet con otros medios tales como la radio y la televisión y dio datos interesantes pero los medios sencillamente son tan distintos que tratar de hacer comparaciones se reduce a lo meramente anecdótico.

De Google realmente habló poco y demasiada parte del tiempo se dedicó a darse autobombo en todos los proyectos en los que participa. Es normal en estos casos pero por ser normal no tiene por qué gustar. Quien esperaba de la charla un poco más de información de lo que es Google, sus políticas, cómo es la vida en esa compañía os recomiendo el libro El Modelo Google, de Bernard Girard.

Entre transparencia y transparencia sí que dejaba caer perlas que merece la pena comentar. El mensaje más importante sin duda apareció con la locomotora tirando del carruaje. Incidió con mucho acierto en que hay empresas que se han dedicado a utilizar la misma receta cuando la tecnología iba evolucionando. Periódicos que migraban su versión impresa directamente a la red sin más innovación, las empresas de marketing con los molestos popup, páginas amarillas con su misma receta hecha web,... Cuánta razón tienes.

Me gustaría resaltar de los tres ejemplos el mundillo del marketing web donde Adwords ha hecho algo tan maravilloso como crear publicidad selectiva y controlada. Selectiva pues decides en qué páginas puede aparecer y controlada porque puedes indicar lo que te quieres gastar y puedes controlar el número de visitas en tiempo real.

A pesar del interés en muchos de los asistentes en extraerle algo de información sobre las novedades que traerá Google Bernando fue muy correcto y simpático indicando que no podía decir nada. Me aventuro a pensar que en las próximas semanas se van a poder realizar búsquedas de información en tiempo real y que en los resultados por defecto esta información aparecerá por defecto.

También explicó en reiteradas ocasiones que compañías como Google y Tuenti se forjan con grandes profesionales. Que si no te rodeas de los mejores su éxito es imposible. Estoy completamente de acuerdo con estas palabras. Sobretodo pues tengo alguna experiencia en trabajar con grandes consultoras informáticas del panorama nacional y mucha de la gente de base con la que cuentan son de un nivel medio-bajo y el ambiente de trabajo en el que se encuentran les hace migrar a compañías más pequeñas. Sin duda Google es un gran ejemplo a seguir en su cuidado del trabajador y en su enorme inversión en recursos humanos.

Bernardo habló también de que un camino futuro que Google va a tomar sin duda es la integración con redes sociales. Aquí dejó una pulla a Facebook por no devolver lo que Google les había dado.. pero bueno, siendo participante de Tuenti creo que esos comentarios sobraban totalmente. En cualquier caso me parece muy interesante poder llegar a indexar toda la información presente en las redes sociales. Hoy en día se está convirtiendo en una fuente de conocimiento bastante grande. Sobretodo desde el punto de vista estadístico para las agencias de publicidad.

El turno de preguntas fue por desgracia demasiado corto y me quedé con las ganas de preguntar acerca de Google Wave y el impaco que Bernardo creía que podía tener en el día a día de un usuario habitual. Por suerte luego puede hablar con él unos segundos y me comentó su impresión, que se acercaba mucho a lo que pensé cuando conocí el producto, y es que está más orientado a entornos corporativos. En la Uji queremos utilizarlo para el aprendizaje de lenguas pues sus posibilidades son muy grandes. Espero un día poder escribir una entrada en el blog con más información al respecto.

Igual que hice en el primer iniciador de nuevo me gustaría muchísimo felicitar al equipo de Iniciador Castellón (Pep Gómez, Carlos Matallín y Álvaro Verdoy) y a sus patrocinadores: TISSAT, Patronato de Turismo del Ayuntamiento de Castellón y Search Congress. Desde estas líneas dar las gracias a todos por traernos a este Gurú a Castellón y también desde estas líneas ofrecer la ayuda de Sinergics para próximos iniciadores.

Android o iPhone esa es la cuestión

Llevo unos días queriendo crear una entrada en el blog donde poder expresar mi opinión sobre esta nueva oleada de dispositivos móviles que está apareciendo en el mercado.

Desde un punto de vista de desarrollo podríamos hacer una clasificación de las plataformas móviles más comunes:

• iPhone
  
• Android
• J2ME
• Windows Mobile
• Symbian (Nokia)
  
• Blackberry

Mercado objetivo
Algunas de ellas tienen unos tipo de móviles objetivo con características muy diferentes entre si.

• iPhone y Android compiten en un mismo mercado de móviles conectados siempre a Internet. Estos dispositivos suelen venir de la mano de una tarifa plana de Internet asociada y cuentan con GPS, pantalla táctil, acelerómetro y una resolución mínima de 480x320.
• J2ME sea quizás el mercado más amplio pues la mayoría de los dispositivos con los que cuentan los usuarios domésticos permiten la ejecución de aplicaciones Java J2ME.
  
• Windows Mobile se encuentra en dispositivos PDA tanto conectados como no conectados. Estos dispositivos, si bien pueden conectarse a Internet mediante 3G por ejemplo, nacieron en unos años donde esto no era posible y su mercado creo que ha sido condicionado por este aspecto. Luego lo comento.
• Blackberry son una familia de dispositivos con una tarifa de correo asociada y que se encuentran que tanto Android, como iPhone y .NET están dentro de su mercado.
• Symbian es el sistema operativo creado por Nokia y presente en todos sus dispositivos en distintas variantes (las llamadas series)

Habiendo introducido estos dispositivos creo que es un secreto a voces que algunas de estas plataformas van a ir poco a poco cayendo en el olvido.

Sobre Android y iPhone creo que el tiempo juega completamente a su favor. La llegada de Internet a los teléfonos móviles los coloca en una posición envidiable. El sistema operativo está pensado para este caso de uso. Así, en el último año y medio han aparecido muchas más aplicaciones para estos dispositivos que para el resto de plataformas en la década que llevan de vida. A continuación podéis ver una gráfica que aparece en la siguiente noticia http://telecompk.net/2009/06/22/comparison-of-android-and-iphone-application-usage/

Lo que esta gráfica viene a denotar es que el número de aplicaciones para esta nueva gama de dispositivos ya representa el 95% de las aplicaciones disponibles. La razón es una plataforma bien pensada desde un inicio, orientada a dispositivos con conexión y un mecanismo muy sencillo para instalar nuevas aplicaciones (App Store y el Android Market).

J2ME es la plataforma más antigua de todas y la que, a pesar de su fama, ha hecho las cosas no mal sino peor. Soy un fan de Java desde hace mucho tiempo pero no me impide ver con claridad que todo el ecosistema de aplicaciones J2ME es una auténtica chapuza debida a su fragmentación. Crear una aplicación J2ME que funcione en cualquier dispositivo es una locura. La culpa realmente no es sólo de la especificación que a veces no es muy específica sino yo lo achacaría a Sun Microsystems al no forzar una certificación en los dispositivos que prometiendo ser compatibles con J2ME presentaban innumerables bugs y diferencias con la especificación. J2ME seguirá en el mercado por algunos años pero tiene el futuro muy negro. No está pensada para la nueva generación de dispositivos. Sinceramente, es un favor para los desarrolladores que vaya desapareciendo del mapa.

Windows Mobile es otra plataforma, al igual que J2ME, estaba al borde del abismo con la aparición de iPhone y con la nueva oleada de dispositivos de Android pero el poder que tiene Microsoft en el mercado creo que la hará sobrevivir. Su control sobre el canal de distribución le hará que grandes fabricantes como HTC sigan distribuyendo su sistema operativo y ahí estará, en mi opinión a la sombra de iPhone y Android pero estará. Probablemente siga teniendo más cabida en el ámbito empresarial en el que su conexión con Exchange y sus conectores a ERPS y CRMS hagan que se posicione cada vez más como un dispositivo de trabajo que no de ocio. En los próximos meses probablemente aparecerá una tienda online de aplicaciones para Windows Mobile pero como siempre yendo a remolque del resto habrán llegado tarde, muy tarde.

Blackberry ha ocupado de forma muy inteligente una posición en el mercado de telefonía móvil. Dispositivos con capacidad para leer correo electrónico. Esto hace un año o dos años podía ser un buen reclamo para las empresas pero creo que ahora es muy poco peso. Android, iPhone y Windows Mobile pueden ofrecer lo mismo, con una interfaz de usuario más amigable y con mucha más funcionalidad. En mi opinión es la plataforma junto con J2ME con menos futuro.

Symbian, de forma similar a Motorola en la década de los 80 y los 90 lo tenía todo para ganar cualquier batalla. Se confiaron, se relajaron y les adelantaron. Con el amplio mercado del que ha gozado la compañía finlandesa una buena inversión en innovación les habría posicionado primeros en la carrera por los dispositivos de nueva generación. Sin embargo, en mi opinión, han estado desarrollando el mismo tipo de dispositivo durante 10 años. Se han mejorado las pantallas, las cámaras, aparición de GPS, pero sus dispositivos apenas han innovado. Todavía recuerdo la llegado de los N70 o los N90 que prometían una experiencia sin igual. Cuando tenías uno en la mano te dabas cuenta de que eso iba lento, era poco usable,... Sólo cabe comparar con la primera vez que cuentas con un iPhone o un Android. Es distinto, aire nuevo, un mundo nuevo de posibilidades.

iPhone o Android
Esta es una pregunta bastante habitual y que no ciertamente no sabría responder.

Habiendo trabajado con ambos dispositivos desde el punto de vista de usuario y habiendo programado para ambas plataformas (Cocoa Touch y Android) sólo puedo decir que es una gozada trabajar con ellos.
iPhone lleva más tiempo en el mercado, el dispositivo es muy potente y el sistema operativo tremendamente estable. La tienda de aplicaciones (App Store) centraliza todas las aplicaciones y la instalación es simple. Android acaba de aparecer este año y básicamente cuenta con lo mismo, un sistema estable, una tienda de aplicaciones muy práctica y que en la nueva versión del sistema operativo (la 1.6 también llamada Donut) mejora sensiblemente...

Creo que ambas plataformas han llegado para quedarse por mucho tiempo. Desde el punto de vista empresarial el iPhone es mejor plataforma porque es más fácil vender aplicaciones. Hay un elevado número de usuarios que están familiarizados con la compra de aplicaciones/canciones mediante iTunes o a su modelo de negocio Mac. Una cosa que me pareció muy interesante es que incluso sus actualizaciones sean de pago ¿y esto por qué? Sencillo, para instalarte la última actualización es necesario introducir tus datos bancarios para poder comprar dicha actualización. Estos datos se asocian a tu usuario y se guardan ¿y qué tiene esto de bueno? Para una empresa que se dedique a desarrollar aplicaciones mucho. En el momento que un usuario ya se ha habituado a hacer una compra, ya ha introducido sus datos... la posibilidad de que se decida a pagar 1 Euro por una aplicación ascienda exponencialmente. Si ese euro lo multiplicas por los miles de usuarios con los que cuenta la plataforma el negocio está más asegurado.

En Android la cosa es diferente y los usuarios son menos propensos a realizar estas compras por lo que de ahí que aplicaciones comerciales del Top Ten del Android Market consigan 50 euros al mes. Una noticia que acabo de encontrar referida a esto: http://alt1040.com/2009/09/comparaciones-incomodas-iphone-app-store-vs-android-market


La apuesta de Sinergics
La apuesta de Sinergics es el desarrollo de aplicaciones tanto para iPhone como para Android. Si bien el mercado de Android es inferior al de iPhone en estos momentos creo que la nueva llegada de dispositivos (se estima 50 nuevos modelos el año que viene) hará que poco a poco la balanza comience a igualarse. En los próximos meses seguramente daremos algún detalle de las nuevas aplicaciones que estamos desarrollando y también sobre cursos que queremos ofrecer aquí en Castellón sobre ambas tecnologías.

Los desarrollos sobre las otras plataformas (sobretodo J2ME y Windows Mobile) se seguirán haciendo en tanto en cuanto los clientes lo pidan pero nuestra intención es ir migrando tal y como se ha dicho, a iPhone y Android.

Estado de tucongreso.es

Hace ya un mes del último post y es un buen momento para comentar las últimas noticias sobre el proyecto en el que se está trabajando con tanto empeño.

Aunque la página tucongreso.es no está visible todavía la primera versión del sistema ya está funcionando en un congreso que se celebrará en octubre en La Rioja. El sistema se podrá utilizar en breve desde el dominio tucongreso.es pero da la posibilidad de integrarse en páginas ya existentes, un requerimiento por parte de muchos congresos para conservar la estética de la página en todas las secciones.




Voy a tratar de explicar toda la funcionalidad que tiene implementada hasta la fecha y la que falta por incluir.

Para los que no han leído el post anterior, tucongreso.es es un sistema para la organización online de congresos. Esto es, para gestionar a través de Internet todos los datos de un congreso, desde los usuarios y la inscripción al congreso, como el envío de propuestas, gestión del horario, etc.

Voy a utilizar el listado de funcionalidades del post anterior para así describir cada uno con un poco más de detalle.

• Gestión del flujo de envío de textos. Desde que una propuesta se envía hasta que es aceptada puede suponer diversos pasos sobretodo si además del envío de propuestas también se requiere del envío de los textos completos, para llevar a cabo una posterior publicación. Todos estos pasos se registran en la base de datos de forma que en todo momento se puede consultar su estado. Cuando una propuesta se envía por primera vez pasa a un estado enviado pero pendiente de revisión. Cuando el revisor la consulta, si utiliza evaluadores, puede enviar la propuesta a los evaluadores pasando a un estado de enviada a evaluación. Cuando los evaluadores han enviado la evaluación al revisor se pasa a un estado de evaluada y pendiente de revisión. Tanto si ha utilizado evaluadores como si no, hay una persona responsable de tomar la decisión de aceptar, rechazar o pedir cambios a una determinada propuesta. Cuando toma una de estas decisiones la propuesta vuelve a cambiar de estado e indicar por ejemplo que ya ha sido aceptada. Si de esta propuesta luego tiene que enviarse el texto completo el procedimiento es bastante parecido. Esta gestión de estados es utilizada en otros puntos del sistema como el envío de correos o la sección de estadísticas. Gracias a este estado se puede saber en todo momento el estado actual del congreso. Como ya veremos en posteriores puntos, estos cambios de estado desencadenan eventos que se guardarán en la base de datos para trazabilidad y suelen conllevar el envío de algún correo electrónico a los interesados.
  
  
• Gestión de usuarios, roles y permisos. En un sistema para la organización de congresos intervienen distintos tipos de usuarios. Por una parte tenemos a los organizadores del congreso, a los revisores, a los evaluadores, a los ponentes, plenarios,... Cada uno de estos usuarios puede llevar a cabo sólo una serie de acciones en el sistema.
  Cualquier funcionalidad del sistema está protegida de forma que sólo se puede acceder a ella cuando se tienen los permisos apropiados. Así, los organizadores del congreso pueden consultar los detalles de todas las propuestas, los participantes sólo sus datos enviados,... Para los menos acostumbrados a estos términos un usuario tiene una serie de roles y un rol tiene un conjunto de permisos asociados, de forma que los permisos de un determinado usuario se definen por los roles que posee. Aunque hay variantes este es el procedimiento más usual. Inicialmente se cuenta con una serie de roles ya configurados y que cubren seguramente el 90% de los congresos pero ante cualquier requisito especial de un congreso en particular se puede añadir un nuevo rol con los permisos necesarios.
• Redacción online de abstracts. Los congresos pueden configurar el envío de abstracts de forma que sea online. Esto es, los usuarios escriben el abstract directamente en la página web, sin necesidad de enviar un PDF, Word, ODT,... Los textos completos tiene mucho menos sentido pues las necesidades de formateo son mucho más amplias. Esta redacción online permite, de forma sencila, generar automáticamente el libro de abstracts partiendo de tanto el asbtract como la información de los autores que está guardada en la base de datos.
• Generación automática de libro de abstracts. Tal y como se ha comentado en el punto anterior, gracias a la redacción online de abstract se permite generar automáticamente el libro de abstracts para aquellos congresos que así lo requieran.
• Soporte multi-idioma. Los congresos suelen ser eventos donde interviene gente de muchas nacionalidades. Así, es muy necesario que la página pueda incorporar tantos idiomas como sea necesario. El sistema cuenta con un motor de internacionalización (i18n) de forma que todo texto que se muestra en pantalla es un recurso de traducción. Antes de mostrarse en pan y dependiendo de las preferencias del usuario, se traduce a su idioma. En el momento de registro en el congreso el usuario puede indicar este idioma de preferencia. Gracias a este dato, todos los correos automáticos que se le envían se hará en su idioma de preferencia, ayudando lo máximo posible.


• Gestión de plantillas de correos. Durante el proceso de registro de usuario, envío de propuestas, aceptación o rechazo de estas, envío de textos completos, asignación de horarios,... se produce un intercambio muy importante de correos electrónicos. Además de la personalización de la parte visual de la página (fuente, imágenes, paneles,...) todos los correos que se intercambian pueden personalizarse. Inicialmente se cuenta con un texto por defecto que puede ser utilizado pero si en un momento determinado alguno de los correos intercambiados se quiere personalizar, cada congreso puede definir los suyos. Para poder permitir esta personalización el sistema incorpora un motor de plantillas. Cada asunto y cada mensaje de un correo está definido en la base de datos y cada congreso puede utilizar el que hay por defecto o bien escribir el suyo propio. Hay ciertos campos de cada correo que pueden ser dinámicos como el nombre del autor, el título del texto,... Para poder tratar estos campos cada plantilla cuenta con una serie de parámetros que se pueden incorporar o no de forma que cuando se envíe el correo el sistema convierta estos parámetros a su valor real.
  
  
  
  
  


• Historial de acciones (trazabilidad). Recurriendo de nuevo a Murphy cuando algo malo tiene que pasar pasará. Hay algunos casos en los es necesario saber cuándo se envió un determinado artículo, cuándo el director de panel lo aceptó/rechazó, cuando se envió una nueva versión del texto completo... En resumen, controlar todo el flujo de acciones que el sistema permite llevar a cabo. El sistema cuenta con un sistema de registro de eventos de forma que cada vez que un evento relevante ocurre se guarda en la base de datos. El organizador del congreso podrá en un momento determinado consultar este historial de eventos para poder solucionar algún problema o duda que pueda surgir.
  
  



• Gestión de autores y coautores. En las primeras páginas que programamos para la organización de un congreso fue uno de los requisitos que se vio con el tiempo que no estaba perfectamente recogido. Un paper en un congreso suele estar firmado por varias personas e inicialmente los datos de estas personas se recogían de forma vaga. Básicamente su nombre y apellidos. Esto luego puede conllevar problemas, por ejemplo, cuando se generan todos los certificados, cuando se escriben las actas del congreso, para gestionar los pagos del congreso... Por ello, el sistema permite vía configuración obligar a que todos los coautores de un determinado texto sean usuarios ya existentes. Esto luego se refleja en las estadísticas, inscripciones, generación de certificados... Un consejo: si crees que un dato no va a ser necesario lo será. Ley de Murphy.



• Gestión de paneles o áreas temáticas. En ciertos congresos las ponencias se dividen en áreas temáticas o paneles. Suele ser común en aquellos congresos menos específicos donde las ponencias cubren un amplio número de campos. A través de la página se permite indicar si el congreso utiliza paneles o no e indicar el nombre de cada uno de ellos. Enlazando con el punto de la seguridad, los roles se pueden asociar a un determinado panel en lugar de que se apliquen de forma global al congreso. Por ejemplo, el rol organizador del congreso, que tendría asociados por defecto permisos como listar los usuarios, consultar las inscripciones, gestionar el horario... se aplica de forma global a todo el congreso, sin embargo un rol como revisor (llamado muchas veces director de panel) se asociaría a un determinado panel de congreso de forma que permisos como aceptar propuesta, rechazar propuesta sólo se aplicarían a aquellas propuestas que se han enviado a su panel. Por lo tanto, no podría aceptar, ni rechazar las propuestas de un panel distinto al suyo.
  


• Gestión de asistentes no ponentes. Como los asistentes a un congreso no es necesario que presenten paper también se tiene en cuenta esta necesidad y a través de la página un asistente que no va a presentar ningún trabajo se puede registrar. La distinción entre asistente ponente y no ponente se refleja en la base de datos. Esto es así porque el pago en muchos casos es distino y porque estadísticas sobre este tipo de asistentes son muy importantes para la organización de un congreso.
• Generación automática de certificados. Otra funcionalidad que ahorra mucho trabajo en muchos congresos es la generación automática de certificados. Gracias a todos los datos almacenados en la base de datos el sistema permite generar un certificado para cada uno de los asistentes. Cada congreso puede crear su propia plantilla (bien en formato ODT, Word o HTML) e incluso definir plantillas distintas por roles, pudiendo generar un certificado distinto para ponentes, directores de panel, asistentes, plenarios, becarios,...



• Envío de correos online a usuarios. En un momento determinado del congreso puede ser necesario enviar un correo electrónico a todos los asistentes, o a todos los ponentes de un determinado panel, o bien a todos los asistentes que todavía no han pagado... Así, se cuenta con una página para el envío de correos a usuarios utilizando un potente mecanismo de filtros. Así, además de indicar el asunto y el cuerpo del mensaje se puede seleccionar los usuarios a los que va a ir dirigido el mensaje. Esto evita tener que enviar un mensaje a todos los usuarios cuando sólo una parte de estos son los interesados o tener que utilizar exclusivamente la web para enviar una cierta noticia.
  
  
  



• Estadísticas del congreso. Otra sección obligada de la página y muy útil de cara a los organizadores es la de las estadísticas del congreso. En esta página se puede llevar un seguimiento de los usuarios, ponentes, propuestas aceptadas, rechazadas,... Un amplio número de estadísticas que pueden servir al organizador para tomar decisiones, para comparar con ediciones anteriores...
  

A pesar de que se ha dado un paso muy grande con la primera versión del sistema hay funcionalidades que todavía no han sido incorporadas pero que en unas pocas semanas se irán incorporando paulatinamente:

• Gestión de horarios
• Aplicación móvil
• Conexión con sistema de pagos
  

Nuevo proyecto: tucongreso.es - Organizador de congresos online

Quería explicar en el blog uno de los proyectos que tenemos entre manos y que nos está ocupando estas últimas semanas. Se trata de tucongreso.es un organizador de congresos online.

Desde hace 4 años colaboro a modo personal y ahora Sinergics de forma profesional con AESLA (Asociación Española de Lingüística Aplicada). Esta asociación, de casi 800 socios organiza anualmente un congreso al que asisten cerca de 250 personas. Este congreso se divide en 10 áreas temáticas (o paneles) que se pueden consultar en la página de la asociación. Aquellas personas que quieren exponer trabajos en el congreso envían un resumen de la ponencia a uno de estos paneles, concretamente a uno de los directores del panel que lo acepta o rechaza. Después de enviar la propuesta, unos meses más tardes se abre el plazo para enviar la versión ampliada de esta propuesta (lo que llamamos texto completo). El proceso es similar, se envía al director del panel correspondiente que lo acepta y/o rechaza. Este texto completo se envía para unas actas que se publican posteriormente al congreso.

Hasta el año 2008 el envío de estos resúmenes y textos completos se envíaban a través de correo postal, algunos a través de e-mail,... En ningún momento el organizador del congreso conocía el estado real en el que se encontraba el congreso.

El año 2008 implementé un sistema para el envío de propuestas y textos completos que informatizaba todo el proceso. Directores de panel, organizador del congreso, junta directiva, socios y no socios de AESLA contaban con usuario/contraseña para poder enviar los textos al congreso. Ante cualquier evento que se producía en el sistema (envío de propuesta, aceptación/rechazo de propuesta, envío de texto completo,...) se envíaba un e-mail a los interesados.

Habiendo funcionado satisfactoriamente en el año 2008 este año se le ha dado una vuelta de tuerca a la funcionalidad ampliándola considerablemente. Gestión de pagos, ampliación de las estadísticas del congreso, envíos de correos por criterios (participantes con propuestas aceptadas, participantes que no han pagado,...).

Gracias a la experiencia en este congreso y las experiencias que nos están transmitiendo otras personas de la universidad surge el proyecto de tucongreso.es. En desarrollo actualmente, la idea es construir una plataforma para la organización de congresos online.

Esta plataforma nace con la flexibilidad como uno de sus pilares fundamentales. En un primer análisis de requerimientos comprobamos como hay varios aspectos en los que divergen la mayoría de los congresos y por eso, desde un primer momento, la funcionalidad de la plataforma se está haciendo muy parametrizable. Áreas temáticas, gestión de usuarios, roles y permisos, gestión de asistentes no ponentes, gestión de autores y coautores,... funcionalidades que en algunos casos serán necesarias y que para otros congresos no tienen sentido.

En las próximas semanas os iremos dando más detalles de la plataforma pero de forma esquemática estas son las funcionalidades definidas en el primer análisis de necesidades:

• Gestión de usuarios, roles y privilegios
• Gestión de autores y coautores
• Gestión de asistentes no ponentes
• Gestión de paneles o áreas temáticas
• Redacción online de abstracts
• Historial de acciones (trazabilidad)
• Generación automática de libro de abstracts
• Gestión de horarios
• Generación automática de certificados
• Conexión con sistema de gestión de pagos (TPV)
• Soporte multi idioma
• Envío de correos online a usuarios
• Estadísticas del congreso
• Aplicación móvil con información del congreso
• Personalización de e-mails automáticos

También indicar que toda la programación se está haciendo sobre Symfony. Este proyecto nos está sirviendo para explotar realmente la potencia de este fabuloso framework. No quiero ni imaginarme el estado en el que se encontraría el proyecto de no ser por Symfony.

Seguiremos informando.

Hasta ahora!

Soporte remoto con VNC y uso de túneles SSH

En una de mis visitas a Otime en Segovia me enseñaron una variante de soporte remoto que no conocía y sencillamente me encantó. He usado VNC desde hace muchos años pero tiene un problema importante cuando quieres ofrecer soporte a clientes y es cómo acceder a ordenadores que están en una red local detrás de un router/firewall. La solución consistiría en cambiar la configuración del router para que redireccionara los puertos a las máquinas locales pero creo que estaréis conmigo cuando pienso que no es una solución factible.

Pues bien, en Otime me enseñaron el uso del VNC inverso. Lo conocía con SSH pero no caí en que fuera posible hacerlo con VNC. La idea es que en lugar de iniciar tú la conexión al ordenador del cliente sea el cliente el que inicie la conexión contigo y luego tomes el control de su ordenador. Esto es mucho más factible pues sólo es necesario modificar las reglas del firewall en un sitio, en tu oficina. Además tiene otro punto muy favorable y es que es gratis. Hay varias soluciones de helpdesk en el mercado pero de esta forma, aunque algo más compleja, te lo haces tú mismo.

Las formas de hacer este VNC inverso son distintas dependiendo del cliente que utilices. Yo voy a explicar el uso de Ultra VNC y su addon Single Click. Ultra VNC te ofrece un .zip a modo de distribución para que lo personalices con los logos, los mensajes en tu idioma,... y mediante su página web te generas un .exe ya configurado como el que se ve en la imagen siguiente.


Las instrucciones están detalladas en http://www.uvnc.com/addons/singleclick.html por lo que no merece la pena que las repita pero únicamente decir que es sencillísimo. Este Single Click representa al programa que tiene que ejecutar el cliente. En cuanto a Sinergics lo que tenemos es un script que arranca winvnc indicando que escuche en un determinado puerto (el mismo que se pone en la configuración del Single Click).
> vncviewer -listen 8888

Por lo tanto, a modo resumen:
- Llama el cliente indicando que tiene un problema y requieres controlar su ordenador.
- Arrancas el VNC en modo escucha.
- Le indicas que se descargue de la página web el ejecutable y que lo abra.
- Cuando lo ha abierto tendrás el control de su máquina.
- Justo antes de dejar de tener el control de su máquina le cierras el cliente de VNC por si las moscas.

Un esquema gráfico muy sencillo de cómo quedaría la cosa:



Hasta aquí todo bien pero... muchas veces me encuentro que estoy en la universidad, donde me conecto a través de una VPN y mi máquina no es accesible desde el exterior por políticas de seguridad. La única forma de ver acceder a máquina es desde otra máquina a la que sí que se tiene acceso desde fuera, pero únicamente vía SSH ¿Eingg? Pues sí, esto me ha pasado.

La solución a la que he llegado, por lo menos la única que se me ocurrió fue la siguiente... Tengo un servidor privado alojado en Internet con control total sobre él. Lo que decidí hacer fue crear un túnel SSH desde un puerto, por ejemplo 8989 de forma que cuando alguien se conecte a este puerto se redirija los datos a mi máquina pasando a través del ordenador de la universidad que está visible a través de SSH. La orden es algo así:
ssh -L IP_PUBLICA_DE_MI_SERVIDOR_PRIVADO:8989:IP_DE_MI_MAQUINA:PUERTO_ESCUCHA_VPN
usuariomaquinauniversidad@ipuniversidad

Como ni yo mismo entiendo este párrafo después de escribirlo voy a pegar otro diagrama para que quede algo más claro.



Lo que he hecho es configurar el SingleClick con la IP y puerto del servidor que tengo contratado y entonces cuando el cliente se conecta a dicho puerto el túnel se conecta con mi máquina local pasando a través del servidor de la universidad que es el que hace de túnel.


ACTUALIZACION
Indagando un poco más he encontrado otra solución más sencilla para el caso en el que no te encuentras en la oficina y que es en mi opinión más práctica . Consiste en utilizar un túnel SSH inverso.

El funcionamiento de un túnel SSH es más o menos el siguiente. Desde una máquina A quieres acceder a una máquina C, pero A no ve a C. Sin embargo A ve a una máquina B que esta a su vez ve a la máquina C. A haría un túnel utilizando a B de forma que mapea un puerto local de la máquina A con un puerto de la máquina C. Si A hace un telnet por ejemplo a dicho puerto local el túnel SSH configurado lo que hace es enviarlo a la máquina B que a su vez lo envía a la máquina C. B hace las veces de mensajero.

Pues bien, el túnel SSH inverso hace algo parecido. En el caso del túnel normal lo que haces es permitir a A que se conecte con C. En el túnel inverso lo que haces es preparar a A para que pueda recibir datos de C enviando dichos datos a través de B (que es pública). Con el ejemplo de la VPN quedará más claro. Me voy de viaje y estoy en las oficinas de un cliente. En este entorno no puedo tocar el router de la oficina y mi máquina no es visible desde fuera. Necesito conectarme con un cliente con el VPN inverso (luego el cliente tiene que iniciar la conexión conmigo). Lo que hago es crear un túnel inverso desde mi máquina al servidor privado que tengo contratado y que es público. Este túnel lo que hará es mapear un puerto de dicho servidor remoto de forma que cuando alguien se conecte a dicho puerto reenvíe los paquetes a mi máquina. Realmente que esta máquina me envíe datos no se puede hacer sin túnel porque mi máquina no es visible desde fuera pero al iniciar yo la conexión mediante el túnel inverso ya pasaría a ser visible.

La sintaxis del ssh inverso, que se ejecutaría desde mi máquina local, es la siguiente.
ssh -R IP_MAQUINA_PUBLICA:8989:localhost:8888 usuariomaquinapublica@IP_MAQUINA_PUBLICA

Lo que indica es que cuando alguien acceda al puerto 8989 de la máquina remota el túnel reenvíe dicho dato a mi puerto 8888 que es donde tendría escuchando el UltraVNC con el -listen 8888.

Otra cosa a tener en cuenta es que hay que modificar la configuración del sshd tal y como indica la página man. Por defecto la máquina remota sólo escucharía este puerto mediante la loopback interface.

By default, the listening socket on the server will be bound to
the loopback interface only.  This may be overriden by specifying
a bind_address.  An empty bind_address, or the address '*', indi-
cates that the remote socket should listen on all interfaces.
Specifying a remote bind_address will only succeed if the
server's GatewayPorts option is enabled (see sshd_config(5)).

Espero que os haya servido de ayuda este post.

Uso de Symfony en Sinergics.com

Alguno de nuestros colaboradores me ha preguntado qué es eso de Symfony que aparece en el pie de nuestra web.


Symfony es un framework para la creación de aplicaciones Web que conocí hace unos 4 meses aproximadamente. Llevo programando en Java desde hace más de 7 años y el hosting disponible de esta tecnología es escaso y bastante caro. Esto, añadido a que en la universidad el alojamiento en sus servidores sólo permite PHP me hizo formarme en este lenguaje hace varios años.

Quizás por los vicios a los que te acostumbra Java busqué IDEs y frameworks para que formaran parte de mi batería de utilidades. Después de programar "a pelo" durante estos años y tras comparar todo lo que vi disponible elegí Eclipse y Symfony como mis herramientas de trabajo.

De Eclipse espero hablar en sucesivos posts porque es de las cosas más grandes que ha creado la informática en los últimos tiempos. A modo resumen diría que es una plataforma para la creación de entornos de desarrollo. El más conocido es el plugin de Java para poder trabajar con este lenguaje pero otros lenguajes como C, C++ y PHP son soportados con sus plugins correspondientes. El plugin de PHP utilizado es PDT.

Symfony, como he dicho anteriormente, es un framework para la creación de aplicaciones web. Es una implementación desde mi punto de visto muy acertada del patrón MVC (Modelo Vista Controlador).

Empezamos por el modelo. Para trabajar con bases de datos utiliza los ORM (Object-Relationship Mapping) Propel o Doctrine. Estos frameworks sirven de puente entre el mundo de la orientación a objetos y las bases de datos relacionales. Permiten mapear clases con tablas de la base de datos y por consiguiente instancias de estas clases (objetos) con registros de las tablas.
Evitan mucho del famoso glue-code al permitir definir la estructura de una base de datos en unos ficheros de configuración (por ejemplo xml) y autogenerar los sql para crear la base de datos. También crear los ficheros PHP que representan cada una de las clases del modelo con sus correspondientes métodos save, update... Esto, junto con el API de Criteria para hacer las búsquedas da una flexibilidad enorme para trabajar con la base de datos.

Cada página de la aplicación se separa en dos partes básiscamente: acción y plantilla. La acción es el código php que se invoca cuando se llama a la página y es la responsable de acceder al modelo y dar el resultado a pintar a la vista que sería la plantilla. Por lo tanto la acción es el controlador del MVC. De esta forma tienes el controlador perfectamente localizado dentro de un proyecto Symfony.

En cuanto a la vista Symfony ofrece un mecanismo de layout (o master-pages) muy potente. Puedes definir una página de plantilla con la cabecera y el pie y especificar el lugar donde se pintará el contenido de cada una de las páginas de las que constará la aplicación web. Estos layouts no son para nada estrictos. Mediante el uso de slots puedes definir sitios dentro del código donde las páginas pueden insertar código (muy útil si por ejemplo quieres cambiar el title en alguna de las páginas). Un paso más de flexibilidad está en el uso de componentes pero no viene al caso en esta entrada.

Otro de los módulos que ofrece Symfony y que me parece muy interesante es el de routing. De forma declarativa te permite definir las páginas de las que consta la web, qué parámetros acepta, cuál es la url,... Cada una de las páginas tiene un identificador unívoco que puede ser utilizado desde las propias páginas para referenciarlas sin conocer su URL. Esto permite modificar las urls de las páginas de forma sencilla. Esto es una gran ventaja para trabajar con SEO..

Otra de las características que más agradezco a Symfony es la capacidad de crear distintos entornos de aplicación. Después de trabajar en proyectos en La Caixa y Caja Navarra donde en un aplicativo nos podíamos encontrar con hasta cuatro entornos de desarrollo distintos (test, integración, preproducción y producción) es una funcionalidad que busco en todas las herramientas. Symfony te permite configurar la aplicación de forma distinta dependiendo de en qué entorno te encuentras y utilizar uno u otro sólo invocando una url de inicio distinta. En el caso de la web de Sinergics tengo definidos dos entornos, uno de test, para hacer pruebas en local, y otro de producción, que es donde está alojada la web. Cada entorno trabaja con una base de datos distinta. A lo hora de mostrar los errores también la configuración es distinta, en local se obtiene un stacktrace mientras que en remoto sólo te muestra que ha habido un error,... Los logs también son distintos, el uso de la caché es completamente diferente. Es un mecanismo realmente potente.

Otra de las herramientas más interesantes de Symfony es el generador de formularios. Dada la estructura de la base de datos crea los CRUDs (Create-Replace-Update-Delete) para cada una de las tablas. Estos CRUD son luego fácilmente configurables por lo que ahorran mucho tiempo en el desarrollo del backend de una aplicación.

Espero encontrar el tiempo para explicar con más detalle lo que es Symfony en sucesivos posts.

Sólo dar las gracias a todo el equipo de Symfony y especialmente a Fabien por este magnífico framework.

Hasta ahora!