Autor: NicoPaez

Proyecto CMS, día #4 y #5

Me atrasé, por eso aquí paso el reporte de los últimos dos días.

El día #4 (el lunes pasado), fue durísimo, muy poco avance pues me pasé casi todo el día haciendo troubleshooting de ciertas funcionalidades que detectamos no corrian correctamente en el ambiente de prueba. Primero habia una temita con ciertos chequeos de seguridad de Rails que se activan por default cuando la aplicación corre en environment=production. Una vez detectado y resulto este tema, surgió algo inesperado. La gema XMLObject (que mencioné en otro post) lanzaba una excepción en el ambiente de test, pero en mi máquina y en el build server andaba joya. Finalmente resulto que se debia a un cambio de implementación en una dependencia que en Ruby 1.9.3 andaba joya pero no así en Ruby 1.9.1 (versión de la instancia de test). La solución «rápida» una vez detectado el problema, fue remplazar esa gema por Nokogiri. Por suerte el cambio era interno a una clase la cual tenia los correspondientes test. No hubo mayor historia pero me consumió muchísimo tiempo.

El día #5 fue mucho más productivo, logramos completar las dos stories siguientes en orden de criticidad para el negocio y al mismo tiempo un miembro de otro equipo se hizo cargo de una story que nos iba a llevar mil años implementarla por no estar familiarizados con un determinado módulo de la aplicación.

Continuará…

 

Proyecto CMS, día #3

Un día realmente complicado pero para que se entienda debo dar un poco más de contexto del proyecto. Anteriormente mencioné que tenemos varios equipos trabajando en distintos lugares alrededor del globo, pero lo que no mencioné es que cada equipo trabaja en cosas distintas, básicamente cada equipo tiene un subproyecto. La visión global del proyecto es tomar un sitio existente y ponerlo a correr sobre la plataforma CMS. Esto implica varias cuestiones:

  • Agregar a la plaforma CMS algunas funcionalidades faltantes (aquí estoy yo)
  • Estabilizar algunas funcionalidades de la plataforma que hasta el momento no estaban en uso (equipo en India)
  • Migrar la información del sitio «viejo» a la plataforma (equipo en USA)
  • Realizar diversos ajustes a nivel de infraestructura (otro equipo en USA)
  • Realizar varias gestiones a nivel organizacional (por ejemplo el anuncio de prensa)

Todo esto nos lleva a que distintos equipos, trabajando en distintos lugares, en distintas bandas horarias, se encuentren tocando el código de una misma aplicación. Uno podría pensar que usar una estrategia de feature branch podría ser apropiado, pero quienes llevan la batuta del proyecto tienen una postura bastante extrema y se han tomado la cuestión del delivery contínuo muy a pecho. Por ello es que todo el mundo trabaja sobre el trunk utilizando una estrategia de Feature Toggle. Personalmente no me termina de convencer, pero por ahora funciona. Al mismo tiempo, para poder dar soporte a la estrategia de delivery contínuo contamos con una robusta infrastructura basada en Jenkins y Heroku. Tenemos dos ambientes casi identificos corriendo en Heroku: preview y producción. Cada vez que se completa una story, se realiza un depliegue a preview. Por su parte Jenkins tiene 4 trabajos:

  • Integración contínua, se dispara automáticamente en cada commit, ejecuta las pruebas unitarias (Ruby y JavaScript) y verificaciones de código
  • Integración, ejecuta pruebas de integración y se dispara automáticamente luego de cada despligue a preview
  • Depliegue a Preview, se dispara manualmente y como su nombre lo indica, despligue la aplicación y tagguea
  • Depliegue a Producción, se dispara manualmente

La complicación del día se debió a que el equipo estaba trabajando en la migración de datos, probó sus scripts con la base del ambiente de preview y ello generó ciertas inestabilidades en la instancia de preview. La situación se vió agravada porque este equipo no avisó de esto al resto de los equipos. ¿y porque no mencionaron eso en la reunión de standup? Simplemente porque no asistieron, ja!. Para sumar un poco más de tensión a la situación, resulta que en otra parte del globo estaba el cliente probando la aplicación, ja!.

En cuanto se detectaron las inestabilidades, todos los equipos suspendimos nuestras tareas y nos pusieron a ver cuales eran las causas de las misma. Luego de varias verificaciones detectamos que el problema se debía a los datos inconsistentes/faltantes y pudimos resolverlo. Todo este revuelo me costó dos horas. A pesar de eso pude completar mis compromisos del dia y desplegar mis stories al ambiente de preview.

Una vez más ví confirmada mi tesis, el principal factor de éxito de los proyectos, no es una cuestión de técnica, sino humana: comunicación.

Continuará…

Proyecto CMS, día #2

Si bien el equipo de Argentina está distribuido, hoy me reuní para trabajar con un compañero pues teniamos que atacar una de las funcionalidades más críticas del proyecto. La jordana fue muy productiva,  mucho TDD, varios debates sobre como nombrar métodos, tres rondas de mate y una taza de café para despejar el sueño luego del almuerzo.

Aprendizajes varios:

  • FactoryGirl, una gema facilitar las pruebas con dependencias de base de datos
  • XML-Object, una gema para acceder a un documento xml utilizando sintáxis de objetos
  • SublimeText es un interesante IDE que en algún deberia probar
  • Si bien en la actualidad hay herramientas como Google Hangout que facilitan mucho el trabajo remot0, no hay nada como el trabajar sentado junto a un compañero y aún más si ese compañero sabe más que uno 😉

Mañana será un día intenso pues vamos a desplegar una nueva versión de la aplicación con las funcionalidades desarrolladas hasta el momento.

Año nuevo, proyecto nuevo (cms): contexto y día #1

Hace ya un tiempo vengo trabajando con gente de ThoughtWorks, Purpose y Tipit, en una especie de CMS para montar sitios de ONGs. Un par de dias atrás me contactaron para un proyecto puntual: hacer una prueba de concepto agregando soporte de donaciones recurrentes utilizando el servicio de Recurly. La prueba de concepto fue exitosa y cliente nos pidió que hicieramos la implementación «posta» de esta funcoinalidad para así poder montar en la plataforma el sitio de una ONG.

Dadas ciertas restricciones de negocio, el proyecto fue definido tipo «comando»:  8 dias para implementar la funcionalidad de donaciones, montar el sitio de la ONG y ajustar varias cuestiones de UI. En términos más concretos el proyecto debe dar solución a 8 user stories. Algunos datos de contexto del proyecto:

  • Equipo distribuido entre Argentina, USA e India
  • Tecnologia base: Ruby
  • Plataforma de ejecución: Heroku + PG + Amazon
  • Herramientas de soporte: GitHub, Jenkins, ChiliProject, Campfire y GoToMeeting

Hoy fue el día #1 y por el momento el mayor riesgo que tenemos son algunas definiciones pendientes del lado del negocio. Si mañana no tenemos algunas de estas definiciones vamos quedar bloqueados y ello va producir retrasos.

Continuará…

Formas de ejecución de FxCop

Ejecución Manual

Si uno utiliza la versión standalone de FxCop, tiene en principio 2 alternativas: utilizar la interface de gráfica o la de línea de comandos.Pero hay que tomar en cuenta que mientras la interface de linea de comandos solo puede ejecutar análisis, la interface gráfica además de ejecutar análisis, permite crear proyectos de FxCop (.fxcop) con configuraciones específicas que incluyan conjuntos particulares de reglas y algunos otros parámetros específicos para la ejecución del análisis. Al mismo tiempo ocurre que la interface de línea de comando soporta  algunos opciones que la interface gráfica no, por ejemplo rulesets (.ruleset)

Otra forma de ejecutar análisis FxCop en forma manual es si uno cuenta con una version de Visual Studio que tenga la funcionalidad de Code Analysis incorporada. Es ese caso, pueden configurarse las reglas a aplicar desde las propiedades del proyecto y luego disparar el análisis desde el menú contextual del proyecto.

Ejecuación integrada a la compilación

Si uno cuenta con una versión de Visual Studio con la funcionalidad de Code Analysis incorporada, entonces también tiene opción de modificar los archivos de proyecto (.csproj) para que se dispare el análisis de código en cada compilación.

Ejecución con MSBuild

Esta opción es mi prefedida pues es independiente del Visual Studio lo cual la hace ideal a la hora de utilizar un build server. Básicamente consiste en generar un build script de MSBuild con una tarea de que se encargue de invocar a utilitario de linea de comando de MSBuild. Tiene un pequeño issue pues ni MSBuild ni FXCop proveen una tarea para ejecutar FxCop dentro de un script de MSBuild, por ello es necesario utilizar MSBuildExtensiónPack. Los interesado en esta opción pueden darle un vistazo a este build script que muestra un ejemplo (ver el target RunCodeAnalysis).

Artesania de Software, el movimiento

Es muy posible que los siguidores de este espacio conozcan algo sobre métodos agiles. En la misma línea que lo métodos ágiles pero yendo un poco más lejos, hace unos años apareció otro movimiento llamado Software Craftsmanship.

Este movimiento pone el acento en ciertas cuestiones de índole más técnica y entre sus referentes cuenta con Uncle Bob, Micah Martin y Paul Pagel (estos últimos dos tuvimos el gusto de tenerlos en la Conferencia Latinoamericana de Métodos Agiles). El punto de entrada a este movimiento es su manifiesto y a mi parecer este video de Uncle Bob.

A modo de resumen les recomiendo este comic que esquematiza bastante bien las distintas visiones del desarrollo de software según el enfoque tradicional, el enfoque ágil y el enfoque craftsmanship.

Cierre de cuatrimestre en UNQ, tercera promoción

El lunes pasado tuvimos la última clase de Elementos de Ingeniería de Software la cual como de costumbre estuvo dedicada a la retrospectiva. Pero antes de entrar en las conclusiones de la retrospectiva, les comparto algunos números:

  • Alumnos anotados: 8
  • Alumnos aprobados: 7
  • Alumnos pendientes de aprobación: 1
  • Nota final promedio: 8,14
  • Fueron un total de 27 clases
  • Tuvimos la visita de un profesional de la industria (¡gracias Emilio!)
  • Trabajamos exhaustivamente con Ruby, Sinatra y Cucumber
  • Desarrollamos varias aplicaciones, las cuales publicamos en heroku y algunas incluso con dominio propio

Personalmente estoy muy conforme con como resultó el curso. A diferencia de cuatrimestres anteriores, puse mucho menos foco en cuestiones de arquitectura/diseño y más énfasis en cuestiones de análisis y especificación (Visual Story Mapping, BDD, etc).

 Respecto de la retrospectiva, los puntos destacados fueron:
  • Mantener:
    • Dinámica de las clases
    • Lecturas
    • Resumenes
    • Herramientas
    • Invitados
    • Clase remota
  • Probar/incrementar:
    • Actividades de relación previas al comienzo de la clase
    • Clases al aire libre
  • Mejorar:
    • La forma de feedback >> Action Item: ser más explicíto al setear expectativas de los entregables y ser  más cuidados con el tono

Para cerrar el post, quiero agradecer a Natalia, una ex-alumna de la materia que colaboró conmigo durante todo el cuatrimestre.

unq-promocion3

Nota: el ícono representa una alumna que estuvo ausente el día de la retrospectiva.

 

FxCop y Visual Studio

Continuando con la cuestión de análisis de código, quiero dedicar algunas líneas a estas dos herramientas. Como mencioné anteriormente,  Visual Studio ha incorporado nativamente a FxCop, pero he aquí algunos detalles curiosos:

  • No todas las ediciones de Visual Studio incorporaron FxCop, en particular las ediciones Professional no lo incorporaron hasta la version 2012 (nótese la diferencia entre version: 2008, 2010, 2012, etc  y edición: personal, professional, ultimate, etc).
  • Dentro de Visual Studio no hay ninguna mención a explícita a FxCop, sino que en los menús figura como Code Analysis, pero internamente es FxCop (pueden verse los assemblies dentro de la carpeta de Visual Studio).
  • Aún es posible descargar FxCop y utilizarlo de manera independiente al Visual Studio.
  • El FxCop independiente y el incluido en el Visual Studio no son exactamente lo mismo. Entre las diferencias hay algunos conjuntos de reglas adicionales que vienen con Visual Studio que no estan en el FxCop independiente.

Los puntos anteriores hacen que dependiendo de la versión específica de Visual Studio con la que uno cuente, la forma ejecutar el análisis de código sea diferente. en próximos post daré más detalles sobre esto.

Análisis de Código en .Net

Al hablar de análisis de código en .Net es necesario diferenciar entre Source Analysis y Code Analysis.

Con Source Analysis nos referimos al análisis del código fuente escrito por el programado (típicamente en C#) el cual se realiza con la herramienta StyleCop.

Con Code Analysis nos referimos al análisis del byte code (MSIL) generado como resultado del proceso de compilación. La herramienta para esto es FxCop.

Ambas herramientas funcionan en base a un conjunto de reglas que pueden personalizarse e incluso extenderse. Si bien estas herramientas trabajan sobre distintos artefactos y tienen distintos objetivos, hay ciertos puntos en los que se superponen. Para entender esto analicemos 3 situaciones «incorrectas»:

  • Una clase escrita en C# nombrada todo en minúsculas, es una situación que seria detectada por StyleCop pero no por FxCop
  • Una clase que oculta un método declarado en una clase base, es una situación que será detectada por FxCop, pero no por StlyeCop
  • Un método con 20 parámetros, es algo que puede ser detectado tanto por StyleCop como por FxCop

Inicialmente ninguna de estas dos herramientas venia integradas con Visual Studio y debian ser descargadas e instaladas por separado. En la actualidad StyleCop continua en esta situación, pero no FxCop, que fue incorporado nativamente a Visual Studio en la versión 2008 (o puede que sea 2010, no estoy seguro).

Continuará…

Radio 3, 2, 1…

Uno de mis hobbies durante la adolescencia fue hacer radio. Aún recuerdo el día de la primera transmisión: 28 de febrero de 1995. Esa primera iniciativa duró 3 años exactos, la última transmisión fue 28 de febrero de 1998. Luego participé de otras iniciativas, más «serias»,  menos improvisadas, con más tecnologia, sobre distintas temáticas, etc. La ultima de ellas fue en 2008, pero desde entonces siempre estoy con ganas de retomar.

Hace un par de semanas un amigo, que también estuvo en aquellas andanzas radiofónicas de antaño, hizo un curso de radio que lo enloqueció e instantáneamente me contagió.

Luego de un par de averiguaciones y pruebas de concepto, finalmente estamos en condiciones de montar nuestra propia radio en internet. En este contexto tendré un espacio con mi amigo en el que hablaremos música, actualidad, etc y por otro lado tendré un espacio dedicado a cuestiones relacionadas al software. Más novedades en breve.