Primeras impresiones con Pentaho Data Integration (Kettle)

UPDATE 090814: Se añade información sobre la ejecución de una transformación y su impact.

A veces en un proyecto software es necesario extraer, transformar y cargar información de una o varias fuentes de datos. A este proceso se le conoce como ETL.

Los ejemplos típicos de procesos ETL incluyen (i) extracciones de datos desde ficheros con diversos formatos, bases de datos o servicios web, (ii) transformaciones como traducciones de valores, calculos de nuevos valores, cruces de fuentes de datos, filtrar registros, generación de claves, división de columnas o pivotar filas a columnas y viceversa, y (iii) cargas a ficheros o tablas de bases de datos.

La tarea puede llegar a ser bastante compleja, no sólo por la diversidad de las fuentes de datos sino por la variedad de transformaciones a realizar. Sobre todo en el caso de las grandes organizaciones, las llamadas Enterprise, donde cada departamento funciona como le da la gana.

Esta semana me ha tocado (lo que tienen las vacaciones, las de los demás claro) realizar un proceso ETL relativamente simple. Así que he aprovechado para probar la aplicación Pentaho Data Integration, también conocida como Kettle o Spoon, que forma parte de la suite opensource Pentaho de Business Intelligence.

La instalación es muy sencilla. Es una aplicación Java, así que necesita tener instalada una JVM. Por lo demás es simplemente descargar, descomprimir y ejecutar el script de arranque.

Con Kettle puedes crear transformaciones y trabajos (jobs) de forma visual arrastrando, uniendo y configurando los distintos pasos.

Una transformación incluye pasos de extracción, transformación y carga del tipo anteriormente comentado y muchos más. Cada uno de estos pasos se puede previsualizar por separado. Una vez diseñada la transformación, se puede validar, ejecutar, debugear, monitorizar, analizar su impacto en el rendimiento y obtener el código sql que genera.


Un trabajo te permite configurar cómo y cuando se ejecutará una transformación. Sus pasos incluyen, a parte de ejecutar una transformación existente, planificar el inicio, abortar, enviar y recibir emails, operaciones con ficheros, ejecutar un http get, evaluar condiciones sobre ficheros, servidores y tablas, ejecutar scripts sql, javascript y shell, validar xml, escribir log y usar ftp, entre otros.


Conviene tener en cuenta el impacto de la transformación sobre la base de datos a la hora de planificar su ejecución en Producción. Normalmente son tareas muy pesadas que pueden afectar al rendimiento general durante muchos minutos. Así que deben ser ejecutadas en horario de mínima actividad.

El uso de Kettle es muy intuitivo y ágil desde el principio, como se puede en las flash demos que hay disponibles en la wiki. De hecho, en menos de una hora ya tenía hecha una primera versión de mi transformación a la que sólo le faltaban algunos detalles de formatos. Para ser mi primera vez estuvo muy bien!

En la wiki también existe una buena cantidad de documentación. Además existe una guía de usuario en pdf bastante completa que merece la pena tener a mano como referencia.

Una sorpresa que me llevé fue que está traducida en parte al castellano. Aunque como todo no puede ser perfecto, el típico botón Ok o Aceptar ha sido traducido por Vale...

En resumen, Kettle (Spoon) me ha encantado. Es muy completo, sencillo y eficaz. Me va a hacer la vida muy fácil cuando tenga que realizar tareas de ETL.

Chuleta Maven

UPDATE 20100126: Añadido cómo configurar el máximo de memoria heap

A continuación una chuleta con buena parte de lo que llevo aprendido usando Maven estos dos últimos meses más algunas referencias.

> 1. CREAR PROYECTOS

Crear un proyecto jar
$ mvn archetype:create -DgroupId=com.example -DartifactId=example-jar-project

Crear un proyecto war
$ mvn archetype:create -DarchetypeartifactId=maven-archetype-webapp -DgroupId=com.example -DartifactId=example-war-project

> 2. ECLIPSE

Configurar plugin eclipse para descargar fuentes y javadocs de las dependencias

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-eclipse-plugin</artifactId>
<!-- Ojo, la versión 2.6 tiene bugs con AJDT -->
<version>2.5</version>
<configuration>
 <downloadSources>true</downloadSources>
 <downloadJavadocs>true</downloadJavadocs>
</configuration>
</plugin>

Crear variable M2_REPO
Ir a Window -> Preferences -> Java -> Build path -> Classpath variable -> New
Name: M2_REPO
Path: /ruta/a/tu/.m2/repository

Generar ficheros de configuración de un proyecto jar Eclipse
$ mvn eclipse:eclipse

Generar ficheros de configuración de un proyecto war Eclipse
$ mvn eclipse:eclipse -Dwtpversion=1.5

Cargar un proyecto en Eclipse
Ir a File -> Import -> General -> Existing project into Workspace -> Select root directory

Borrar ficheros de configuración proyecto Eclipse
$ mvn eclipse:clean

Ahora más que nunca, se recomienda no subir a CVS o similar los ficheros de configuración del proyecto en el IDE.

> 3. CONFIGURACIÓN DE PLUGINS MÁS COMUNES

Configurar un plugin para este pom y sus hijos
En build -> pluginManagement -> plugins

Configurar un plugin sólo para este pom
En build -> plugins

Configurar encoding y versión java de compilación

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.0.2</version>
<configuration>
 <encoding>UTF-8</encoding>
 <source>1.4</source>
 <target>1.4</target>
</configuration>
</plugin>

Configurar plugin surefire para ignorar fallos de tests, definir patrones de nombres de tests aceptados y configurar propiedades de sistema (locale) durante la ejecución de los tests

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.4.3</version>
<configuration>
 <testFailureIgnore>true</testFailureIgnore>
 <includes>
    <include>**/*Test.java</include>
    <include>**/*Tests.java</include>
 </includes>
 <systemProperties>
    <property>
       <name>user.language</name>
       <value>es</value>
    </property>
    <property>
       <name>user.country</name>
       <value>ES</value>
    </property>
 </systemProperties>
</configuration>
</plugin>

> 4. COMANDOS ÚTILES EN EL DÍA A DÍA

Borrar carpeta de construcción
$ mvn clean

Ejecutar tests
$ mvn test

Construir proyecto
$ mvn package

Instalar proyecto en tu repositorio local
$ mvn install

Instalar (desplegar) proyecto en el repositorio de la organización (necesita configuración)
$ mvn deploy

Ejecutar Maven saltándose los tests (unitarios e integración)
$ mvn xxxxxxx -Dmaven.test.skip=true

Mostrar el stacktrace de excepción
$ mvn xxxxxxx -e

Mostrar información de debug
$ mvn xxxxxxx -X

Instalar una libreria de terceros en tu repositorio local
mvn install:install-file -Dfile=ruta/a/fichero/jar -DgroupId=com.example -DartifactId=nombre_libreria -Dversion=x.y.z -Dpackaging=jar

Instalar (desplegar) una libreria de terceros en el repositorio de la organización (necesita configuración)
$ mvn deploy:deploy-file -Dfile=ruta/a/fichero/jar -DrepositoryId=id_repositorio -Durl=url_repositorio -DgroupId=com.example -DartifactId=nombre_libreria -Dversion=x.y.z -Dpackaging=jar

Ver pom efectivo (suma de poms padres)
$ mvn help:effective-pom

Ejecutar Maven en modo offline
$ mvn xxxxxxx -o

Preparar Maven para poder ejecutarse en modo offline
$ mvn dependency:go-offline

Ejecutar Maven con máximo de memoria heap configurable (ejemplo con 512m)
$ mvn xxxxxxx -DXmx512m
o editar la variable de sistema MAVEN_OPTS=-Xmx512m

> 5. DEPENDENCIAS

Ver jerarquía de dependencias
$ mvn dependency:tree

Ver dependencias en orden alfabético
$ mvn dependency:resolve

Analizar uso de dependencias
$ mvn dependency:analyze

> 6. RECURSOS

Ciclos de vida
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

Estructura estándar de carpetas
http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html

Propiedades
http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide

Pom
http://maven.apache.org/ref/2.2.1/maven-model/maven.html

Plugins más comunes
http://maven.apache.org/plugins/index.html

Documentación oficial
http://maven.apache.org/guides/index.html

Libro gratuito: Maven La Guía Definitiva
http://www.sonatype.com/books/maven-book/reference/

Gestor de repositorios Nexus
http://nexus.sonatype.org/index.html

Esquema de un Sistema de Gestión de Desarrollo Software

UPDATE 090731: Se mejora la imagen del esquema y se subraya la importancia de la automatización de la alimentación del Sistema.

Me encuentro sumido en un proyecto de consultoría para definir un Sistema de Gestión de Desarrollo de Proyectos o Ecosistema Software. Así que aprovecho para compartir una primera versión del esquema lógico sobre el que estoy trabajando.

Wiki

Es el punto de entrada principal al Sistema.
Contiene la información básica de cada proyecto y la organización.
Redirige al resto de aplicaciones del Sistema.
Permite la creación de documentación de forma colaborativa.
Control de cambios automático.
Documentación exportable a formato pdf.

Cms

Sistema de Gestión Documental para los documentos binarios, como word, powerpoint, etc.
No toda la documentación puede estar en el Wiki.

Project Management

Visión de alto nivel de la gestión de proyectos.
Cuadro de mandos ágil para directivos.
Gestiona resto de estados de un proyecto que no son Desarrollo.

Issue Management

Gestión del desarrollo de cada proyecto con sus versiones, tareas, equipo, trazabilidad, etc.

Scm

Sistema de Gestión de Control de Fuentes (CVS, Subversion, Git,... etc.)

Continuous Integration Server

Descarga, construye, prueba, analiza el código, crea informes de estado y despliega en el Demos Server los proyectos de forma automática y periódica.

Demos Server

Servidor de demos del estado actual de cada proyecto.

Otros

Notificaciones vía RSS y e-mail.
Single Sign On.
Privacidad.
Integración con el IDE del equipo de desarrollo para automatizar la alimentación del Sistema y garantizar la trazabilidad.


Ahora toca analizar alternativas y seleccionar la que más se ajuste a las necesidades del cliente.
Los mayores problemas están en (1) el análisis del Wiki y el Cms por la cantidad de alternativas disponibles y (2) en la herramienta de Project Management porque cada organización tiene un punto de vista muy personal sobre la gestión de proyectos, lo que interesa y lo que no. Así que no descarto que haya que desarrollar una aplicación a medida como suelen tener todas las organizaciones.

Cuanto vale un experto en programacion (ii)

Empezamos nuestra vida profesional programando. A muchos nos encanta. Va más allá de una obligación o un mal menor y temporal en un camino mezquino. Es una pasión. Disfrutamos construyendo buen software y cúanto mejor lo hacemos, más nos gusta. Por eso nos cuesta abandonar la rama técnica de nuestro sector. Aunque es una rama corta, torcida y con un techo salarial injusto.

Hace unos dias os contaba que Kent Beck ofrecía sus servicios durante 2 horas de forma remota a través de ebay. Me pareció una buena prueba para saber dónde está este techo ahora. Para saber cúanto vale un experto en programación y animarme a no cambiar de rama.

Finalmente la puja se cerró en 405 dolares americanos. No llega a 300 euros al cambio actual. Más o menos lo que cualquier consultora cobra por una jornada de un perfil técnico medio aquí en España. No sé a vosotros, pero a mi me parece poco. Me cuesta creer que haya faltado repercusión o que la cuestión del remoto haya sido un impedimento. Sinceramente me esperaba más dinero. Sobretodo teniendo en cuenta que por casi cualquier curso o seminario con un profesor anónimo ya se está facturando eso o incluso más. Y no es lo mismo un formador que un experto.

La conclusión es tan clara como desmotivadora. Un experto en programación vale poco en comparación con otros expertos.

Por qué

Por un lado es un problema de actitud. Nos quejamos mucho en nuestros circulos internos pero reivindicamos poco o nada en comparación con otros colectivos de trabajadores.

Pero principalmente pienso que es un problema de no saber reconocer la calidad ni importancia del trabajo de un programador. Me explico. Reconocer la calidad del trabajo de un diseñador gráfico es sencillo (gustos aparte). Reconocer la calidad del trabajo de un experto en usabilidad es sencillo. Reconocer la calidad del trabajo de un tester es factible con métricas sobre el número de bugs detectados. Reconocer la calidad del trabajo de un formador también es sencillo. Calcular la comisión del trabajo de un comercial se hace todos los dias.

Sin embargo, reconocer la calidad del trabajo de un programador no es fácil para alguien que no sea también programador. Características como la eficacia, estabilidad y escalabilidad del código de una aplicación no son fácilmente medibles a primera vista. Ni siquiera para un programador. Ya sea sobre el código o sobre la aplicación funcionando. ¿Es culpa del análisis, del código propio de la aplicación, de alguna librería externa, del servidor, del proxy, de la base de datos,...?

Mucho más dificil es responsabilizar de cualquier mérito o demérito a un programador concreto dentro de todo un equipo de desarrollo. ¿Trazabiliqué? Todos somos de excusa rápida para nuestros fallos y muy poco comprensivos para los de los demás.

La complejidad se multiplica para el caso de aplicaciones enterprise donde existen numerosas fuentes de datos, cuya integridad y fiabilidad no dependen directamente del programador pero si pueden afectar a la aparente calidad de su trabajo. ¿A quién no le han abierto una incidencia que realmente era por un bug en un servicio externo, por inconsistencia de datos o simplemente porque estaba caido algún sistema externo?

Al final el cliente termina por aceptar y convivir con que sus aplicaciones fallan y necesitan de grandes contratos en mantenimiento correctivo y funcional. Los comerciales hacen su trabajo. La empresa gana dinero. Y nosotros terminamos parcheando dinosaurios. Todo puede seguir como estaba.

Aún así, nosotros, los que programamos, sabemos que un buen programador no es que valga x2 o x3. Vale mucho más. Mientras que un mal programador ya no es que sume poco, es que llega a restar. Lo sabemos porque lo vivimos a diario, pero comunicar esta lección a otros niveles no es fácil.

Un futuro mejor pasa irremediablemente por medir la calidad de un proyecto, y por tanto medir la calidad de sus programadores. Con números delante, todo el mundo es capaz de medir y comparar. Para ello se puede (1) medir la calidad del código mediante métricas de análisis estático, (2) medir la cobertura de tests unitarios del código y (3) definir tests de aceptación funcionales y de esfuerzo sobre la aplicación. Con lo primero medimos mantenibilidad, con lo segundo fiabilidad y con lo tercero eficacia, estabilidad y escalabilidad.

Cuanto vale un experto en programacion

Estamos acostumbrados a enfrentarnos a nuevos problemas por nosotros solos a diario. No nos queda otra. El aprendizaje a base de ostias investigación, prueba y error es una realidad por la que todos pasamos y que viene a cubrir las carencias de los sistemas de formación profesionales.

Pero muchas veces podemos dedicar días y días, incluso semanas, para dar con la solución. Se soluciona sí. Se aprende también. Pero no es eficiente. Por un lado, tiene un coste psicológico en la persona o equipo en forma de stress, desmotivación y quemado. Por otro, tiene también un coste económico en las cuentas del proyecto. Y hasta puede tener un coste en imagen si el cliente se entera o simplemente por entregar con retraso.

Contar con un experto podría resolver el problema de forma eficiente a la vez que mejoraría la formación del equipo. Por problema no sólo me refiero a un marrón, puede ser un conjunto de tareas importantes sobre las que el equipo no tiene aptitudes ni experiencia.

Conozco algunas compañías donde se cuenta con esa figura de experto al más puro estilo Señor Lobo de Pulp Fiction. Aunque son muy pocas y a veces el experto no es tan experto. Pero siempre está la opción de subcontratar a un verdadero experto para resolver el problema. En España no se lleva. Una pena.

Y todo este rollo al hilo de un sorprendente anuncio de Kent Beck en ebay, donde ofrece una sesión remota de programación en pareja de 2 horas. La sesión se hará mediante VNC para compartir la pantalla y Skype para comunicarse. Aunque puede ser para revisar código, las dos horas se pueden emplear en temas de diseño, testing o lo que se quiera. Va por 305 dolares pero aún faltan días para que se cierre la puja. Veremos como termina la cosa.

Sobre pruebas y errores

Veo en las noticias las imagenes de una prueba de carga en un nuevo puente de una autovía en Galicia (España). Durante un momento me quedo absorto mirando la larga flota de camiones sobre el majestuoso puente. Impresiona. No puedo evitar pensar: Vaya! eso sí que es una prueba manual. Y luego yo quejándome sobre las pruebas manuales que hacemos en el desarrollo de proyectos software...

Bastan un par de segundos para darme cuenta de la tontería de mi reflexión. Si eso fuera una primera ejecución de una prueba exigente sobre un proyecto software recien construido, el puente se habría caido arrastrando a la flota de camiones tras él.

En el caso del puente, lo que no estamos viendo es todo el proceso de pruebas y control de calidad, que se ha realizado previamente en cada una de las fases del proyecto para evitar errores.

Pero comparar nuestro mundo de desarrollo software -¿ingeniería software?- con el de la construcción o cualquier otra ingeniería es una equivocación. Una equivocación torpe, injusta y desafortunada, porque, entre otras cosas, hace imaginarse a un programador como a un obrero. Así nos va.

Aunque centrémonos en los errores. Errar es humano. Obvio. A veces estamos distraidos, cansados, estresados, desmotivados o simplemente no somos perfectos y se nos escapan cosas.

Otro hecho es que los proyectos software salen a producción con demasiados errores. También obvio si estudiamos el ineficaz proceso de pruebas que se sigue en la mayoría de proyectos, basado en unas pruebas mínimas, manuales y sin documentar. Por lo que las pruebas dificilmente se repiten en el tiempo, aunque se modifique código afectado, haciendo aparecer nuevos errores o, peor aun, haciendo reaparecer viejos errores. ¿Vosotros compraríais algo cuyo proceso de pruebas fuera así?

Lo primero no tiene solución. Pero sí se puede minimizar el efecto. Contratando talento y con motivación.
Lo segundo sí tiene solución. Aplicar un proceso profesional de pruebas, basado en pruebas automatizadas, completas, independiente y repetibles. Los errores seguirán produciéndose, pero la mayoría serán detectados antes de llegar a producción.

Por supuesto, siempre hará falta alguna prueba manual pero, al igual que en el puente, será más un mero trámite de aceptación que el actual infierno de prueba y error sin fin.