Categoría: Software

Esa cosa NoSQL

Probably the worst thing about relational databases is that they are so good in what they are doing. Good enough to conquer the entire market on data storage and hold it for decades.

Wait! That is a bad thing? How?

It is a bad thing because relational databases are appropriate for a wide range of tasks, but not for every task […]

Hace tiempo ya que sigo el blog de Ayende Rahien, uno de los principales desarrolladores de NHibernate (aunque él lo niega y dice que es el que más habla de NHibernate, no el que más desarrolla). Además es también el autor de RavenDB, una base de datos NoSQL para .NET.

Hace un tiempo en el trabajo, donde utilizamos Java, por distintos motivos se estuvo evaluando cambiar la base de datos actual (Apache Derby) por una NoSQL (la candidata era OrientDB). Al final no se realizó el cambio, pero me sirvió para enterarme un poco mejor de lo que se trata toda esta movida, y no solamente tener ideas sueltas sobre el tema.

Me gustaría compartir en este post una serie de artículos de Ayende sobre estas bases de datos. No son posts introductorios, sino que va a las preguntas más importantes como: ¿cuándo usamos una base NoSQL? De todos los tipos que hay, ¿cuál sirve para cada de problema? etc.

Continuá leyendo Esa cosa NoSQL

¿Cuál es mi estrategia para ser un mejor desarrollador?

Hace unos días, por twitter, me entero de un post de hace unos dos años de Angel “Java” López. ¿Qué hago para ser mejor en lo que me gusta?

Algunos puntos que se mencionan, para reforzar o para comenzar a implementar si todavía no lo hago:

  • Hay mejores desarrolladores que yo. Tengo que ver cómo trabajan y así obtener algunos tips para superarme a mí mismo.
  • Leer. Tanto blogs como código fuente de otros. Hay muchísimo conocimiento ahí afuera.
  • Lo que aprendo y se, lo comparto. Esto ayuda muchísimo a reforzar el conocimiento. Si les muestro a los demás lo que pienso y hago puedo obtener valioso feedback para saber si realmente estoy haciéndolo bien. Además esto me puede ayudar a identificar problemas específicos y contar con la experiencia de otros para resolverlos.
  • Hablar. Entrar en contacto con mi grupo local o en la facultad y dar una charla de lo que se. Además esto hace que los demás me conozcan. Pero sobre todo, como dice López, cuando enseño, aprendo. Interesante para los que se sientan llamados a la docencia.
  • Practicar. Jugar e implementar algo para probar una idea. Luego publicarlo y mostrarlo a los demás. Por ejemplo escribir un intérprete: en esto Ángel López es experto, de vez en cuando escribe uno y lo publica en su blog.
  • Aprender cosas nuevas. Ir más allá de lo que se. Un lenguaje, una plataforma, una técnica de programación, una metodología…

Y si bien ya está implícito, yo agregaría uno más: siempre mantener un cierto aire de inconformismo con lo que hacemos. El software siempre se puede mejorar, siempre podemos ser un poco mejores en lo que hacemos.

¿Ustedes qué estrategia tienen?

TDD con Python

Excelente serie de videos donde se muestra cómo hacer TDD con Python. Como dice Angel “Java” López en un post, cuando uno comienza a hacer TDD, luego no puede dejarlo. Además las herramientas utilizadas me encantaron, sobre todo pyTDDmon, que en una ventanita en colores rojo y verde nos indica el estado actual de los tests de unidad.

Este es el primero de la serie:

Los demás videos los pueden encontrar en estos links.

Es muy buena la explicación de “Java” Lopez:

Implementa algo sencillo: código que dado un string con una URL, identificar el protocolo, el dominio, y el recurso que está contenida en esa dirección. En TDD, se va escribiendo el test, el código que pasa el test, y se va progresando de a poco. No hace falta escribir el código correcto y completo desde el principio. Como en otras tantas actividades, el “baby-step”, el “pequeños pasos” de avance, nos ayuda para ir incrementalmente produciendo el resultado esperado.

Noten el ciclo rojo-verde-refactor, el código mínimo que se agrega en cada tests (a veces, retornando valores puestos a mano, sólo para pasar los tests), refactorizando el test si hay código duplicado, las micro-decisiones de diseño que se van tomando, etc… Excelente trabajo para mostrar en video!

Además otra cosa interesante, no directamente relacionado con TDD pero si con las pruebas de unidad, es la cantidad de veces que el autor prueba distintas implementaciones sin preocuparse, ya que tiene toda una suite de tests para saber si la misma es válida. Eso es algo hermoso 🙂

En Making Good Software, leí una vez un post muy interesante titulado “TDD is not about testing!!!” que me llamó mucho la atención al principio. Mucha gente piensa que escribir los tests primero es hacer TDD, lo cual es incorrecto. TDD es una práctica de diseño, y es todo un proceso:

Test-driven development

Si usás Buildbot con Mercurial…

… y la versión de Buildbot es la 0.7.11p3 (la última al momento de escribir este post) y Mercurial 1.3.1, que son las versiones que están en Karmic, quizá tengas un problema cuando el Build Slave intenta bajar el código del repositorio para comenzar el ciclo de compilación/testing.

Arquitectura de Buildbot
Arquitectura de Buildbot

Buildbot permite configurar de varias formas el modo en que va a obtener el código fuente del proyecto y cómo realizará las actualizaciones subsiguientes. Por ejemplo, el modo “update” hace que las operaciones de checkout/update se ejecuten en el directorio de trabajo, y no en uno independiente, como en el modo “copy” o “clobber”, que mantienen un directorio separado y limpio del repositorio (en el caso de Mercurial, “copia de trabajo” en el caso de Subversion) y hacen una copia del mismo para realizar la compilación (esto asegura que siempre se compile todo y que no influyan archivos generados en procesos anteriores, además de otros problemas menos comunes pero que existen).

El problema que estuve teniendo es cuando utilizo Mercurial. Al intentar traer el código fuente, Buildbot entra en un bucle infinito donde realiza el checkout (clone), borra el directorio, otra vez clone y asi… me pareció rarísimo el comportamiento. Versiones anteriores de Buildbot con versiones anteriores de Mercurial funcionan bien.

En uno de los pasos para realizar el checkout/update, Buildbot verifica si ha cambiado la URL del repositorio. Si esto es así, entonces hace clobbering, o sea, vuelve a bajar todos los cambios (checkout) y obviamente no realiza un update, aunque el modo no sea “clobbering”. Para saber si dicha URL ha cambiado, ejecuta un “hg paths default” en el directorio de trabajo y lo compara con la URL asignada en el archivo de configuración central del Build Master.

El bug está en que al ejecutar “hg paths default” Mercurial 1.3.1 devuelve el password oculto con asteriscos:

$ hg paths default 
http://miltondp:***@url.mi_proyecto.com/path/al/repo

… y, obviamente, la URL asignada en el archivo de configuración está completa (sin el password oculto). Al compararse ambas, son distintas, y por lo tanto siempre se hace clobbering.

Continuá leyendo Si usás Buildbot con Mercurial…

Gtk+: trabajando con TreeViews

edicion-treeview1

Este post puede ser útil para los que utilicen el widget TreeView de Gtk+ (no importa el lenguaje mientras haya bindings), y necesiten activar por código celdas en modo edición. Hay algunas cuestiones a tener en cuenta.

Para el Proyecto Final de Carrera estamos desarrollando un sistema de nivel operativo, con funciones de facturación y demás. Necesitamos manejar un TreeView con campos editables, y al finalizar la edición de uno de ellos es necesario dar el foco a otro campo en modo edición, listo para que el usuario comience a cargar datos sin tocar el mouse.

Continuá leyendo Gtk+: trabajando con TreeViews

sl: Steam Locomotive

¿Nunca escribieron LS o sl cuando en realidad quisieron ejecutar “ls” en la terminal? Bueno, si les pasó, habrán visto que en Ubuntu salta el siguiente mensaje:

$ sl
El programa «sl» no está instalado actualmente.  Puede instalarlo escribiendo:
sudo apt-get install sl
bash: sl: orden no encontrada

La primera vez que lo vi me pareció extraño, así que instalé el paquete “sl” como me sugería. La descripción del paquete es esta:

Correct you if you type `sl' by mistake
Sl is a program that can display animations aimed to correct you
if you type 'sl' by mistake.
SL stands for Steam Locomotive.

Me imagino que tendrán ahora la intriga de qué es lo que pasa si ejecutan “sl”. Simplemente tengan cuidado 😛

Mono C# Shell

El otro día necesitaba saber bien cómo funcionaba el método Remove de la clase StringBuilder en Mono. Entonces hice lo siguiente:

miltondp@wasabi:~$ csharp 
Mono C# Shell, type "help;" for help

Enter statements below.
csharp> using System.Text;
csharp> var a = new StringBuilder("Milton");
csharp> a.Remove(a.Length-1,1);
Milto
csharp> a.Remove(a.Length-1,1); 
Milt
csharp> a.Remove(a.Length-1,1); 
Mil
csharp> a.Remove(a.Length-1,1); 
Mi
csharp> a.Remove(a.Length-1,1); 
M
csharp> a.Remove(a.Length-1,1); 

csharp>

Si, funcionaba como me lo imaginaba 🙂 Esta shell para C# está disponible en la versión 2.2 de Mono.