¡Habemus Blog!

El nuevo blog gitevangelism se dedica a la promocion de GIT. Un sistema de versionamiento que tiene asombrosos features pero que lamentablemente no esta lo bastante
difundido, por lo menos en los ambientes que frecuento: en los trabajos y en la facultad.

Sin duda, el sistema de control de versiones mas usado y difundido es el SVN, son muy pocas personas las que conocen a fondo las prestaciones de ambos como para poder elegir y por eso podria parecer que lo unico que agrega GIT son "commits locales" y "complejidad innecesaria". gitevangelism se encargara (entre otras cosas) de desmistificar esto y promover el conocimiento acerca de esta herramienta y como el control de versiones esta mas asociado a la forma del proceso de desarrollo de lo que en principio se cree.

El nuevo blog:
http://gitevangelism.blogspot.com

--amend

Overview de herramientas UML online

Resulta que me anote en una materia interesante y estoy necesitando encontrar una herramienta de UML a mano, facil y si es posible colaborativa... esto es online, o "en la nube"

Ya que estoy probando varias opciones, aprovecho para escribir un overview de todas las herramientas que probe. Para cada herramienta se incluye un diagrama generado con esta y la evaluacion de las siguientes caracteristicas:

* Almacenamiento: Si tiene storage para almacenar los diagramas online
* Vistas: Si tiene vistas publicas dinamicas para que se pueda mostrar en una pagina o en un blog la ultima version del diagrama
* Diagramas: Que tipos de diagramas se pueden hacer (diagramas de actividad, casos de uso, clases, objetos, secuencia, despliegue, colaboracion, transicion, componentes)
* Exports: Si se puede exportar como imagen o como algun otro formato editable
* Imports: Si se puede importar imagenes o incluso otros objetos
* Coop: Si es colaborativo, o sea, si varios usuarios pueden editar el diagrama simultaneamente diseñando de manera cooperativa.
* Estabilidad: Si es posible editar sin que se cuelgue o tenga algun otro fallo que afecte el trabajo
* Portabilidad: Si funciona en varios navegadores (por ahora testeados en Mozilla Firefox 3.6.8 con Ubuntu Linux)
* Registracion: Si es necesaria, y que implica
* Costo: Si tiene paquetes de uso gratis, si tiene paquetes de servicio pago, que limitaciones y precios hay de cada uno de ellos
* Engine: Como funciona, si usa java, flash, etc...

Cacoo
http://cacoo.com/

Segun mi opinion, uno de los mejores, si se pudiera guardar el diagrama en la computadora local seria perfecto

* Almacenamiento: SI
* Vistas: SI (ej: https://cacoo.com/diagrams/hB18F3rQnjWqxQ74/view )
* Diagramas: casos de uso, clases, secuencia, estados, componentes, deployment, ER y tiene mas bibliotecas de objetos
* Exports: Solo imagenes en formato PNG (la version gratuita)
* Imports: Cualquier tipo de imagen
* Coop: SI
* Estabilidad: Si tenes una conexion mala no lo uses
* Portabilidad: Funciona bien en firefox 3.6.8 y en Ubuntu Linux
* Registracion: SI o SI es necesaria (tambien con la version gratuita)
* Costo: Gratis (limitacion de 3 colaboradores por diagrama)
Engine: flash

Creatly
http://creatly.com

Este diagramador puede guardar archivos en la computadora local (ademas de poder guardarlos online)

* Almacenamiento: SI
* Vistas: SI
* Diagramas: Actividad, Clase, Colaboracion, Componentes, Deployment, ER, Objetos, Secuencia, Estados, Casos de uso, networking, electronica, de flujo
* Exports: PNG, JPG, PDF, Creatly File
* Imports: Image, Creatly File
* Coop: SI
* Estabilidad: Me colgo el firefox una vez, pero la mayoria de las veces lo pude usar
* Registracion: Se puede usar sin registracion (aunque se recomienda registrarse y es gratuito)
* Costo: Actualmente Gratis para 2 collaborators, U$S4.95 para 5 collaborators y un 1 Gb, U$S9.95 para ilimitado espacio y collaborators. No se puede tener varios proyectos ni exportar archivos en formato "editable" en la version gratuita. Ver http://creately.com/plans7

yUML
http://yuml.me/

Este es rarisimo, hay que poner un codigo (como una especie de lenguaje) y genera el diagrama. No tiene editor y es el que menos funcionalidades tiene, lo unico bueno que tiene es que funciona bien sin impotar cual sea el browser

* Almacenamiento: NO
* Vistas: NO (Algo parecido)
* Diagramas: clases, actividad, casos de uso
* Exports: Imagen PNG
* Imports: NO
* Coop: NO
* Estabilidad: 100% Siempre funciona, porque es muy sencillo
* Portabilidad: 100%, ya que no importa que browser uses, el diagrama se genera del lado del servidor a partir del "codigo" que se le ingrese
* Registracion: no hay
* Costo: Gratis

gliffy
http://www.gliffy.com/

Este es interesante, tiene el estilo del cacoo y al creatly, pero viene con templates base para crear diagramas (con lo que ayuda bastante al usuario primerizo), lastima que no me anda el drag&drop (¿sera mi version de flash?), cualquier cosa pruebenlo (no se necesita registracion para probar). En lo personal para lo que necesito no tiene elementos de suficientes diagramas.

* Almacenamiento: SI
* Vistas: SI (Ej: http://www.gliffy.com/pubdoc/2214754/S.png)
* Diagramas: Diagramas de flujo, networks, ER, UI, Diagramas de clases, secuencia, casos de uso
* Imports: SI, Formatos GIF, JPEG y PNG
* Exports: SVG(Visio), Gliffy Xml, Formatos graficos JPEG y PNG
Coop: SI
* Estabilidad: Por lo visto es estable, pero no lo pude probar bien
* Portabilidad: Me fallo en firefox 3.6.8 con Ubuntu Linux, talvez funcione en otras plataformas
* Registracion: Se puede usar sin registracion (aunque se recomienda registrarse y es gratuito)
* Costo: es Gratis, pero es un trial de 30 dias

gModeler
http://www.gskinner.com/gmodeler/

Mismo problema de drag&drop como con gliffy, mas tarde probare este y otros con otro entorno.

* Almacenamiento: NO (Aunque permite guardar como XML localmente)
* Coop: NO
* Portabilidad: MALA, no funciono en firefox 3.6.8 con Ubuntu Linux
* Registracion: no hay
* Costo: es totalmente Gratis

Mas tarde voy a probar gModeler desde otro entorno

Enlaces:

Cacoo: http://cacoo.com
Creatly: http://creatly.com
yUML: http://yuml.me/
gliffy: http://www.gliffy.com/
gmodeler: http://www.gskinner.com/gmodeler/

Diagramas UML online

Visiten esta web:

http://yuml.me/

Permite crear diagramas UMLs online usando un lenguaje bastante interesante, no tuve mucho tiempo para probarlo mas que para hacer este diagrama que les estoy mostrando

La magia del TDD: un ejemplo real en ruby

Este fin de semana comence un proyecto, una nueva gema que "desparsea" los arboles generados por la gema ParseTree. Explicar los detalles de ese proyecto no es el tema de este articulo, sino mas bien contar la experiencia con TDD.

Para los que no saben que es TDD la wikipedia explica. Sin son vagos como para clickear el link, TDD es una metodologia que basicamente tiene dos pilares: "write tests first" (escribir los test primero) y "refactoring".

Resulta que lo que estoy desarrollando consiste en una funcion que revierte o encuentra la preimagen de otra funcion (es decir, genera un string con codigo ruby que resulte en un determinado arbol cuando se parsee con ParseTree).

Este requerimiento tiene un grado muy alto de testeabilidad ya que se puede calcular el input correspondiente a partir del output esperado (seria como el testeo oracle, pero al revez porq estamos buscando hallar la inversa de una funcion que ya tenemos, que es ParseTree)

Manos a la obra:

Paso 1) Escribir los tests primero:
http://github.com/tario/unparse_tree/tree/0ca29f14

En este caso se fue desarrollando de manera de ahorrar lineas y probar *todos* los casos (mas adelante se sabe que se omitieron algunas cosas, pero creo q eso es comun en TDD sobre todo cuando el analisis de cobertura no es viable)

Paso 2) Implementar hasta que todos los tests pasen:
http://github.com/tario/unparse_tree/tree/48c9a997

Cambios hasta que funcione, algunos "harcodean" o ponen "magic values", otros agregan funcionalidad a conciencia, lo importante es que cada commit disminuye el numero de errors + failures reportados y no se modifican los tests

Paso 3) Refactoring:

En esta etapa se modificara el codigo hasta que se vea minimamente "bien", es decir, se eliminara codigo duplicado, se implementaran las cosas "de verdad" en lugar de usar "magic values", "harcodeos" o "if extraños" y cualquier cambio que mejore el diseño/la distribucion del codigo, de mas esta decir que por cada cambio todos los tests siempre tienen que pasar. Todavia no alcance esta etapa en el proyecto... ya llegara.

Paso 4) Vuelta al paso 1:

Con nuevos requerimientos y/o bugs encontrados, se genera una nueva bateria de tests y el ciclo vuelve a comenzar.

De todo esto, en la practica me encuentro con las siguientes ventajas de usar TDD:

* La validacion de si el codigo funciona es automatica, con solo ejecutar un comando puedo saber si "rompi" el codigo o si estoy progresando
* TDD guia a escribir el codigo de manera "correcta" o por lo menos mas prolija
* Se puede testear un numero mas grande de casos, con lo que se cubren mayor cantidad de posibilidades

Y, como todo, tiene sus desventajas (aunque se mitigan y son evidentamente superadas por las ventajas)

* Hay que programar las pruebas que si no se usara TDD, no se tendrian que programar (de todas maneras, con o sin TDD siempre hay que testear el software, y sin TDD se hace de forma manual)
* Las pruebas no garantizan cobertura total, es decir, pueden ser %100 exitosas las pruebas y el software fallar en la practica al haber omitido algo (esta claro que la idea en principio no es confiar ciegamente en las pruebas, mas bien TDD tiene que basarse en la construccion de pruebas)
* Durante la fase de desarrollo, me doy cuenta de errores que se ven en el codigo o al escribir el codigo, pero no puedo corregirlos si no existen tests que pasen como resultado de esa correccion (para resolver esto se puede optar principalmente por dos alternativas, una seria registrar como un "ticket" la necesidad de agregar el test para el proximo ciclo, la otra seria agregar el test en ese mismo momento, aunque eso se alejaria del espiritu del TDD y superpondria los pasos 1 y 2)

Cabe destacar que las ventajas del TDD asi como otras metodologias son apreciables a mediano y largo plazo (TDD mas que otras), ya que a medida que avancen los ciclos de TDD, los tests desarrollados en ciclos anteriores cumpliran el rol de automatizar las regresiones, es decir, que si se modifica el codigo en un proyecto que tiene 8 meses de vida, las pruebas automaticas rebelaran si se rompio funcionalidad implementada al principio del proyecto, tres meses atras, dos meses atras, que implemento otra persona, etc...
Despues de varias iteraciones, volvere a postear para hacer un analisis de las ventajas de TDD a largo plazo

Enlaces

http://en.wikipedia.org/wiki/Test-driven_development
http://github.com/tario/unparse_tree/tree/0ca29f14 (tests creados en el primer ciclo de unparse_tree)
http://github.com/tario/unparse_tree

Soy malo para los nombres de blogs

He creado un nuevo blog, llamado Soy malo para los nombres de blogs, sera el sumidero de las sobras de todos los blogs, no entren ahi

Enlaces:

http://soymaloparalosnombresdeblogs.blogspot.com/

Sandbox de codigo ruby (remake 2010)

Anteriormente en este mismo blog anuncie la creacion de un sandbox para ruby. Ese proyecto se cancelo y quedo definitivamente incompleto. El proyecto se llamaba arena-ruby-sandbox.

Hace un tiempo comenze el desarrollo de un nuevo sandbox (llamado shikashi), pero con un diseño y una idea totalmente distinta: mientras arena-ruby-sandbox es un intento de sandbox en codigo ruby puro, shikashi se implementa utilizando una modificacion al interprete de ruby hecha en C en formato de extension (llamada rallhook).

Funciona mejor que su antecesor ademas de permitir usar casi todos los elementos del lenguaje como clases y metodos singleton cosa que arena-ruby-sandbox no permitia.

Recientemente libere la version 0.7.1 de rallhook ademas de la version 0.1.0 del sandbox shikashi. La documentacion del gem (que incluye instrucciones de como instalarlo, ejemplos de uso y descripcion completa del API) esta en http://tario.github.com/shikashi/doc/

NOTA: tambien se puede instalar haciendo

gem install shikashi

Cosa que no menciona el README y lo actualizare en proximos releases.

Post-mortem debugging en linux

Que es el debugging post-mortem

El debugging post-mortem es una clasica tecnica de debugging que consiste en que el sistema operativo genera un volcado completo de los registros, los threads y la memoria de un proceso que termina de manera anomala (ya sea por SIGSEGV o por SIGABRT), en linux estos volcados se llaman "cores" y se pueden examinar con gdb para ver en que punto del codigo ocurrio el error, los threads con sus backtraces, los registros, e incluso el valor de las variables (si se tiene informacion de debug) en el momento en que termino el proceso.

Como activarlo

Por default, en la mayoria de los sistemas linux viene desactivado, pero activarlo es tan simple como ejecutar en la terminal:

ulimit -c 4000000000

Que determina que el limite maximo para el tamaño del core sera de aproximadamente 4Gb (valores mucho mayores pueden ser rechazados a no ser que se tenga privilegios de root).

Esto solo tiene validez en la shell en la que se activo, si se necesita que este siempre activo para cualquier sesion, se podria agregar la linea "ulimit -c 4000000000" al final del archivo ~/.bashrc

echo ulimit -c 4000000000 >> ~/.bashrc

Como verlo funcionando

Se crea un programa de purebas, "mytest.c" que genera un error abort()

#include "stdlib.h"

int main()  {
abort();
}

Se compila generando informacion de debug y se ejecuta:

gcc -ggdb mytest.c -o mytest
./mytest

El programa falla y seguramente anunciara que se genero el core (en mi caso solamente el archivo generado se llama "core", en algunos sistemas pone el pid o cosas asi)

Se puede usar gdb para analizar el core, tambien hay que pasarle como parametro el ejecutable que genero el core para poder ver la informacion de debug:

gdb -c core mytest

A partir de entonces se puede examinar el estado que tenia el programa en el momento de finalizar como si se tratara de un debug normal:

(gdb) bt
#0  0x00007f55e7ef3a75 in raise () from /lib/libc.so.6
#1  0x00007f55e7ef75c0 in abort () from /lib/libc.so.6
#2  0x000000000040052d in main () at mytest.c:4
(gdb) info threads
* 1 Thread 4352  0x00007f55e7ef3a75 in raise () from /lib/libc.so.6
(gdb) disass main
Dump of assembler code for function main:
   0x0000000000400524 <+0>: push   %rbp
   0x0000000000400525 <+1>: mov    %rsp,%rbp
   0x0000000000400528 <+4>: callq  0x400418 
End of assembler dump.
(gdb) print/x $rcx
$4 = 0xffffffffffffffff
(gdb)