Mi espacio

Definir un buen ecosistema software es garantía de comodidad, ventajas y mejoras durante el transcurso de un proyecto hasta alcanzar nuestros objetivos. Es lógico, dado que las herramientas que lo conforman están concebidas precisamente para eso, para automatizar y simplificar ciertas tareas.

Hasta ahora, mi experiencia definiendo ecosistemas software se ha limitado a entornos donde la localización de los miembros del equipo no suponía un problema, sin embargo, no debemos olvidar que la distribución geográfica puede ser una cuestión a tener muy en cuenta. De partida, si hay miembros con husos horarios distintos tendremos que tenerlo en cuenta a la hora de planificar nuestras tareas de integración continua. ¿Y qué pasa con la forma comunicación? La posibilidad de coger tu silla y sentarte al lado de un compañero para trabajar no existe. Un problema importante en los equipos de desarrollo software es la comunicación en el equipo, especialmente, transfiriendo información entre distintos roles.

Por otro lado, el acceso a la información es otra cuestión importante. Yo no quiero un acceso por VPN para poder recuperar el último informe de pruebas que se realizó la noche anterior. Quizás, si nos encontramos en nuestro lugar habitual de trabajo o contamos con nuestro ordenador portátil, no sea demasiado intrusivo dado que ahí encontraremos todo aquello que usamos frecuentemente. Pero, ¿Qué sucede si estoy en las oficinas del cliente y por cualquier motivo (no es la primera vez que me pasa) necesito acceder a determinada información? Con esto lo que intento transmitir es la importancia que tiene garantizar el acceso a la información y que por tanto, a la hora de definir nuestro ecosistema software la accesiblidad debemos tenerlo presente.

Por lo tanto, un ecosistema software se plantea como una solución (o mejora) a estos dos nuevos retos, por un lado la distribución geográfica, y por otro, el acceso a la información. ¿No es precisamente esto básico para las factorías de software?

Si alguien se encuentra con la necesidad de monitorizar el consumo de memoria que está haciendo su contenedor JSP/Servlet Apache Tomcat, quizás esta entrada le interese.

Hace ya algunos años que vengo usando Lambda Probe. Concretamente comencé a usarlo tras la primera release de Opina y posteriormente se convirtió en una de mis herramientas favoritas. Es difícil ver un entorno de desarrollo montado por mi en el que no esté presente esta herramienta. La uso tanto durante la fase de desarrollo como tras la puesta en producción. Es aconsejable monitorizar (aun estando en producción) nuestra aplicación, aunque sólo sea durante las primeras semana. Es una herramienta muy útil para preparar informes de calidad relacionados con rendimiento. ¿Cómo establecer sino los requisitos mínimos de memoria? Supongo que hay ocasiones en las que los administradores de sistemas reciben aplicaciones que deben ser desplegadas y desconocen cuáles son esos requisitos mínimos.

Pues bien, definiendo un buen entorno de entorno de desarrollo, pruebas de rendimiento y Lambda Probe, podemos realizar una buena aproximación de eso requisitos mínimos de memoria.

¿Qué debemos hacer para añadir a nuestro entorno de desarrollo monitorización de memoria?

1. Descargamos la herramienta del sitio web oficial.
2. Desplegamos el WAR en nuestro Apache Tomcat
3. Creamos el archivo $TOMCAT_HOME/bin/setenv.sh y le añadimos la siguiente configuración:
   CATALINA_OPTS=”-server -Xms256m -Xmx300m -XX:MaxPermSize=128m -Dcom.sun.management.jmxremote”
4. Accedemos a la aplicación:

   http://hostname[:port]/probe

5. Y si tenemos correctamente configurado un usuario con el rol manager en $TOMCAT_HOME/conf/tomcat-user.xml, simplemente accedemos con ese usuario. En la página oficial hay información más detallada sobre el proceso de instalación.

A continuación os muestro una captura de pantalla correspondiente al consumo de memoria del entorno de preproducción que usamos para Opina.

Captura de pantalla de Lambda Probe

Esta es una de esas entradas que llevo tiempo queriendo escribir y tras un tiempo pensando e intercambiando ideas con otros compañeros, he pensando que es momento de proporcionar mi perspectiva sobre los ecosistemas software.

En una de las entradas del blog de Brett Porter leí como usaba el término development ecosystem para referirse a como herramientas como Maven, Archiva y Continuum pueden ayudar a los equipos de desarrollo a ser más eficientes.

Un ecosistema software es un espacio de trabajo en el que conviven una serie de herramientas que acompañadas de unas buenas prácticas permiten a un equipo de desarrollo modelar una metodología de trabajo.

Me resulta complicado proporcionar una definición corta para transmitir una idea que es simple pero que implica muchísimas cosas:

• [...una serie de herramientas...]: ¿Qué herramientas?
• [...acompañadas...]: ¿Quiere decir esto que las herramientas por sí solas aportan poco?
• [...buenas prácticas...]: Aquel documento donde está explicado qué hacer, cómo y cuándo.
• [...modelar una metodología...]: Planificación, organización, medición, control, etc.

Todos los equipos de desarrollo software, incluyendo aquellos que se organizaban para realizar las prácticas de alguna asignatura de la carrera, tienen su propio ecosistema software. Los ecosistemas software surgen como necesidad de alcanzar nuestros objetivos de la forma más eficiente posible. Un equipo de trabajo puede alcanzar sus objetivos siguiendo Métrica v3 y usando poco más que una suite ofimática como OpenOffice y cualquier IDE de desarrollo para las tareas propias de codificación. Sin embargo, siendo este nuestro ecosistema software creo que nos costaría muchísimo responder a ciertas preguntas como:

1. Cuál es el próximo hito en la planificación
2. Qué sistema de versionado (version naming) se está llevando a cabo y cómo comprobarlo
3. Cuánto costó elaborar un informe de calidad previo a obtener una nueva versión
4. Cuál es la actividad del proyecto
5. Qué métricas e indicadores de calidad se tienen del proyecto y cómo se obtienen
6. y un largo etcétera.

Es cierto que el caso que he expuesto es algo extremista, pero os puedo asegurar, porque lo he sufrido, como un proyecto se lleva adelante a base de documentos de texto, hojas de cálculo, intercambio de correo y de vez en cuando intercambio de código fuente a través de correo para que un miembro del equipo hiciera que aquello “ensamblase” bien.

Por lo tanto, la correcta definición de un ecosistema software nos ayudará a flexibilizar y agilizar tareas, que en cierta medida se traducen en eficiencia y productividad.

Algunos factores que condicionan la definición y configuración de un ecosistema software:

1. Marco tecnológico: Las herramientas que conformen nuestro ecosistema software en gran medida estarán condicionadas por nuestro marco tecnológico. Obviamente no es igual trabajar con tecnología Java que con tecnología .NET
2. Desarrollo de negocio: Es muy importante si nuestra actividad se centra en el desarrollo de soluciones a medida o por el contrario desarrollamos una línea de productos. En el primer caso, una vez entregada una versión estable, nuestra implicación queda resumida a una garantía de mantenimiento. Sin embargo, desarrollar un producto tiene muchas más implicaciones que requieren atender de forma eficiente la interacción con los consumidores de nuestros productos.

Disponer de un ecosistema software estable y bien definido puede ser un valor añadido de cara a nuestros clientes. Construir un ecosistema software no es sencillo ni es una tarea que se pueda llevar a cabo en semanas, entre otras cosas porque implica un cambio en la cultura de empresa puesto que estamos hablando de nuestra forma de trabajar.

Más adelante intentaré hablar sobre los ecosistemas software como paso previo para las factorías de software.

Neon es una herramienta para VJ desarrollada por gente muy vinculada a la demoscene y que recientemente, Jordi Ros, quien ha estado evolucionando la herramienta estos últimos años, ha decidido liberar el código con licencia GNU GPLv3.

Hay publicados algunos trabajos que se han llevado a cabo con esta herramienta.

Mi más sincera enhorabuna a shine (aka Jordi Ros) por el excelente trabajo que ha realizado, y por haber decidido compartir su trabajo para que otros lo evolucionen y aprender de él. Si queréis conocer otras habilidades de este crack: