Mes: enero 2012

Jenkins vía GTalk

Con mi llegada al mundo Ruby comencé a utilizar Jenkins como servidor de integración contínua y cuando empecé a investigar los plugins me copé. Los últimos dos que agregué fueron el HTML Publisher y el Jabber Notifier.

El HTML Publisher permite visualizar en la interface de Jenkins reportes html que se generen como parte del proceso de build; en mi caso lo uso para visualizar el reporte generado por SimpleCov. La configuracion es trivial, solo hay que indicar la ubicación y nombre del archivo del reporte.

El Jabber notifier permite enviar notificaciones vía  GTalk. Una vez instalado el plugin (que se instala con 2 clicks al igual que casi todos los plugins Jenkins) la configuración es bastante simple. En primer lugar vamos a necesitar una cuenta de gmail para que sea utilizada por Jenkins, en mi caso tengo una cuenta de gmail generada especificamente para este propósito.  Entonces en la configuración general de Jenkins (Manage Jenkins > System Configuration) en la sección Jabber Notification ponemos las siguientes settings:

  • Jabber ID: <la cuenta de gmail que queremos que Jenkings use para enviar las notificaciones> (ojo, esto no es la cuenta a la que Jenkins va a enviar las notificaciones, sino la cuenta con la que Jenkins se va logguear en GTalk)
  • Password, el password correspondiente a la cuenta de Gmail antes mencionada
  • Server: talk.google.com
  • Expose presence: yes
  • Acceptance mode for subscription requests: accept_all
  • Bot command prefix: !

Y el resto de los campos podemos dejarlos en blanco. Luego en la configuración particular de cada Job, en la sección Post-build actions, habilitamos  Jabber Notification y en el campo targets indicamos las cuentas de Gtalk a la que se debe notificar.

Les dejo un screenshot de las notificaciones que envia el Jenkins, noten lo gracioso del mensaje de estado.

Instalación de Ruby (la posta para mi)

En los últimos meses instalé Ruby en al menos 4 máquinas distintas (mi máquina personal, mi desktop del trabajo, una máquina virtual y mi build server). En todos los casos intenté seguir el mismo procedimiento, pero en todos me encontré con distintos issues, estimo que debido a que los ambientes eran levemente distintos (pero todos eran Ubuntu).

Cuando hablo de instalación de Ruby, no estoy hablando de la instalación base de ruby para hacer un «Hola  mundo», sino una instalación como para crear una aplicación «de verdad» (básicamente aplicación web, con conexión a internet, manejo de xml, pruebas y build automatizado).

Habiendo seteado el contexto paso a describir los pasos comunes que logré identificar en todas las instalación que realicé y que voy a seguir la próxima vez que tenga que preparar un ambiente.

Vamos a comenzar por instalar Ruby usando apt-get, no importa si luego queremos utilizar otra versión, yo me inclino por comenzar instalando ruby con apt-get pues eso se encargará de hacer varios seteos. Entonces abrimos una terminal y ejecutamos

sudo apt-get install ruby

Si no tenemos instalado Git aún, es un buen momento para instalarlo.

sudo apt-get install git

Luego vamos a instalar Ruby Version Manager (rvm). Esta herramienta nos va permitir instalar y administrar distintas versiones de Ruby en una misma máquina. Pero para instalar RVM primero tendremos que instalar git y curl, entonces:

sudo apt-get install curl
bash -s stable < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer )
echo '[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm" # Load RVM function' >> ~/.bashrc

Cuando finalice la instalación de estos componentes cerramos la terminal.

Ahora instalaremos ruby 1.9.2 usando RVM, para ello abrimos una nueva terminal y ejecutamos

rvm install 1.9.2

El siguiente paso es installar RubyGem, un administrador de paquetes (que en ruby se llaman gemas). La instalación de esta herramienta consisten en descargar el paquete desde http://rubygems.org/pages/download , descomprimirlo y ejecutar setup.rb (ruby setup.rb). Con esto ya estamos en condiciones de comenzar a installar gemas, pero resulta que algunas gemas en su proceso de instalación incluyen un proceso de compilación de código C, el cual puede requerir de la existencia de ciertas librerías nativas en nuestro ambiente. Por suerte las mismas pueden instalarse fácilmente utilizando apt-get.

sudo apt-get install libmysqlclient-dev libpq-dev libsqlite3-dev zlib1g-dev libreadline5-dev libssl-dev libxml2-dev libopenssl-ruby libxslt1-dev

Ahora  si, podemos proceder a la instalación de dos gemas fundamentales: rake (ruby make) y bundler (un administrador de dependencias en un punto similar a Maven).

gem install rake
gem install bundler

Con esto estamos listos para comenzar, cuando creemos nuestras aplicaciones tendremos un archivo llamado Gemfile en el cual especificaremos las dependencias de nuestra aplicación (las gemas) y con solo ejecutar bundle install, bundler se encargará de instalar las gemas especificadas.

Espero que esto les resulte útil.

Continué con Ruby y me copé

Luego de mi comienzo en el mundo Ruby, seguí avanzando: agregué tests (utilizando rspec), medí la cobertura (con simplecov) y automaticé el build contínuo (con rake y jenkins). Ahora que tengo todo mi código cubierto por pruebas voy aplicar algunos refactorings pues no estoy muy conforme con los nombres de algunos métodos y al mismo tiempo quiero agregar algunas funcionalidades nuevas. Lo que aún me falta agregar es algo que verifique el cumplimiento de estándares de codificación.

Si bien aún soy un principiante en el mundo Ruby, puedo afirmar que hacer el setup de todo lo mencionado arriba en un proyecto Ruby, me ha resultado mucho más simple que hacerlo para un proyecto C#, a pesar de la experiencia mucho más extensa que tengo con este último.

¿Y si tu sueldo dependiera de la cobertura de tu código?

Definitivamente algunos meses habría pasado hambre  y  creo que algunos otros no habrían cobrado ni un solo peso, ja!

Más allá de lo chistoso (o lo triste) del título, este post es una continuación  de otro que escribí hace un par de dias sobre esta misma temática. En dicho post compartí algo de teoría junto con algunos links interesantes (el de artículo de Marrick es excelente) y en los cuales he encontrado justificación para algunas de las ideas que compartiré a continuación. Durante las últimas semanas he estado dedicando la mitad de mi tiempo en entrenar gente y la otra mitad al desarrollo de una aplicación y en ambos casos he puesto bastante foco en el tema de la cobertura de código lo cual me ha llevado a una reflexión profunda sobre el tema.

Si desarrollamos nuestra aplicación siguiendo un enfoque TDD extremo, siempre mantendremos un alto grado de cobertura, pues solo agregaremos código cuando haya una prueba que lo ejercite.

Si procuramos seguir las buenas prácticas de diseño la relación entre nuestros componentes será por medio de interfaces, lo cual nos permitirá utilizar mocking y asi superar la infantil excusa «No lo puedo testear porque tiene dependencias».

Si nuestros métodos son cohesivos y hacen usa sola cosa, entonces será más simple testearlos.

Si hechamos mano del polimorfirmo, seguramente podamos evitar algunos «if» en nuestro código lo cual también ayudará con la cobertura.

Para cerrar este post, les comparto una situación que viví hace unos dias. Resulta que una de las personas que estuve capacitando durante la semana pasada hizo una demo de la aplicación que desarrolló como parte de la capacitación. La demo venia bien y en un momento le pedimos que mostrara una funcionalidad particular que no habia sido mostrada. Resulta que cuando la va a mostrar, la aplicación ¡pincha!, ja!  a lo que le pregunto: ¿y los tests? adivinen….no había tests para esa funcionalidad. Y cuando pregunto por el porcentaje de cobertura de la aplicación, resulta que no superaba el 40%. ¡Que mejor forma de ilustrar la importancia de estas cuestiones! Espero que este colega haya aprendido la lección.

Por último quiero agradecer a David Frassoni quien la semana pasada me dió la idea de escribir este post.

El siguiente post de esta serie lo dedicaré a analizar las implicancias/consecuencias de tener una alta cobertura y de definir un shipping criteria en base al mismo.

Continuará…

Code Coverage

Durante las últimas semanas he estado dedicando la mitad de mi tiempo en entrenar gente y la otra mitad al desarrollo de una aplicación y en ambos casos he puesto bastante foco en la cobertura de código. Esto me ha motivado a compartir algunas ideas sobre este tema y para setear el contexto y las expectativas, voy comenzar este post compartiendo algunos conceptos básicos y luego en otro post voy a volcar algunas ideas/experiencias personales.

¿Qué es la cobertura de código?

La cobertura código es la cantidad de código (medida porcentualmente) que está siento cubierto por las pruebas. O sea, ejecuto las pruebas de mi aplicación y si hay alguna línea de mi código que nunca fue ejecutada en el contexto de las pruebas, entonces dicha línea no está cubierta. Si mi código consta te 100 líneas y solo 50 líneas están siendo ejecutadas al correr las pruebas, entonces mi cobertura es del 50%. La pregunta que viene a continuación es:

¿Qué beneficio tiene medir la cobertura? y más específicamente ¿que beneficios tiene tener una alta cobertura?.

Una respuesta genérica podría ser que aumenta la calidad de mi aplicación. Siendo más concreto podría decir que si tengo una alta cobertura, significa que gran parte me mi código está siendo probado y por consiguiente podria tener cierta certeza sobre el correcto funcionamiento de mi aplicación. Al mismo tiempo medir la cobertura podria ayudarme a detectar código innecesario en mi aplicación, ya que no se ejecuta.

La pregunta que surge a continuación es:

¿Qué porcentaje de cobertura es suficiente?

La respuesta no es única, existen distintos criterios y pueden resultar bastante polémicos por eso voy a tratarlos en otro post. Pero por ahora solo diré que para SimpleCov, lo idea es de al menos 90% y en Southworks soliamos perseguir el 80%.

¿Una cobertura del 100% asegura que mi código no tiene bugs?

De ninguna manera, una cobertura del 100% solo nos dice que todo nuestro código está siendo cubierto por pruebas, pero puede que las pruebas no esten contemplando algunas situaciones, o sea, me falta pruebas.

¿Qué necesito para poder medir la cobertura?

En primer lugar  es necesario escribir pruebas y en segundo lugar contar con alguna herramienta que permita medir la cobertura.En la actualidad los lenguajes más populares cuentan con herramientas para medir la cobertura. Si trabajamos con C# y escribimos nuestras pruebas con MSTest, entonces el Visual Studio nos ofrece la posibilidad de habilitar la medición de cobertura de código. Si en cambio trabajamos con Ruby, podríamos utilizar RSpec para escribir nuestras pruebas y SimpleCov para medir la cobertura.

Esto es todo por ahora, les algunos links interesantes sobre el tema:

En el siguiente post voy hacer algunos comentarios sobre estos artículos.

Peer Reviews

Estaba degustando un aperitivo post-cena mientras hacía un poco de zapping entre las pestañas de mi explorador. Fue entonces cuando me topé con un mail de un ex-compañero de trabajo consultando sobre el tema de referencia. Puntualmente la consulta fue:  ¿cuáles serían los 4 puntos más importantes a tener en cuenta para hacer un peer review? Luego de pensarlo brevemente, comencé a redactar mi respuesta cuando caí en la cuenta que era un tema interesante para compartir y entonces decidí publicarlo aquí.

Haciendo un poco de memoria, creo que mi primer acercamiento a este tema fue con Code Complete, el clásico de Steve McConnell. Pero no estoy seguro, tal haya sido cuando cursé la materia Calidad con Alejando Oliveros en Fiuba.

Comencemos por el principio. El términos generales podemos decir que el peer review es una técnica de revisión del trabajo producido por una persona, realizada por sus pares. El fin de este tipo de actividad suele variar levelmente dependiendo del campo de aplicación, pero usualmente tiene que ver con el aseguramiento del cumplimiento de normas/estándares, la detección de oportunidades de mejora y la validación (esto último es muy común en el campo académico, previo de la publicación de trabajos de investigación).

Bajando a concreto y hablando especificamente del ámbito de desarrollo del software, un peer review es una revisión de un artecfacto (código, especifición, etc) realizada por su autor y un conjunto de pares con el fin de evaluar su contenido técnico y/0 calidad.  La técnicas existentes para realizar este tipo de revisiones varian considerablemente en su nivel de formalidad. En un extremo podriamos encontrar el collective ownership de los métodos ágiles y en otro las inspecciones formales propuestas por el IEEE. En medio hay unas cuantas alternativas. ¿cual de todas es la más apropiada? Dependerá del fin concreto de la revisión y de la cultura de la organización donde pretenda implementarse.

Volviendo a la pregunta de mi colega que motivo estas lineas, asumo en primer lugar que su inquietud apunta a implementar la práctica de peer review en una organización y no a simplemente realizar UN peer review. Al mismo tiempo asumo que estamos habland de review en el sentido de revisión de artefactos y no de evaluar el desempeño general de una persona. Dicho esto, los principales puntos a considerar son a mi enteder:

  1. El objetivo del peer review
  2. La cultura organizacional
  3. La conformación del equipo
  4. El proceso

Si bien los items estan enumerados, dichos números no representan necesariamente su orden de importancia. Más allá de eso, tanto (1) como (2) son fundamentales para determinar la técnica concreta a utilizar y ello sin duda tiene impacto en (3) y (4).

En cuanto a (1), si el objetivo es la implementación de alguna práctica de mejora certificada como la propuestas por modelos como CMMi, entonces tal vez las inspecciones formales propuestas por Michael Fagan resulten muy convenientes.

En lo referente a (2), hay que tener mucho cuidado puessi en la orgnaización hay gente de gran antiguedad que puede sentirse amenaza por este tipo de prácticas. En casos así, la implementación puede llegar a resultar verdaderamente muy dificil y de no hacerlo con la debida precaución podría llegar a resultar contraproducente.

Respecto a (3) creo que el equipo debiera estar conformado por gente con cierto reconocimiento de sus pares, gente que ha demostrado sus habilidades técnicas y que es reconocida por sus pares independiente del título que ostenta dentro de la organización.

Finalmente respecto a (4)  resulta importante mirar el proceso completo, pues solo hacer revisiones y registrar los resultados, no va a llevar por si solo a la mejora. Es necesario definir que hacer a partir de los hallazgos de la revisión.

Algunas recomendación claves a la hora realizar revisiones:

  • El foco es la detección, no la corrección
  • El management no participa de la revisiones (a excepción de lo que se esté revisando sea algún artefacto de gestión como un plan)
  • Lo que está bajo revisión es el artefacto, no la persona que lo produjo
  • Entrenar a los revisores
  • Preparar checklist para realizar las revisiones

Para los interesados en profundizar puedo recomendar algunos materiales que acabo de chequear en mi biblioteca:

Otro titulo importante en esta temática (pero al que no he tenido accesso) es Peer Reviews in Software, de Karl Wiegers.

Por último, les dejo algunos link interesantes sobre el tema:

Espero este ayude a resolver las dudas de mi colega.

¡Nos leemos!

Eventos (académicos) 2012

Durante el año pasado mientras estudiaba para las materias que cursé en la maestría de la UNLP, se me ocurrieron dos artículos que me gustaría desarrollar para presentar en algún congreso y casualmente recien empezado el año tengo tres posibles eventos donde presentarlos.

El primero es ArgenCon, organizado por la sección argentina de IEEE. El mismo se desarrollará del 9 al 13 de Junio  en Córdoba. La fecha límite para el envío de trabajos es el 15 de Marzo.

El segundo evento es la edición 41 de las JAIIO, este año organizadas en conjunto con la UNLP entre el 27 y 31 de Agosto. La convocatoria de trabajos trabajos esta abierta hasta el 30 de Abril.

Finalmente el tercer evento que tengo en el radar es Foro Mundial de Educación en Ingenieria (WEEF: World Engineering Education Forum). Sinceramente nunca había nunca había escuchado hablar de este evento (tal vez porque no siempre se realiza en Argentina). El mismo será organizado por UTN y se desarrollará en Buenos Aires del 15 al 18 de Octubre. La fecha límite para el envio de trabajo es el 2 de Marzo.

Volviendo a los trabajos que tengo en mente, el primero es sobre el enfoque que estoy utilizando en UNQ para dictar ingeniería de software. El otro es sobre algunas ideas que he venido madurando para la enseñanza de la programación en los cursos introductorios de programación.

Sueldos IT (version 2011)

La semana pasada en iinfo (la lista de correo de ingeniría informática de la UBA) surgió un hilo de discusión sobre este tema. Un dato importante mencionado durante la discusión por GuidoDeB es que la Cámara Cámara de Empresas de Software & Servicios Informáticos de la República Argentina (CESSI), a través de su Observatorio Permanente de la Industria del Software y Servicios Informáticos (OPSSI), elabora un informe sobre la evolución salarial semestral dentro de las empresas del sector, socias de la cámara.

A continuación les dejo algunos de los links que se compartieron durante la discusión.

 

Chau 2011

¡Adentro! se fué el 2011 y tal como lo dijera en su momento: 2010 fue un año bisagra y con 2011 empezó una nueva etapa. Entre los hechos destacados de esta nueva etapa debo mencionar:

Respecto de eventos fui orador en Codecamp y en Smalltalks,  participé activamente en el Agiles2011 y en el AO Tour y dicté un workshop en el contexto de ASSE/JAIIO.

Otro punto que quiero destacar es que he mantenido mi constancia en este blog. Durante 2011 escribí 88 post superando las 66 que había escrito durante 2010. Este incremento de casi 30% también se correlaciona con la cantidad de visitas que paso de casi 7.000 en 2010 a casi 11.000 durante 2011. Intentar superar estos números durante 2012 será sin duda una gran desafío.

Bueno, es todo, chau 2011. Me despido no sin antes agradecer a los lectores de este blog deseándoles un gran 2012 y esperando poder seguir aportandoles mis 2 centavos durante este nuevo año.

¡Salud!