Autor: NicoPaez

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!

Orientación a Obejtos Pura

Es común cuando se presenta Smalltalk mencionar que es un lenguaje orientado a objetos puro. También es común que la audiencia no logré captar el significado de esta afirmación inmediatamente. Yo mismo he analizado esta afirmación montones de veces, pensando que tal vez sea un poco extrema, pero esta semana, vi la luz y me dí cuenta de que es absolutamente acertada.

Resulta que por estos dias, me encuentro entrenando a un grupo de programadores en C#. Fue en este contexto que me encontré hablando de las diferencias y relaciones entre interfaces, clases, estructuras (structs) y enumerados, ¡recorcholis! 4 artefactos del lenguaje que NO son objetos. ¡Y aún no expliqué eventos, delegados, tipos primitivos y atributos (anotaciones)!. ¡Cuantas cosas que explicar!

¡Cuanto más fácil seria explicar Smalltalk!

¿Bug en Mercado Libre?

Busco un producto, reviso las opciones, finalmente me decido y compro.Voy a retirar el producto, llego a casa y veo que no tiene una característica que recuerdo explícitamente me interesaba.

Entro a mi cuenta de Mercado Libre a ver los detalles de la compra. En mi lista de compras figura el item comprado junto con su precio (digamos $100). Hago click en el item para ver el detalle de la compra y me lleva a la publicación. Pero…. ¡rechorlis! la publicación ha sido actualizada, el precio ya no es $100, sino $80 y la especificación a cambiado.

Llamo al vendedor, explico la situación. El flaco comprende el problema y admite que hubo una actualización en la publicación. Me indica que me acerque al local asi arreglamos la situación. Parece que no va a haber problemas, mañana les cuento.

Si el flaco no tenia buena onda, yo estaba al horno, pues al parecer Mercado Libre no guarda «una foto» de la publicación al realizar la compra. Hablando tecnicamente, parece que la entidad compra, no tiene los detalles de la compra sino simplemente una referencia a la entidad publicación. Puede que esto sea asi explícitamente por diseño, pero desde el punto de vista del negocio, yo creo que es un Bug, pues yo como comprador quiero poder tener el detalle exacto de lo que compré independientemente de que la publicación sea actualizada.

Por otro lado miro mi lista de compras y veo que solo figuran las más recientes, las compras que realicé hace 11 meses no figuran en el listado. Mmmm esto tampoco me gusta, pues tampoco veo ningún link del estilo «Ver compras anteriores».

Nota: si bien el post está escrito en primera persona, esta situación no me sucedió a mi sino mi hermano, pero yo la seguí de cerca e incluso la reproduje.

Sobre el hosteo de aplicaciones en Heroku

Luego de estar trabajando con Heroku por un par de semanas, hoy voy a compartir algunos algunos consejos útiles.

Suele ser una buena práctica al desarrollar una aplicación, manejar distintos ambientes. En general suelen manejarse al menos 4 ambientes, puede que los nombres varíen, pero en líneas generales podríamos decir:

  1. Desarrollo, donde se desarrolla aplicación
  2. Test/integración, ambiente similar de desarrollo donde se ejecutan la pruebas
  3. Staging, ambiente de prueba lo más parecido posible al de producción donde se realizan las pruebas de aceptación (UAT)
  4. Producción, ambiente final donde correr la aplicación

Al trabajar con Heroku tendremos

  1. Desarrollo es la maquina del desarrollador
  2. Test/integración, es el build server
  3. Producción ya dijimos que seria heroku, por lo cual
  4. Staging también debería ser heroku.

Si uno está dispuesto a pagar, heroku nos permite manejar más de un ambiente en la misma aplicación, pero si pretendemos un enfoque gasolero al máximo, entonces tendremos que generar 2 aplicaciones: una representará nuestro ambiente productivo y la otra a nuestro ambiente de staging. Dado que el comportamiento de ciertos componentes puede varias dependiendo de ambiente en que se encuentre, para que nuestra aplicación Heroku de staging se comporte como tal, tendremos que setear la correspondiente variable de entorno utilizando el siguiente comando

heroku config:add RACK_ENV=staging

Esta variable tiene como valor por defecto production y por eso es que no la modificaremos para nuestra aplicación de producción.

Utilizando esta variable podremos definir distintos parametros de configuración para cada uno de nuestros ambientes.

configure :production do
  DataMapper::setup(:default, ENV['DATABASE_URL'])
  DataMapper.auto_upgrade!
end

configure :staging do
  DataMapper::setup(:default, ENV['DATABASE_URL'])
  DataMapper.auto_upgrade!
end

configure :development do
  DataMapper::setup(:default, "sqlite3://#{Dir.pwd}/mydata.db")
  DataMapper::Model.raise_on_save_failure = true
  DataMapper.auto_upgrade!
end

configure :test do
  DataMapper.setup(:default, "sqlite::memory:")
end

Para poder desplegar nuestra aplicación a los correspondientes ambientes, tendremos que agregar los correspondientes repositorios git remotos. En general uno ya lo tendremos seguramente bajo el nombre heroku, pero para evitar confusiones lo mejor seria removerlo y volver a agregarlo con un nombre mas representativo. Para ello podemos hacer

git remote add production <git-de-la-app-heroku-de-production>
git remote add staging <git-de-la-app-heroku-de-staging>

El hecho de que el despligue a Heroku este basado en git, hace muy simple el versionado de la aplicación y la vuelta atras a una versión anterior. Pero más allá de esto hay un plugin que estoy utilizando llamado Releases. Este plugin ofrece cierta funcionalidad básica en su versión gratuita (como agregar un número amigable de versión a cada despliegue y la posibilidad de hacer un rollback del último despliegue).

Continuará…

Fin de mi primer cuatrimestre en Ingeniería de Software

Finalmente el lunes pasado cerramos la materia. Entregué las notas he hicimos una retrospectiva. Si bien la materia no salió exactamente como la había planeado, estoy conforme con el resultado. Creo que logré transmitir conceptos importantes y algunas herramientas concretas para el desarrollo profesional, la organización personal y el trabajo en equipo. Comencé el cuatrimestre con 15 alumnos y lo terminé con 12. Por lo que pude hablar con algunos alumnos, aquellos que dejaron la materia lo hicieron principalmente porque tenían otra expectativa respecto de la dedicación que la materia requería. Incluso los alumnos que completaron la materia, también coincidieron en este punto. Esto me parece totalmente entendible, pues hubo efectivamente un cambio de docente y con el ello también un cambio de dinámica. Varios alumnos venian con la expectativa de una materia más tradicional: asistir a clase, realizar un serie de trabajos prácticos y rendir un examen. En lugar de ello se encontraron con tareas semanales, muchas lecturas y varios entregables. Todo esto de forma constante a lo largo de todo el cuatrimestre. Y fue explícitamente así, pues a mi entender los proyectos se hacen día a día TODOS los días, de forma constante. Al mismo tiempo les pedí a los alumnos que dieran visibilidad constante y temprana, avisando cada vez que iban a faltar a clase o llegar tarde. Los alumnos que completaron la materia, comprendieron el objetivo de este pedido y reconocieron su importancia. La importancia no radica en avisar si faltan a la materia, sino en generar el hábito, hacer que los alumnos se acostumbren a dar visibilidad. En el contexto de toda actividad uno puede sufrir atrasos, imprevistos, etc, pero lo que NO puede hacer bajo ningún punto de vista es no dar visibilidad.

En fin, por ahora, esto es todo, más adelante comentaré algunas conclusiones de la retrospectiva.

Finalmente les dejo la foto de mi primera promoción de Ingeniería de Software, ¡felicitaciones estudiantes! (y gracias por aguantarme)

Y un día llegué a Ruby…y publiqué una gema

Y si, después de haber trabajado con Delphi, PHP, C#, Java, C/C++, Smalltalk y Python finalmente me tocó Ruby.

Recién estoy dando mis primeros pasos, no conozco bien la sintáxis y al mismo tiempo hay ciertos idioms que me resultan incómodos, pero más allá de eso he encontrado varias similitudes con Smalltalk que me han resultado muy amistosas.

A diferencia de muchos de los que se acercan a Ruby, no he hechado manos a Rails. Mi stack de desarrollo se compone de Sinatra+Datamapper+SimpleDB+Heroku. He aquí otro punto interesante, luego de trabajar con la plataforma Azure, Heroku me pareció extremadamente simple y sólido. La experiencia de usuario es muy….¿suave?, en inglés diria smooth, con lo cual creo que suave es una traducción aceptable.

La aplicación que estoy desarrollando tenia como requerimiento funcionar con identidad federada. Si bien en Southwoks ya teniamos un gema para resolver dicha cuestión, la misma corria sobre Ruby 1.8 y la idea era que mi aplicación corriera sobre 1.9 pues tiene varias mejoras interesantes. Asi que luego de un poco de investigación y algunas pruebas de concepto logré dar con un código que permite federar mi aplicación usando tokens del tipo SWT.

Y estaba tan entusiasmado que di un paso más y empaqueté dicho código en un gema (este es el nombre que se le da a las librerias reutilizables en Ruby). La gema está disponible en RubyGems y el código fuente en GitHub.

Próximamente más sobre mis aventuras en Ruby.