Jenkins 2 ha llegado

Así es, Jenkins 2 finalmente está aquí. Según se cuenta en el sitio oficial los puntos destacados de esta nueva versión mayor (major release) son:

  • Soporte nativo para delivery pipelines
  • Mejoras de usabilidad
  • Completa compatibilidad con versiones anteriores

Tuve la oportunidad de verificarlos cuando pasé uno de mis proyectos a la versión pre-release que Jenkins publicó hace un tiempo. Adicionalmente a esto noté:

  • «Independencia» de Maven, lo pongo entre comillas porque no estoy seguro que el término apropiado sea independencia. Lo que noté es que en la versión anterior, al crear un nuevo job existía la opción «proyecto Maven», cosa que ya no existe. Creo que inicialmente esto tenía sentido pues Jenkins había surgido en el mundo Java, pero en los últimos años creo que ha transcendido ampliamente el mundo Java y se ha convertido en la herramienta de-facto para integración continua.
  • Integración con Gradle para la definición de los pipelines, los cual tiene mucho sentido ya que Gradle es una herramienta que se posiciona como herramienta de build genérica capaz de buildear proyectos en distintos lenguajes.
  • Se removió el soporte nativo para repositorios CVS, quedándo nativamente soporte solo para Git y Subversion.

Más allá de estos puntos, un detalle que me llamó positivamente la atención fue que como parte del proceso de instalación, se ofrece instalar un conjunto de plugins que son los más comunmente utilizados por la comunidad.

A partir de esta nueva versión de Jenkins y de algunas charlas que he tenido con mi equipo actual de proyecto he decido empezar a trabajar en la preparación de un curso de Jenkins para dictar en Julio o Agosto.

Tipado estático vs. Tipado dinámico

Como de costumbre luego del almuerzo dominical, me senté con un café a leer mi lista de blogs. Fue en ese momento cuando me encontré con este artículo que había publicado Uncle Bob ese mismo día. El artículo está titulado «Type Wars» y en forma muy resumida es una recorrida histórica de esta interminable contienda, con opiniones intercaladas del autor y un cierre interesante.

Este tema del tipado es una cuestión que me encuentro recurrentemente en mis clases todos los cuatrimestres. En FIUBA la mayoría de los alumnos viene de programar Pascal, C y C++, mientras que en UNTREF todos vienen de programar Java. Cada vez que en las materias empezamos a trabajar con lenguajes de tipado dinámico (Smalltalk o Ruby) algunos alumnos se sienten desconcertados y en más de una ocasión surge el debate en clase. De ahora en más voy a referenciarlos directamente al artículo de Uncle Bob, más aún, voy a incluir el artículo como lectura obligatoria.

Para cerrar les recomiendo dedicar un rato para leer el artículo completo y les dejo aquí una frase excelente incluida en el mismo:

…when a Java programmer gets used to TDD, they start asking themselves a very important question: «Why am I wasting time satisfying the type constraints of Java when my unit tests are already checking everything?» Those programmers begin to realize that they could become much more productive by switching to a dynamically typed language like Ruby or Python.

Extracto del artículo «Type Wars, de Uncle Bob«, artículo completo disponible en: http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html

Preparing my session for XPConf @ Edinburgh

My session proposal for the Extreme Programming Conference was accepted so now I must practice to ensure a clean delivery.xp2016logo

The session is based on my Software Engineering course at UNTreF but I need to perform some modifications in order to delivery it in 6 hours.

The session is called «Modern Extreme Programming Workshop» and it is focused on how Extreme Programming practices have evolved and how they are being used by (some) development teams nowadays. The session is hands-on so the participant we will have the chance to apply XP practices while working in a «real world» Java application. Among the practices we will cover Behaviour-Driven Development, Mob Programming, and Continuous Delivery. Regarding tools and technologies, we will work with Java, Gradle, Cucumber, Jenkins and Ansible.

To practice before the conference I will run this workshop in Buenos Aires (but in English). If you are interested in participating just fill this form (programming experience required).

Nueva aventura: proyecto de investigación

Luego de algunas discretas expediciones esporádicas al mundo de la investigación, este año voy a embarcarme formalmente en un proyecto de investigación junto a Diego Fontdevila y Alejandro Oliveros.

Si bien aún estamos en etapa de definiciones nuestro trabajo entra en la temática ingeniería de software y más específicamente en el área de prácticas y procesos.

Hemos decidido intentar gestionar este proyecto de investigación de forma similar a como gestionamos cotidianamente nuestros proyectos de desarrollo software. En ese sentido hemos bautizado el proyecto con un nombre clave: Paladine (nombre del líder de los hechiceros en el mundo DrangonLance).

Como parte de mi formación para llevar adelante este trabajo estoy cursando un seminario de Introducción a los métodos experimentales de investigación en Ingeniería de Software. Hasta el momento llevamos tan solo dos encuentros y ambos me han resultado extremadamente enriquecedores.

Continuará…

3 semanas de proyecto

El miércoles pasado se cumplieron 3 semanas/iteraciones desde que empecé a trabajar en mi proyecto actual. En estas semanas creo que hemos hecho algunos avances importantes respecto al producto y a la forma de trabajo:

  • Mejoramos «el teamwork»
    • ahora el equipo se sienta todo junto en la misma mesa
    • dimos un par de pasos para integrar a los miembros con asignación part-time (testing y UX)
    • creamos una lista de correo que tiene bastante vida y que nos permite estar más comunicados principalmente los días que hacemos homeworking
  • Respecto de los aspectos técnicos del proceso de desarrollo
    • tenemos 2 ambientes de testing: uno para tests automatizados y otro para tests manuales
    • agregamos tests automatizados
    • automatizamos el deployment a los distintos ambientes
    • empezamos a desplegar la aplicación en forma frecuente
    • ordenamos el versionado del producto agregando release notes y tags en los repositorios
  • Finalmente respecto del producto
    • hicimos un refactoring de arquitectura que gradualmente nos permite movernos de una arquitectura monolítica a una esquema de microservicios
    • como consecuencia del refactoring mejoró la estabilidad del producto

Personalmente estoy contento con como venimos avanzando y con los desafios que aún nos quedan por delante.

Continuará…

Más de 10 años de blogging

Ayer por casualidad caí en la cuenta de que hace 10 años que escribo este blog, aunque no siempre estuvo hosteado aquí. Actualmente este blog está hosteado en WordPress, pero antes de llegar aquí pasó por otras plataformas.

Mi primer blog lo empecé a escribir en 2006 con el fin de llevar una bitácora de mi trabajo en mi tesis de grado, por ello el blog estaba dedicado a cuestiones de Programación Orientada a Aspectos. Ese primer blog estaba hosteado en Blogger.

Un par de meses después, mientras trabajaba en Microsoft empecé a escribir un segundo blog en el cual escribía principalmente sobre cuestiones relacionadas a mi actividad profesional en Microsoft (la difusión de tecnología .Net) y de vez en cuando colaba alguna que otra entrada sobre cuestiones de agilidad.

En mi paso por Snoop y Southworks también escribí algunas entradas en sus respectivas plataformas de blogging.

Cuando finalmente me mudé a WordPress, traje conmigo las entradas de mis blogs anteriores.

A lo largo de estos 10 años también he ido alternando el idioma. En algún momento se me había dado por escribir en inglés, simplemente para practicar mi escritura en ese idioma. Luego, cuando empecé a dedicar la mayor parte de mi escritura a cuestiones de agilidad, me pareció importante escribir en castellano, pues en aquel momento escaseaba el contenido sobre agilidad en castellano. Actualmente escribo casi todo el tiempo en castellano y dejo el inglés para algunas situaciones muy particulares como cuando asisto a conferencias fuera de Latam.

A los largo de estos años la cantidad de visitantes del blog ha ido en aumento, pero sinceramente no es algo que me preocupe, pues en la mayoría de los casos escribo para mismo, ya sea a modo de recordatorio de como resolver un determinado tema o bien como bitácora de los proyectos en  los que voy participando.

Al día de hoy este blog cuenta con 763 artículos y en los últimos años he tenido un promedio de publicación de ~100 artículos/año, lo cual representa algo asi como un artículo cada 3,6 días. Nada mal, aunque a pesar de la práctica aún no estoy conforme con la calidad de mi escritura.

Este año tengo pensado volver a trabajar en un investigación, con lo cual sospecho que la la cantidad de entradas puede llegar a estar por encima del promedio.

 

Nuevo proyecto: java, micro-servicios y entrega continua

Esta semana empecé a trabajar en un nuevo proyecto. Se trata de una aplicación que una empresa desarrolló para uso interno hace ya varios años y que ahora quiere»productizarla» para ofrecerla a terceros y montar un esquema de Software As A Service. Es ahí donde entro yo para dar una mano en «la productización» colaborando en cuestiones de refactoring de arquitectura, tareas de automatización, monitoreo y ajustes en el proceso de desarrollo.

La aplicación nació como un monolito Grails que fue evolucionando a lo largo de los años incorporando nuevas funcionalidades, en este momento está corriendo sobre Grails 2.5. Recientemente se decidió pasar a una arquitectura de micro-servicios construidos con Spring Boot sobre Java 8.

Más allá de las cuestiones técnicas, hay algunos issues a nivel de dinámica de trabajo. Si bien el equipo trabaja en un esquema tipo Scrum, el testing de la aplicación lo realiza otro sector de la empresa y es testing manual. Esto genera importantes delays en el release, ya que muchas veces se llega al final de la iteración y no se puede pasar a producción pues hay funcionalidades no testeadas.

Continuará…

Automatización de pruebas en AS400, fin de la historia

Como mencioné tiempo atrás, en octubre comencé a trabajar en un proyecto para automatizar pruebas de una aplicación RPG/AS400. He completado mi participación en el proyecto, logramos dejar una arquitectura de pruebas funcionando con un par de casos automatizados, ahora está en manos del propio equipo de desarrollo continuar agregando nuevos casos.

El siguiente gráfico resume la arquitectura implementada:

test_as400

La arquitectura está armada de forma tal que un tester puede agregar fácilmente nuevos casos sin tener que meterse mucho en el código. Algo de código obviamente va a ser necesario escribir pero por la forma en que todo quedó armado (con template methods) es realmente poco lo que hay que codear.

Los casos de pruebas se generan con FitNesse y luego el gluecode/driver utiliza dos librerías de IBM: una para invocar funciones nativas en AS400 que se encargan de hacer el setup del ambiente con los datos iniciales y otra para la creación de las colas MQ y para leer/escribir en dichas colas.

Como la aplicación y los tests están codeados en distintas tecnología y almacenados en distintos repositorios, el servidor de integración continua (jenkins) quedó configurado para correr el set de tests ante cada commit y también en forma periódica 3 veces al día.

Estoy conforme con el resultado de nuestro trabajo, al mismo tiempo creo que fue un lindo desafío que me permitió aprender un poquito del mundo AS400. Ahora está en manos del codear más pruebas y sacar valor al trabajo realizado.

 

 

 

 

Blue Green Deployment

En las últimas 2 semanas me encontré explicando la técnica de despliegue Blue/Green más de 5 veces. Cuando tomé conciencia de ello decidí hacer un video explicativo de modo de poder utilizarlo también en mis clases. Espero resulte de utilidad.