Open Source al rescate

Open Source al rescate

El objetivo principal de este artículo es presentar un panorama sobre las herramientas de software libre u open source, relacionadas con la generación de un ambiente de desarrollo integral, que cubra las diferentes etapas involucradas en la creación de software.Aunque la mayor parte de las herramientas mencionadas son ampliamente utilizadas hoy en día, otras no cuentan con el mismo nivel de difusión y adopción. Sin embargo, la intención es destacar el impacto que tienen todas ellas en relación con el desarrollo colaborativo. Vale la pena resaltar que, estas herramientas no sólo son exclusivas para el desarrollo de proyectos open source, sino que se pueden utilizar para cualquier tipo de proyecto.

Un vistazo a las diferentes necesidades
Desde un punto de vista muy simplista y, sin estar apegado a alguna metodología específica, podemos identificar las siguientes etapas en el ciclo de vida de un proyecto:
•Planeación y costeo.
•Diseño y arquitectura.
•Desarrollo y pruebas unitarias.
•Estabilización y pruebas de estrés.
•En vivo (ya en producción).
•Carga real, uso real, ambiente real ...
•Detección de errores, cambios, mejoras ...

¿Cómo seleccionar las mejores herramientas para cada una de estas etapas? Las revisiones de producto son útiles, pero no son la última palabra, porque cada situación es única (como los proyectos), y los procesos de adopción en cada organización son muy variados. Algunos de los aspectos a considerar dentro de esta gama son: metodología y procesos; presupuesto para hardware-software, infraestructura actual; tamaño de proyectos y equipos de trabajo.

A pesar de estas limitantes para la selección de herramientas, lo que está claro, es que debemos seleccionar aquéllas que nos ayuden a producir, conservar y administrar todo el material generado en los proyectos, así como los que promuevan la estandarización en el uso de las mismas.

Herramientas de colaboración
Comencemos por mencionar algunas herramientas orientadas a coordinar y facilitar la colaboración entre los miembros de un equipo de trabajo. Aquí tenemos las siguientes categorías:

Control de versiones
El control de versiones es uno de los pilares de un buen desarrollo de software. Usado de forma adecuada, proporciona una bitácora de todos los cambios realizados a la documentación y al código fuente, siendo así una gran ayuda para la corrección de bugs. Una recomendación adicional es que todos los artefactos de los proyectos (código fuente, contenido estático, scripts para builds, documentación de análisis y diseño, material de cursos, acuerdos con el cliente, etcétera) sea administrado con una herramienta de control de versiones.

Hoy en día existen dos grandes tecnologías para el control de versiones: CVS y Subversion; la primera de ellas es prácticamente de adopción universal; la segunda, cuenta con algunas mejoras de implementación que la colocan como el sucesor natural de CVS. Entre las características comunes están:
•Repositorio central accesible vía Internet.
•Resolución de conflictos vía “merging”, en lugar del concepto de “locking”.
•Gran diversidad de clientes multiplataforma para acceder a los repositorios.

Entre las principales diferencias a nivel conceptual (no de implementación), está el reemplazo de etiquetas (tags) y ramas (branches) de CVS por simple copiado y renombrado de archivos y directorios en Subversion.

Issue tracking
Utilizado para manejar las listas de pendientes a resolver y las solicitudes de mejora. Es indispensable contar con visibilidad de los asuntos por resolver, así como un mecanismo automatizado de asignación de tareas y notificación de alertas. Toda esta funcionalidad la provee una herramienta como Bugzilla, la cual fue originalmente desarrollada para atender las necesidades del proyecto Mozilla, y ahora se ha convertido en la herramienta por excelencia para manejo de issues. Los usos que se le pueden dar a la herramienta son muy variados: los desarrolladores pueden rastrear defectos o bugs; los usuarios solicitan soporte, asignación de tareas de codificación y/o corrección, control de actualizaciones o parches y discusión sobre posibles mejoras.

Discusiones técnicas
En este rubro se pueden utilizar una diversidad de mecanismos que promuevan el entendimiento técnico del proyecto, así como la facilidad de dejar evidencia escrita del por qué se tomaron ciertas decisiones a lo largo del proyecto. Dentro de estas posibilidades nos encontramos los sitios web por proyecto, los foros de discusión, las listas de correo, HowTo’s y FAQ’s.

En lo personal, me gusta la utilización de una lista de correo por proyecto, ya que es tan accesible y cotidiano como el correo electrónico, con la gran ventaja de dejar un histórico de las discusiones en web. Una de las opciones más utilizadas para generar estas listas de correo es MailMan, que ofrece una interfaz web para utilizar listas de correo electrónico, diversas opciones de entrega y suscripción a las listas. Otra alternativa de más reciente aparición son los grupos de Google, que además de proporcionar la funcionalidad de listas de correo, permite adjuntar archivos y crear páginas (tipo Wiki) desde la misma interfaz web.

Herramientas de desarrollo
En cuanto a las herramientas de desarrollo se refiere, existen una infinidad de posibilidades para categorizarlas. Sin embargo, me enfocaré en esta ocasión, a las más apegadas a las etapas de construcción o implementación.

Editores de texto
Si consideramos que las herramientas son una extensión de nuestras manos, esto aplica mejor que en ningún otro caso para los editores de texto. Lo ideal es conocer un editor lo mejor posible y utilizarlo para cualquier tarea de edición: código, documentación, scripts, notas, entre otras.

Las características esenciales que debe tener un editor son:
•Configurable. Todo debe poderse adaptar a las preferencias del usuario (fonts, colores, asociación de shortcuts, etcétera).
•Extensible. Un editor no debe pasar de moda si surge un nuevo lenguaje o formato de texto.
•Programable. Ya sea mediante la utilización de macros u otra funcionalidad equivalente, se deben poder realizar tareas complejas.

Entre los editores open source más populares encontramos a Emacs, Xemacs y Judit, por mencionar algunos.

A pesar de la sencilla interfaz gráfica que presenta, Emacs es uno de los editores más potentes que he conocido. Algunas de sus características son:
•Ampliamente configurable y programable a través de Lisp.
•Ligero: no se requiere mucho espacio de memoria para su instalación y ejecución.
•Utiliza atajos o shortcuts. A pesar de que es un poco difícil aprenderse los atajos, una vez que se tienen dominados son extremadamente útiles.
•Funcionalidad robusta y de gran diversidad: búsquedas, ejecución de comandos, ftp, soporte para múltiples buffers, highlighting, indentación automática; soporta diversos modos de edición, juegos, calendario, control de versiones, mail, etcétera.

Automatización de tareas de compilación y despliegue (build systems)
El estándar de facto para los proyectos en Java, es Ant. Para quienes están familiarizados con Unix, Ant es el equivalente al comando “make”, con la diferencia de que Ant utiliza archivos XML en lugar de makefiles. En cada archivo XML se describen los pasos y dependencias para ejecutar cada tipo de tarea: compilación, empaquetado, despliegue en servidores, etcétera. Las tareas se invocan a través de línea de comandos, o directamente desde un IDE.

Ant es muy fácil de extender e incorporar tareas diversas como envío de correos electrónicos, verificación de estándares de codificación (CheckStyle), integración de control de versiones, pruebas unitarias (JUnit), automatizar la ejecución de tareas en servidores, etcétera.

Con el uso extensivo que se ha hecho de Ant, surgió Maven, cuyo uso es menos generalizado. Maven agrupa las “mejores prácticas” y asume cierta estructura de directorios con el fin de estandarizar tareas. Adicionalmente, provee una estructura que permite declarar las dependencias complejas entre librerías de diferentes proyectos.

En lo personal, me gusta más la flexibilidad que provee Ant, ya que cuento con una infraestructura de muchas plantillas de proyectos diversos que me dan un buen punto de partida para cualquier nuevo proyecto. Sin embargo, creo que Maven puede ser una buena opción para quienes no cuenten con dicha infraestructura, o bien, para aquellos casos en que las dependencias entre proyectos o componentes es bastante significativa.

Entornos gráficos de desarrollo (IDE)
Los IDE’s son herramientas visuales que integran muchas de las características antes mencionadas (control de versiones, build systems, edición), y otras más avanzadas (modelado UML, construcción de interfaces gráficas, debugging, instalación en servidores de aplicaciones, refactoring) que no cubrimos en este artículo.

La tarea de elegir un IDE es verdaderamente difícil. Cada una de las opciones presenta ventajas y desventajas. Sin embargo, podemos tomar en cuenta algunas consideraciones al momento de hacer esta elección:
•Naturaleza del proyecto a realizar. Es importante considerar las características del proyecto a desarrollar para así, poder delimitar las necesidades que se deben cubrir. Una vez que se tiene un panorama del proyecto y sus requerimientos, podemos buscar un apoyo en los IDEs para que faciliten algunas de las tareas más laboriosas.
•Hardware disponible. Aunque a veces este punto se pasa por alto, no debemos olvidar que generalmente los ambientes de desarrollo requieren de una capacidad mínima para que funcionen de manera óptima.
•Flexibilidad de la herramienta. Existen herramientas que hacen verdaderas maravillas en la generación de cierto tipo de proyectos, pero que al momento de quererlas integrar con otro tipo de tecnologías o herramientas, empiezan a generar problemas.
•Estabilidad. Algunos IDEs tienden a deteriorar su funcionalidad al momento de ser utilizados en proyectos grandes con muchos componentes.
•Documentación. Es conveniente revisar si existe buena documentación y soporte sobre el funcionamiento del IDE.
•Perfil del desarrollador. Algunas características de los IDEs pueden ser útiles para unos y un estorbo para otros. De nada sirve tener asistentes para tareas que podemos realizar de mejor manera utilizando otro tipo de herramientas, metodologías, etcétera.

Hablando principalmente de desarrollos en Java, al día de hoy destacan dos opciones como alternativas open source: Eclipse y NetBeans. En cuanto a la filosofía que promueven con su arquitectura, ambos fueron implementados alrededor de un pequeño núcleo con todas sus características implementadas como plug-ins. Ambos sirven como plataforma base para otras herramientas de valor agregado que proveen las empresas que fundaron a estos proyectos.

Por ejemplo: en el caso de NetBeans, éste sirve de base para el Java Studio Creator y Java Studio Enterprise, ambas herramientas de Sun Microsystems. La primera está dirigida a desarrolladores de Visual Basic que buscan hacer el salto a la plataforma Java; mientras que la segunda, está más dirigida a desarrollo de aplicaciones corporativas.

De forma similar, en el caso de Eclipse, existen diversos productos de IBM construidos sobre esa plataforma, especialmente de las líneas de Rational y Websphere. Tal es el caso del WebSphere Studio Application Developer.

A pesar de que la opción de utilizar un IDE puede ser muy tentadora, en algunas ocasiones es mejor utilizar sólo un buen editor de texto. De cualquier forma, no olvidemos que las herramientas de programación deben ayudar a:
•Minimizar costos de desarrollo.
•Automatizar procesos.
•Reducir errores.

Para decidir si es conveniente o no utilizar una herramienta de desarrollo, debemos preguntarnos si ésta nos ayuda o no a cumplir con estos objetivo.

Conclusión
Independientemente de la selección de herramientas para generar nuestro entorno de desarrollo colaborativo, conviene tener muy presente dos cosas:
1. Las herramientas de colaboración no son un sustituto de la comunicación directa con los otros miembros del equipo de trabajo, también es importante establecer las “reglas de uso” de las herramientas para facilitar su adopción
2. En cuanto a las herramientas de desarrollo, yo considero de mayor valor contar con un “esquema estándar” de proyecto, que funcione con cualquier herramienta de desarrollo, en lugar de “casarme” con alguna en particular.

Referencias
•SourceForge - sourceforge.net
•CVS - www.nongnu.org/cvs
•Subversion - subversion.tigris.org
•Bugzilla - www.bugzilla.org
•Google Groups - groups.google.com
•Emacs - www.gnu.org/software/emacs
•Jakarta Ant - apache.ant.org
•CheckStyle - checkstyle.sourceforge.net
•JUnit - www.junit.org

Acerca del autor
Francisco Castrillo es Director de Soluciones de Nexusware, empresa pionera en México en el desarrollo de soluciones corporativas basadas en Java. Como expositor, ha impartido seminarios relativos a la tecnología Java EE en diversos foros a nivel nacional e internacional. Francisco es miembro del Consejo de la Comunidad Java México (www.comunidadjava.org) y es egresado de Matemáticas Aplicadas del ITAM.