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.

El año pasado escribió una introducción a este tipo de bases de datos, que pueden acá.

En su blog también hay otros post interesantes, sobre cada tipo de base NoSQL:

• Key/Value store (operaciones y usos)
• Key/Value store – sharding
• Key/Value store – replication
• Key/Value store – eventually consistent
• Document Databases (usos y como modelar este tipo de bases)
• Graph Databases (scaling)
• Column (Family) Databases
• Why do I need that again?

Como hay varios flavours, si vamos a usar una base NoSQL, lo primero sería repasar cuándo se usa cada tipo, sus puntos fuertes y débiles, y ver si eso se ajusta nuestras necesidades o no.

Al conectar la segunda impresora, exactamente igual que la primera, la detección fue también satifactoria. Aunque surgió un pequeño gran problema: al imprimir sobre ésta última, la impresión se realizaba sobre la primera. Observando la configuración de ambas, me percaté de que tenían exactamente el mismo Device URI.

La solución fue bastante rápida: editar el archivo /etc/cups/printers.conf, y cambiar el device URI, que era algo así como “usb:/Samsung…” por “file:/dev/usblp0″, y la otra impresora por “file:/dev/usblp1″. Con esto el problema fue resuelto y todo comenzó a funcionar como uno esperaba. Aunque no tardó en surgir otro inconveniente.

Después de un tiempo de estar funcionando todo de mil maravillas, la cajera me comenta un día que, para sorpresa de ella, las facturas A se imprimían en la impresora para las facturas B, y viceversa. Me había comentado que no fue mucho problema, ya que simplemente cambió las hojas y tema resuelto. Pero desde ese mismo instante no me quedé muy tranquilo.

Después de un tiempo recibo una nueva llamada: las impresoras estaban enloquecidas. Todos los días, al encender la PC, los puertos se cambiaban. Lo que en el principio era una pequeña molestia, ahora se estaba transformando en una situación bastante irritante. No estaba seguro cómo solucionarlo, así que por lo tanto intenté una actualización del sistema, lo que en apariencias lo había solucionado. Duró uno o dos meses más hasta que el problema reapareció.

Entonces esa vez me puse a buscar un poco más, a preguntar, y me encontré con udev. Este componente del kernel Linux, encargado de gestionar dispositivos, permite, entre muchas cosas, crear reglas para: nombrarlos de una forma distinta (cambiar “sda1″ por “mi_disco”), agregar links simbólicos cuando se cumplan ciertas condiciones, ejecutar comandos ante ciertos eventos, y mil cosas más.

Lo que tuve que hacer, entonces, es buscar algún tipo de información en los atributos de cada impresora, que sea único para la misma. Para esto utilicé el comando udevadm:

$ udevadm info -a -p  $(udevadm info -q path -n /dev/usblp0)

[...]

  looking at parent device '/devices/pci0000:00/0000:00:1d.3/usb5/5-2':
    KERNELS=="5-2"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{configuration}==""
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bmAttributes}=="c0"
    ATTRS{bMaxPower}=="  0mA"
    ATTRS{urbnum}=="1368"
    ATTRS{idVendor}=="04e8"
    ATTRS{idProduct}=="3301"
    ATTRS{bcdDevice}=="0100"
    ATTRS{bDeviceClass}=="00"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{bMaxPacketSize0}=="16"
    ATTRS{speed}=="12"
    ATTRS{busnum}=="5"
    ATTRS{devnum}=="2"
    ATTRS{version}==" 1.10"
    ATTRS{maxchild}=="0"
    ATTRS{quirks}=="0x0"
    ATTRS{authorized}=="1"
    ATTRS{manufacturer}=="Samsung Electronics Co., Ltd."
    ATTRS{product}=="ML-1660 Series"
    ATTRS{serial}=="Z526BKDZ800022B."

El atributo serial es el que difiere en cada impresora, por lo tanto utilicé éste para crear un archivo /etc/udev/rules.d/impresoras.rules con las siguientes reglas:

SUBSYSTEMS=="usb", ATTRS{product}=="ML-1660 Series", ATTRS{serial}=="Z526BKAZ301606A.", SYMLINK+="impr_fa"
SUBSYSTEMS=="usb", ATTRS{product}=="ML-1660 Series", ATTRS{serial}=="Z526BKDZ800022B.", SYMLINK+="impr_fb"

Una vez guardado el archivo, hacen un “service udev reload”, desenchufan y vuelven a enchufar las impresoras, y verán que aparecen los dispositivos “impr_fa” e “impr_fb”. Ahora estos serán siempre fijos y aputarán siempre al mismo dispositivo físico (en teoría, les cuento en unos meses). Tal cual lo que estaba buscando. Si hacemos un “ls” vemos:

$ ls -l /dev/impr*
lrwxrwxrwx 1 root root 7 2011-02-22 07:34 /dev/impr_fa -> usb/lp1
lrwxrwxrwx 1 root root 7 2011-02-22 10:25 /dev/impr_fb -> usb/lp0

Pueden encontrar más información sobre cómo escribir reglas udev en este link. A mí me vino muy bien para las impresoras, pero se podrían hacer cosas interesantes con pendrives y otros dispositivos.

Cuando les mostré esto a César y a Nacho, nos preguntábamos si en Windows será posible hacer algo similar. Una de las respuestas fue: “estas cosas [impresoras enloquecidas] no pasan en Windows” y “seguramente debe tener alguna forma de configurarlo”. Solo por curiosidad: ¿alguien tiene alguna información al respecto?

Ojalá los bindings para Mono no se retrasen mucho.

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?

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:

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.

Rápidamente me fijé si Mercurial poseía alguna opción para mostrar el password en la salida de “hg paths”. No posee dicha opción por lo visto, pero me encontré con un parche que alguien envió alguna vez, el cual parece que nunca fue incluido. El mismo agrega la opción “–show-passwords” para mostrar la URL completa al ejecutar “hg paths”. Lo pueden bajar aquí. El archivo a parchear es “/usr/lib/pymodules/python2.6/mercurial/commands.py”.

También hay que parchear Buildbot para que utilice esta nueva opción al comparar los repositorios. Este otro parche lo pueden bajar desde este lugar. Tener en cuenta que el archivo a parchear tiene el mismo nombre que el de Mercurial. El path del mismo es “/usr/lib/python2.6/dist-packages/buildbot/slave/commands.py”

No se olviden de reiniciar el servicio de Buildbot, y de borrar los archivos .pyc de Python (por lo visto a veces funciona aunque no lo borremos). Ahora el ciclo funciona como uno espera:

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.

Lo primero que hicimos fue conectar un método al evento Edited del CellRendererText de la columna correspondiente. De esta forma, cuando terminamos la edición en el primer campo, podemos colocar allí el código correspondiente para actualizar el modelo del TreeView y otras operaciones más, entre ellas (la que nos interesa) dar el foco al segundo campo en modo edición. La parte final de este método (el evento se activa al finalizar la edición) había quedado así:

/* ... */

this.tvItems.SetCursor(path,
					   this.tvcCodigoProducto,
					   true);

Hay que tener cuidado al utilizar la función SetCursor. En algunos casos, si no la usamos cuidadosamente, el TreeView no se comportará en forma correcta. Esos casos son por ejemplo cuando el usuario, al estar editando el campo, hace click en otra fila. Esto hace que se dispare el evento Edited, y por lo tanto se activa el modo edición en el segundo campo (SetCursor), pero el foco lo tiene otra fila, y esto hace que el funcionamiento sea incorrecto.

La solución es, antes de ejecutar SetCursor, verificar qué tipo de evento ha ocurrido. En nuestro caso, ejecutamos dicha función sólo si se ha oprimido la tecla Return. El código queda así:

/* Una vez editada la cantidad, automáticamente
 * pasamos el foco al campo de 'código' en modo
 * edición, pero en una nueva fila. A esto lo hacemos
 * únicamente si el usuario presionó la tecla Enter */

Gdk.Event ev = Gtk.Application.CurrentEvent;

if (ev.Type == Gdk.EventType.KeyPress) {
	Gdk.EventKey evKey = (Gdk.EventKey)ev;

	if (evKey.Key == Gdk.Key.Return)
		this.tvItems.SetCursor(path,
							   this.tvcCodigoProducto,
							   true);
}

Lo cual es más lógico también: si se hace click en otra fila, seguramente es porque se quiere editar otro ítem y por lo tanto no es correcto forzar el foco en otro lugar. Además, como se dijo, esto hacía que el TreeView quede en un estado inconsistente.

$ 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

Escenario

La máquina que tendrá el servidor DHCP, TFTP y compartirá Internet es mi notebook, que se llama wasabi (a mí si me gusta el nombre ). La PC target se llamará tellus. Desde mi notebook me conecto a un router via wifi (el cual me brinda Internet), y a tellus por cable. La interfaz de la primer conexión es wlan0, y la de la segunda eth0.

Procedimiento

wasabi

• En wasabi solamente es necesario tener dnsmasq instalado (hará de servidor DHCP y además tiene un server TFTP incluido).
• La IP de wasabi será 192.168.0.1
• Editamos las opciones en /etc/dnsmasq.conf. Agregamos las siguientes lineas (asegúrense de que el archivo no tenga otras opciones conflictivas activadas):

listen-address=192.168.0.1
interface=eth0

dhcp-no-override
dhcp-range=192.168.0.30,192.168.0.60,12h

dhcp-boot=pxelinux.0
enable-tftp
tftp-root=/var/ftpd

• Coloquen el CD de Ubuntu Server (o la versión que sea) en su lectora, y copien los archivos necesarios para realizar la instalación por red:

$ sudo cp -ar /media/cdrom0/install/netboot/* /var/ftpd

• Otra opción al paso anterior es bajarse los archivos desde Internet, para Intrepid o para Jaunty por ejemplo.
• # sudo service dnsmasq restart
• En este punto ya tenemos andando dnsmasq, como servidor DHCP, DNS y TFTP.
• Activamos IP Masquerading:

# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE

• Como les dije, tellus no puede bootear directamente por red, así que es necesario crear un disquette con gPXE. Tienen que elegir el modelo de placa de red exacto de la máquina target (tellus en este caso) para poder bootear, traer la imagen desde wasabi y arrancar la instalación. Una vez bajada, pueden grabarla en un disquette (que difícil conseguir un disquette estos días… y uno que ande) con dd en GNU/Linux o rawwritewin en Windows.

tellus

• Colocan el disquette creado y bootean desde él. Deberían ver cómo la máquina target pide una IP y arranca el instalador de Ubuntu.

Listo, eso es todo. Un inconveniente que tuve fue resuelto con la opción “dhcp-no-override” que les mostré arriba, para dnsmasq. Resulta que en modo normal no arma paquetes DHCP del todo estándar, y que hacían tellus no pueda encontrar la opción de “archivo de booteo” al recibir el paquete DHCP.

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.