Dibujo de las stacks de Bitnami

El dibujo me gusta muchísimo. Opina detrás de Ruby y delante de Drupal, jejejeje, ojalá!

Estos detalles animan mucho para seguir trabajando.

• Linux
• Java jdk1.5.0_06
• MySql
• Tomcat 6.0

Si alguien está interesado en instalar Opina con Oracle, y se encuentra con problemas, que lo comunique a la lista de correo. Hay que realizar un pequeño cambio (BLOB, VARCHAR2) en el esquema que se genera para que todo funcione correctamente.

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?

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

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.

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:

En algún que otro proyecto ya había usado Omnigraffle para realizar modelos conceptuales, wireframes, esquemas, etc. sin embargo, el disponer de “Design Stencil Kit” de Yahoo! Developer Network para prototipar es una maravilla.

Además hay que decir que estas primitivas (algunas son mucho más que una primitiva) no sólo están disponibles para Omnigraffle sino que también lo están para Visio, en PNG, en SVG y en PDF (supongo que para consulta y referencia).

Desde luego el aporte que Yahoo! Developer Network está realizando es realmente bueno a todos los niveles.

1. Las ofertas presentadas en un proceso de licitación son valoradas conforme a unos aspectos que están ponderamos y -normalmente- se hacen públicos en el pliego.
2. La presentación de una oferta por parte de una empresa es una inversión.

Podría haber enumerado algunas premisas más pero no quiero que este texto se extienda demasiado y así dejar algunas reflexiones para más adelante, quizás cuanto estén algo más maduras.

Si el número de ofertas que se presentan a un concurso público es finito y existen una serie de aspectos ponderamos que la mesa evalúa, entiendo que debe haber una puntuación máxima (descartemos el empate) y una puntuación mínima, y entre éstas el resto de resultados. ¿Por qué no se hacen públicos dichos resultados? No quiero ir a solicitarlos, esto no es una revisión de un examen de instituto o de universidad, simplemente quiero saber cómo se ha valorado el trabajo que un grupo de personas ha realizado, en muchos casos, un trabajo que requiere un gran esfuerzo. Al menos las ofertas que preparan técnicos que arrojan gran parte de su conocimiento y experiencia en un documento y que luego, a saber dónde terminan. Descartemos aquellas ofertas realizadas a base de copiar y pegar sin sentido. Los motivos por lo que me gustaría conocer el resultado de la evaluación son:

1. Es una forma de conocer, frente a tus competidores profesionales, qué tal han evaluado tu oferta.
2. Saber en qué aspectos has tenido menos puntuación y pensar en nuevas estrategias para mejorar.

Cuando a nivel interno se decide presentar una oferta a un concurso público se pone en marcha todo un proceso para organizar el trabajo que tendrás que dejar aparcado o delegado para atender a este nuevo reto que se tiene por delante. Cuando la oferta se termina y se entrega, vuelta a los proyectos, reuniones, presentaciones, etc. Pero, ¿Qué pasa con el esfuerzo dedicado? Evidentemente esa dedicación requiere un tiempo del equipo que ha preparado la oferta, y por tanto, inversión. Hasta ahí creo que todos podemos estar de acuerdo. Si finalmente uno gana el concurso público, perfecto. Personalmente lo siento como una recompensa al trabajo. Si no se gana, tu conocimiento y experiencia quedarán en algún cajón, y en el mejor de los casos, en una trituradora de papel. ¿Por qué en el mejor de los casos? Porque nadie me garantiza que el documento que se entrega, siendo privado y de carácter reservado, quede protegido.

Uno de los aspectos que se valora en las ofertas es el referido con el epígrafe “Mejoras propuestas”. Que triste sería que a la empresa adjudicataria le dijesen que añadiese a su propuesta las mejoras del resto de ofertas que no han sido propuestas, ¿Verdad? Pero bueno, yo estoy seguro que estas cosas no ocurren.

Creo que se deberían buscar fórmulas para mejorar este proceso. En lugar de entregar un documento con decenas de páginas explicando hasta cuando los programadores van a ir a desayunar, por qué no citan a las empresas licitadoras y que éstas realicen una exposición con un tiempo limitado. Muchos procesos de oposición tienen exámenes orales donde el candidato tiene un tiempo limitado para exponer un tema que previamente se ha debido preparar. Pues aquí igual, unas transparencias o resumen ejecutivo con los puntos fuertes de la propuesta y una exposición oral con posibilidad para que al final haya unos minutos para resolver posibles dudas.

Una vez más agradecer el excelente trabajo a los que han hecho posible que este DVD exista.

La verdad es que esta nueva versión de Trac se ha hecho esperar, pero vale la pena. Aun no he tenido tiempo de ver las cosas con detenimiento, entre otras cosas porque tengo que configurar mis proyectos para que puedan hacer uso de los nuevas características. Parece que lo más destacado es el nuevo y configurable workflow para los tickets. El módulo browser (navegar por los repositorios) ha ganado en usabilidad muchísimo.