Categoría: opinion

Google Hangout Rocks!

Esta última semana estuve trabajando en un proyecto de desarrollo en forma distribuida y para comunicarnos decidimos utilizar Google Hangouts. Nos funcionó muy bien, nos permitió  hablar y compartir los escritorios para revisar fragmentos de código.

Pero esta mañana fuí un poco más lejos y exploré la funcionalidad de streamming vía YouTube. Esta funcionalidad permite hacer streamming en vivo  utilizando una cuenta de YouTube y como si eso fuera poco, lo streameado queda disponible como video en YouTube (perdón a la real academia por la utilización de tal término). La experiencia me resultó tan buena que tengo ganas de grabar varios videos más.

Aquí pueden ver un hangout que grabé a modo de prueba.

Build Server Gratuito en la nube: TravisCI

Ayer descubrí TravisCI, un build server gratuito y open souce para proyectos open source. Si bien no tiene en principio todos los features de Jenkins (en cuanto a reportes, notificaciones, etc, etc) cumple bien su trabajo de build server.

Trabaja integrado con GitHub y para disparar los build utiliza un hook the Github. Ofrece soporte para los siguientes lenguajes: Clojure, Erlang, Groovy, Java, Node.js, Perl, PHP, Python, Ruby y Scala.

Lo probé con mi proyecto SWTFederation y la verdad que me sorprendió lo simple que fue la configuración.

Espero les resulte útil.

Sobre C# y Ruby

Esta es la continuación del post que publiqué ayer, pero que en realidad es más bien una precuela.

Resulta que la semana pasada estaba hablando con unos colegas de Algo3 sobre tecnologia y comenté mi amistosa incursión en Ruby. Ante esto, uno de mis colegas me tildó de panquequearme, pues la mayor parte de mi carrera he argumentando a favor de C# y la plataforma .NET en general.  Hoy por hoy y para una gran cantidad de aplicaciones prefiero inclinarme hacia Ruby, no porque me parezca más apropiado sino porque me siento más cómodo (incluso a pesar de conocer mucho menos). Pero esto no me convierte en panquete, pues mi cambio de opinion no fue ni reiterado ni en corto plazo de tiempo.

Recuerdo que la primera vez que me acerqué a Ruby fue durante 2006, cuando trabajando en Snoop me tocó participar en un proyecto en el cual el cliente nos pedia definir su plataforma y nos había pedido explícitamente evaluar .NET, Java y Ruby. Al cabo de 3 semanas de trabajo nuestra recomendación fue .NET. Pero bastante han cambio estas tecnologias desde aquel 2006 hasta la actualidad (¡pasaron 6 años!).

Ahora hablando un poco sobre el título de este post, creo si bien ambos lenguajes a simple vista parecen bastante distintos, tienen varias cosas en comun en cuanto a la caraterísticas que soportan. Sin duda la diferencia más distintiva es el hecho de que C# es de tipado estático y Ruby de tipado dinámico. Esto implica que en el caso de C# es necesario realizar una compilación explícita antes de pedirle a la maquina virtual que ejecute nuestro programa. Por otro lado, Ruby incorpora varias cosas de Smalltalk (metaclases, bloques, etc) lo cual me resulta muy feliz.

Más allá de las bondades del lenguaje, debo admitir que me he sorprendido a mi mismo, pues nunca crei que pudiera programar con un editor de texto (gedit) luego de haber trabajado por tanto tiempo con Visual Studio y Eclipse. Cuando trabajo en ruby codeo con gedit y tengo dos terminales abiertas, una para hacer el build y otra con irb (el interprete interactivo de ruby) para probar cosas del lenguje, pues aun no estoy suficientemente familiarizado. Cuando esporáricamente tengo que levantar Visual Studio o Eclipse, me deprimo mal, ambos entornos tardan una eternidad en levantar (a pesar de que tengo 4 GB de memoria). Y ni hablar cuando quiero compilar una solucion y correr las pruebas con visual studio.

Más allá de mi opinion (totalmente subjetivas) y de los gustos particulares de cada uno, creo que es importante que todo estudiante/profesional de sistemas haga una experiencia en ambos mundos: el corporativo (C#/Java) y el open source (ruby/python/smalltalk).

Por lo dicho en el post anterior, esa calificación no me aplica pues mi cambio de opinion

hace algunos años habiaal encarar un proyecto había tenido que elegir entre .Net y Ruby y en aquel momento habia elegido C# practicamente sin dudarlo (pero ojo, había investigado Ruby)

Cambiar de opinion no siempre es «panquequearse»

Una conocida frase dice «Se dió vuelta como un panqueque» y de ahí el término «panquequearse».  Esta frase suele utilizarse para hacer referencia a personas que cambian radicalmente de posición respecto a un tema. La analogia con el panqueque me parece bien, pero creo que no siempre se la interpreta correctamente. Paso a explicar.

La particularidad de la «dada vuelta» del panqueque es que ocurre reiteradas veces y en un breve lapso de tiempo. Entonces para que una persona sea etiquetada con la frase en cuestión deberia ocurrir que que dicha persona cambie de opinion varias veces en un breve lapso. Siguiendo esta línea de pensamiento, creo que uno de los mejores ejemplo de panquequeda en la actualidad lo constituyen (algunos) periodistas deportivos: Si Boca gana Riquelmente es un el mejor, si Boca no gana (lo cual ocurre la semana siguiente), Riquelme es un desastre. Como diria EL Diego, esos periodistas son los mismo que le toman la leche al gato y le roban la limosna al ciego. (ups! me fuí de tema)

Por otro lado, cambiar de opinión es algo sano en un punto, pues siginifica en muchos casos un aprendizaje, ¿acaso uno no cambia de opinion muchas veces luego de  aprender una lección?.

Este post ya se hizo demasiado largo para mi gusto, asi que corto aqui y en el siguiente post les cuento  que fue lo que me llevó a escribir esto.

Continuará…

El solo hecho de que una persona cambie de opinión (por más drástico que sea el cambio) no la «convierte en un panqueque»,

Agilistas: BASTA de tomarle la leche al gato

Hoy comencé a tomar un curso sobre ingeniería de software y una vez más me encontré con Agile vs. Waterfall. Basta por favor, como dice El Diego esto es como tomarle la leche al gato o robarle la limosna al ciego. Ojo, hacer la comparacion no está mal, lo que me parece mal es que se pretenda explicar agile comparandolo contra waterfall. Y le pegan a waterfall, una y otra vez y otra vez. ¿Porque no hacer una comparación de Agile vs Métodos orientados al plan? ¿Será que la gente aún no lo tiene claro? No sé, no entiendo, pero a esta altura escuchar gente hablando mal de waterfall me empieza a sonar molesto.

Hago un pedido a los agilista: por favor, cuando quieran presentar agile busquen algún otro mecanismo que no sea pegarle a waterfall.

¿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á…

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!

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!

Sinatra Modular Applications with Ruby 1.9

Disclaimer: what I write here is something that is working for me, but I am not an expert, so I cannot declare this to be the best solution.

I am working on a small application that I know it will grow, so the traditional Sinatra application could be a mess when I have more than 10 routes.

So the strategy I have chosen is to create a base class called BaseController inheriting from Sinatra::Application, this base clase will handle global application settings.


#./base_controller.rb
require 'sinatra/base'

class BaseController < Sinatra::Base
  get '/' do
    'Home (base controller)'
  end
end

Then, I create one controller class for each application module, each of this controllers should inherit from my BaseController.

#/controllers/module1_controller.rb
require File.join(File.dirname(__FILE__),'..', 'base_controller.rb')

class Module1Controller < BaseController
  get '/' do
    'Module 1'
  end
end

Finally, in the config.ru file I define the base routes for each controller.

# config.ru
require './base_controller.rb'
require './controllers/module1_controller.rb'

map '/' do
  run BaseController
end

map '/module1' do
  run Module1Controller
end

Note: the code snippets above assume that the base_controller.rb and config.ru files are located in the root directory while every all controller files are located under «/controllers» directory.

You can download the source code from here.

Censo Docente UBA (+1)

Hace un tiempo escribí sobre mi experiencia completando el censo docente de UBA. La buena noticia es que el mensaje que envié vía la página de visitas de la UBA, llegó a buen puerto y me contactaron vía mail. En el mail me daban algunas explicaciones y me pedían más detalles sobre los puntos flojos que yo mencionaba. Algo que me llamó la atención es que algo que yo veía como un issue, para los responsables del censo es en realidad un feature. Puntualmente estoy hablando del feature/issue que impide que uno regrese a modificar los datos ingresados en una sección del censo luego de haberla completado.

En fin, ayer me senté y contesté el mail, dando tantos detalles como recordaba (pues el sistema no me permite ingresar otra vez para analizarlo). Al mismo tiempo, para cada punto mencionado, intenté sugerir una posible solución y finalmente envié un link al material de usabilidad que vemos en algo3.

Más allá de las opiniones y de si tienen en cuenta mis comentarios o no, creo que lo importante es que dieron una respuesta a mi inquietud a pesar de que la misma fue enviada por un canal informal. Esto es algo que en instituciones tan grandes y burocráticas como UBA muchas veces es difícil.