jueves, 26 de noviembre de 2009

Testing práctico de repositorios y servicios con xUnit

Una técnica para hacer testing unitario de repositorios y servicios es usar mock objects. Si bien está técnica nos permite probar aisladamente una clase (es el objetivo de una prueba unitaria), en casos simples me parece que es más difícil construir el mock que la funcionalidad.

Supongamos que estamos trabajando con un sitio simple de contenidos. Nuestros repositorios pueden ser del tipo:

IContentRepository {
Content GetById(int contentId);
Ilist GetBySection(int sectionId);
}

Y nuestro servicio:

IContentManagementService {
Content GetContentById(int contentId);
Content GetDefaultContent();
Ilist GetBySection(int sectionId);
}

A veces por cuestiones prácticas conviene no seguir algunas reglas (cómo la de usar objetos mock) y testear directamente sobre los objetos que construimos. Un simple assert, puede hacer mucho por nosotros (para repositorios y servicios):

Ilist contents = repository.GetBySection(1);
Assert.IsNotNull(contents);
Assert.IsTrue(contents.size > 0);

Nos puede ayudar a probar varias cosas, como por ejemplo:
  • Que mapeamos bien los objetos en el ORM.
  • Las expresiones de las consultas (hql, linq, sql, etc.) no dan error al ejecutarse.
  • Las dependencias de IoC. Esto puede no servir de mucho, si tenemos un contexto de IoC para test y otro para la aplicación.
  • Si se hicieron cambios en la base de datos no se rompió nada.
  • Que mínimamente todo funciona, lo cual es muy bueno frente a no probar nada.
Estos tipo de test son muy rápidos y fáciles de crear. Lo único que requieren son de una base de datos especial de testing, para que los test no se vuelvan inválidos con el tiempo, ya que es muy probable que los datos en desarrollo cambien.

Incluso con una pequeña modificación se podrían probar las consultas:

Ilist contents = repository.GetBySection(1);
Assert.IsNotNull(contents);
Assert.AreEquals(5, contents.size);

Es cierto que no sería una prueba unitaria 100%, pero tiene una buena relación costo / beneficio.

saludos!

sábado, 21 de noviembre de 2009

Integración kudewe reports con sistemas legacy

Un punto importante a resolver en una herramienta de reporting es la integración con otros point solutions. Lo primero que pensé fue en una herramienta tipo ETL para extraer los datos de los point solutions, transformarlos y cargarlos en kudewe reports. Buscando encontré esta lista open source:

Quería algo liviano, simple y fácilmente testeable. Algunas de estas herramientas son visuales (kettle, cover etl, talend) seguramente en poco tiempo y sin conocimientos de programación se pueden construir procesos ETL simples. Pero una desventaja es que no tienen automatizados los test (al menos que yo sepa). Leyendo en la lista me encontré con spring batch.

Estás son algunas características interesantes de spring batch:
  • Tiene un lenguaje de dominio muy claro del mundo batch.
  • No tengo que aprender una herramienta nueva, toda la aplicación está construida en java.
  • Clear separation of concerns.
  • Basado en objetos POJO => simple y fácilmente testeable.
  • Cada pieza se puede testear unitariamente, como así también todo el punta a punta.
  • Es escalable, probada, sigue la filosofía de spring.
  • Se complementa con herramientas de schedule, tipo quartz.
El objetivo de este sprint es integrar kudewe reports con una aplicación web asp / ms access. Dado que es la primera vez que hago algo parecido, hay algunas cuestiones que presentan ciertos riesgos y que por lo tanto conviene encararlas tempranamente. Por eso, lo primero a resolver es cómo conectarse a una base de datos ms access desde java. Intenté hacerlo desde ubuntu, pero no encontré como. Leí algunas cosas de un puente odbc-jdbc, pero me parecieron complejas. Por lo que opté hacerlo desde windows, que es el entorno de mi cliente. Para eso encontré un ejemplo simple:

si queremos acceder a través de un dsn, este otro ejemplo explica como:

Lo siguiente es ejecutar los ejemplos de spring batch. Para eso tuve que instalar maven

y agregar a eclipse.ini la ubicación de la vm (requerido por maven, importante escribir la configuración en 2 líneas):
-vm
C:\Archivos de programa\Java\jdk1.6.0_17\bin

Luego, para abrir los ejemplos de spring batch solo que hay crear un nuevo proyecto java en eclipse y seleccionar la carpeta que contiene el ejemplo. Automáticamente se instalarán las dependencias configuradas en el archivo .pom.

Ahora a revisar el ejemplo spring-batch-simple_cli para hacer la prueba de concepto...

saludos!

domingo, 15 de noviembre de 2009

Equipos auto organizados: la cordada

Algo interesante de scrum es que puede aplicarse a otras actividades, no solo al desarrollo de software. De hecho, me imagino sería muy enriquecedor usarlo en escenarios que no tengan nada que ver.

Muchas de las cosas que plante scrum no son nuevas, como por ejemplo los equipos auto organizados. Es muy interesante la dinámica de un equipo que no sigue las reglas de un líder, sino donde el liderazgo es emergente y contextual.

El primer ejemplo que se me ocurre es la cordada. Una cordada es un grupo de personas con un objetivo en común: escalar. Se le llama cordada porque generalmente van encordados (atados). El ir atados es algo muy simbólico para un equipo. Uno a uno los integrantes de van exponiendo al riesgo y los otros lo protegen a través de la cuerda.

Encontrar la mejor manera de escalar una montaña es un problema realmente difícil. Es prácticamente imposible planificarlo todo de ante mano. Generalmente antes de salir acordamos qué equipo llevar, cuanta comida, días, etc. Pero sobre la marcha el equipo se va auto organizando según el contexto. Puede ser que el clima cambie, o que uno se sienta mal o más fuerte o con más ganas. Hay miles de factores que pueden influir.

Me acuerdo de una vez que empezamos a escalar de noche y nos íbamos turnando para abrir huella en la nieve. No pasó que el líder de la expedición dijera "cada uno camina 20 minutos al frente y se va rotando". Todo lo contrario, no había líder. Simplemente acordamos ir caminando por turnos, el que va adelante controla el ritmo y cambia cuando se siente muy cansado o cuando considera que otro puede hacer mejor el trabajo. Y todo se hace en función del equipo, no del interés de un individuo. Según mi experiencia en la montaña, este tipo de dinámicas son muy integradoras y generadoras de buenas amistades.

saludos!

miércoles, 11 de noviembre de 2009

2do día Curso Scrum Master

Durante el segundo día de scrum aprendí un poco más sobre el framework. Hicimos un juego muy bueno en donde construimos algo en 4 sprints, usando user stories, autorganizándonos como equipo haciendo pequeños plannings y retrospectivas. Fue una actividad muy dinámica en la que aprendí scrum haciendo. Ya voy a poner una foto de nuestro "producto".

Otra actividad que me pareció muy buena fue un role play de una daily meeting en un proyecto que "quema". El PO participó de la reunion con un rol activo (en lugar de escuchando), de hecho fue el 1ro que habló y tiró la bomba. El equipo reaccionó hechando culpas, fue un momento tenso. La cosa estaba muy dicícil para el scrum master, tanto que terminó renunciando. Pero entre todos pudimos aprender mucho haciendo una retrospectiva en conjunto.

La daily meeting es una reunión para detectar problemas, no para resolverlos. Es una reunión para el equipo, donde se crea un espacio para descubrir impedimentos. Es importante no olvidar esto, para pedir al PO que no intervenga (él tendrá su momento en la demo o en una meeting especial) y que cada miembro del equipo explique sus problemas sin buscar culpables, para que no se pierda el objetivo de la reunión.

Algo que me llevo de este segundo día es que el trabajo de scrum master no es nada fácil, todo lo contrario. Pero también es desafiante, ya que se trabaja con el potencial humano y lo que éste puede conseguir. Un buen scrum master debe ser un buen facilitador, mantener discusiones abiertas y guiar el equipo por zonas de incomodidad para que al final todos mejoremos.

lunes, 9 de noviembre de 2009

1er día Curso Scrum Master

Hoy asistí al 1er día de entrenamiento de scrum master. Si bien solo vamos la mitad del curso, me pareció buenísimo la dinámica con que se dicta (gracias a Alan y Ariel). Esta ver no quiero comentar sobre scrum, sus roles/responsabilidades, flujos y artefactos. Sino de algo que creo que va más allá de scrum y está presente en casi toda actividad, que tiene que ver con formar equipos, buenos equipos.

Si bien scrum ayuda mucho a conseguir esto, llevarlo a la práctica encierra un desafío muy grande. Ese desafío tiene que ver con sembrar confianza, fomentar la colaboración, potenciar a las personas, generar transparencia, etc.

Algo que rescato de este enfoque es que se trata de un objetivo que trasciende a lo que hacemos todos los días. Va más allá de construir un ABM o probar una funcionalidad. Se trata de mejorar el entorno en el cual trabajamos, de que todos mejoremos profesionalmente, de construir sobre valores. Suena muy idealista, pero es la base para construir un buen equipo, en cualquier ámbito.

Podré decir alguna vez como Pinti:
Pasan los años, pasan los gobiernos,los radicales y los peronistas, quedan los scrum masters?




domingo, 8 de noviembre de 2009

Instalar SVN en Eclipse Galileo y Ubuntu 9.10

Luego de actualizar Ubuntu 9.10 y bajar Galileo, me pasó que dejaron de andar algunos botontes en eclipse. Por suerte encontré cómo arreglarlo:

Tuve algunos problemas para instalar tigris svn (me dejó de andar el eclipse ganymede, por lo que me bajé el galileo). Asi que sobre el galileo instalé subversive svn:

Luego de esto pude subir sin problemas el proyecto a google code:


saludos!

sábado, 7 de noviembre de 2009

Publicando Kudewe Reports Web en el mundo open source

Hoy voy a publicar en google code el código del front end de Kudewe Reports, que se llama Kudewe Reports Web (me maté con el nombre). Se trata de una herramienta web de reporting que permite fácilmente construir tableros de control (dashboard) que contienen vistas (grillas y gráficos) y filtros (por ahora tipo combo).

Esta es la url del repositorio en goolge code:
http://code.google.com/p/kudewe/source/browse/#svn/trunk/reportsWeb

El front end es una aplicación web estática html + javascript estándar, basada en el framework extJs. Me decidí por usar un front end que sea independiente de la tecnología server side, para que cualquiera lo pueda usar, ya sea .net, java, php, etc. También elegí esta alternativa para poder en el futuro agregar la posibilidad de funcionar de manera offline. En mi caso un front end independiente de la tecnología server side me resultó fácil armar y fácil de testear.

Estas son unas demos que armé:

En mi caso estoy usando como pegamento entre el client side y server side spring web y url amigables:

Algo interesante, y sobre lo que tengo que escribir, es que la aplicación está construida como una composite web application. Los filtros y las vistas tienen bajo acople entre si. Pasa eso estoy usando un patrón tipo publish/subscribe implementado con Tibco PageBus.

También me gustaría armar algunos tests usando selenium. Esto es algo que podría hacer fácilmente, ya que el front end no tiene dependencias a ninguna tecnología server side. Cuando este ejecuta un servicio json, el webserver devuelve un archivo ubicado en el path solicitado. Por ejemplo:

services/menu.json: Devuelve el menú de la aplicación
services/sales/yearly.json: Devuelve la definición del dashboard "yearly"
services/sales/yearly/filter/brand: Devuelve el filtro "brand" del dashboard "yearly"
services/sales/yearly/view/byBrand: Devuelve las ventas por marca "byBrand" del dashboard "yearly"

saludos!

Sol + sal = energía

Gracias a idea connection, me enteré de una manera innovadora de generar energía a partir del sol.

Algo parecido había visto hace tiempo, donde leí que google estaba investigando en tecnologías de espejo para abaratar los costos de generación de energía (http://energiasolarok.blogspot.com/2009/09/google-por-la-energia-solar.html)

Me alegra escuchar sobre nuevas iniciativas que ayudan a que esto sea cada más fácil de implementar. En nuestro país la energía solar no es barata, un panel de 80w vale aproximadamente $2500. Todavía tenemos que trabajar en disminuir estos costos, para que este tipo de alternativas sean más accesibles y más personas se animen a utilizarlas. También me parece importante que empecemos a pensar sobre estos temas y a cambiar nuestras prioridades. Me viene a la mente una frase que me sirve para poner las cosas en perspectiva:

No heredamos la tierra de nuestros padres, sino que la tomamos prestadas de nuestros nietos.

saludos!

domingo, 1 de noviembre de 2009

De la relación de dependencia al emprendimiento

Últimamente me pasa seguido de conversar con amigos respecto a trabajar en otra cosa, algo propio. Lo que compartimos en general es que después de estar algunos años en el mismo trabajo, es difícil mantener la motivación.

Una vez escuche en una charla de @bilinkis, que las empresas buscan el engranaje que mejor encaje en su maquinaria. El problema con esto es que nosotros somos personas, no engranajes, tenemos particularidades que nos diferencias y es en nuestras particularidades donde se esconde nuestro potencial. Por lo que en una empresa se hace realmente difícil explotar ese potencial al máximo. Con lo años, uno se va acostumbrando a cómo hacer las cosas para que la maquinaria funcione mejor y poco a poco se va aplacando eso que nos hace distintos.

Muchos me dicen que estando por tu cuenta trabajás más. Si bien esto es algo que parece cierto, ya que conozco algunas experiencias que lo confirman, creo que en mi caso prefiero trabajar 12hs motivado que 8 sin motivación.

Así que este post es para los que buscan motivación en el trabajo. En mi caso me ayudó mucho empezar a leer blogs sobre enterpreneuship. Este fue uno de los primeros que leí, que habla sobre la transformación de desarrollador de software a emprendedor de software:

Este es otro muy bueno, que habla sobre cómo conseguir clientes, organizar el tiempo, etc:

Uno muy bueno, para empezar a concretar algo, es el Santiago Bilinkis:

Me han servido de mucha ayuda sus post para bajar una idea a algo más concreto y empezar a enfocarme:

Ahora me pasa que tengo en claro lo que quiero hacer (construir aplicaciones de software usando energias limpias), de hecho ya estoy trabajado en la primera: kudewe reports. Sin embargo, necesito dedicarle más tiempo a este proyecto. No estoy en condiciones de abandonar mi trabajo actual para dedicarme de lleno a esto, ya que en el super no me pagan por mis aportes a la humanidad.

Pero buscando y buscando encontré una solución, conseguí un trabajo de 4 días a la semana que además es un interesante desafío profesional (.net, arquitectura, scrum). Por lo que ahora puedo dedicar más tiempo a este proyecto.

saludos!