Muchas veces tenemos que sentarnos a pensar prototipos para clientes y una de las mejores herramientas que hay para comunicar lo que pensamos es unos bocetos pintados de cualquier manera en un papel.

Estos días asís y david empezaron a jugar con balsamiq.com y poco a poco todos hemos ido probándolo para nuestros pantallazos. Tiene sus limitaciones, pero es una gozada.

Para muestra un cutre mockup de 4trabes hecho en poco más de lo que llevó calentar un café. Vale, lo reconozco, cuando fui a por él ya estaba algo frío ;)

Para los incrédulos…

visto en graphjam.com

pocas cosas tan ciertas...

cuando nuestra ubuntu arranca con una tarjeta de red pinchada, guarda en "algún sitio" un registro que le permite asociar un nombre a cada uno de los dispositivos. La correspondencia se hace directamente entre MAC y nombre. A la primera mac que "ve" nuestra ubuntu se le asigna el nombre eth0, a la segunda eth1 y así sucesivamente. Las asociaciones permanecen en el sistema aún cuando la tarjeta de red ya no está presente. Esto es muy práctico porque asi las posibles configuraciones de cada dispositivo estarían disponibles en el caso de volver a pinchar la tarjeta que hemos quitado. Pero hay escenarios en los que este comportamiento es molesto.

imaginemos que tenemos guardada una imagen de ubuntu que utilizamos para desplegar nuevas máquinas virtuales. En esa imagen hemos instalado "todo lo básico", de modo que podemos levantar nuevas máquinas virtuales en tan solo unos minutos. Es más, hemos sido tan cuidadosos que hemos guardado la máquina virtual con una IP fija accesible mediante a un dns local con un nombre como newimage.trabesoluciones.local, y hemos escrito un script que nos permite cambiar la IP y el nombre de host de un solo golpe. Parece sencillo y práctico,...pero al desplegar la nueva máquina virtual, ésta tendrá una MAC virtualizada diferente a la que tenía cuando la guardamos, por lo que el interfaz de red utilizable ya no será ethx, sino ethx+1. Esto genera una falta de determinismo a la hora de pensar scripts, además de que a los más puristas y puntillosos puede darles un síncope cuando vean que la máquina usa eth7 como interfaz de red.

para evitar llantos e incomodidades, el camarada farruco y yo estuvimos un rato investigando cómo funciona esta asociación mac-nombre a "bajo nivel". El tema es un poco extenso, así que vamos a quedarnos con lo fundamental: existe un fichero llamado /etc/udev/rules.d/70-persistent-net.rules en el que se almacenan estas asociaciones mac-nombre. Editándolo podremos cambiar los nombres asociados a los distintos interfaces.

en nuestro caso, como lo único que buscamos es que el interfaz sea siempre eth0 para nuestras virtuales, la receta es tan sencilla como borrar este fichero antes de exportar la imagen virtual. Así en el primer arranque de la nueva máquina virtual se escribirá en ese fichero la asociación de la mac actual con el nombre eth0. Más fácil imposible :D

drop sequence seq_one;
create sequence seq_one start with 76000 ;

Muy útil cuando importamos dumps y no queremos que las tablas cuyos IDs se asignan utilizando secuencias empiecen a dar problemas.

El error completo es algo más largo:

ERROR:
ORA-01034: ORACLE not available
ORA-27121: unable to determine size of shared memory
segment
Linux Error: 13: Permission denied

Surge al intentar utilizar las herramientas de consola (sqlplus, imp) desde la propia máquina en la que está instalado el oracle. Las conexiones JDBC, asi como el interfaz web funcionan correctamente.

De otras batallas, tenemos claro que hay que fijar correctamente el ORACLE_HOME y el ORACLE_SID, pero el problema persiste. Tras un rato de búsquedas, llegamos a la solución: el instalador de oracle (al menos en nuestra plataforma que es linux) no "marca" como setuid $ORACLE_HOME/bin/oracle. Sabiendo esto, la solución es fácil:

$ cd $ORACLE_HOME/bin
$ chmod 6751 oracle

En la oficina tenemos montado un proxy reverso con Pound para acceder a varios servicios desde fuera, entre ellos un repositorio Subversion. El mecanismo es sencillo: el SVN está montado en un virtual host de Apache con mod_svn escuchando en el puerto 80 y un Pound proxificando las peticiones HTTPs que recibe en el 443.

Todo funcionaba hasta que se nos dió por hacer un tag (esto es, un svn copy). 502 Bad Gateway al canto. ¿Mande?

Investigando descubrimos que las operaciones MOVE y COPY de Webdav utilizan el valor Destination de los headers de la petición. Valor que el proxy deja intacto con lo que Apache recibe un Destination “https://xxx” y se hace un lío. Teóricamente Pound ofrece soporte para solventar este problema utilizando el parametro de configuración RewriteDestination. Al que no le funcione puede probar a pedirle amablemente a Apache que le arregle el problema, utilizando mod_headers y configurando el virtual host de turno:

  <VirtualHost *:80>
    Servername svn.acme.com
    RequestHeader edit Destination ^https http early
    ...    

Por cierto, si alguien quiere que postee un howto sobre SVN con HTTPs detrás de un Pound que levante la mano.

Viernes, 20 de febrero de 2009, cuatro y cuarto de la tarde.

Tras casi tres años de servicio ininterrumpido apagamos Ortega. Desaparece el siseo de sus 4 ventiladores y el zumbido de sus discos SCSI. Con el silencio el tiempo se para. Una parte de mi muere. Una avalancha de recuerdos me sepulta. Ortega ha estado ahí desde el principio: el primer Subversion, la base de datos MySQL, las carpetas compartidas Samba. Todo lo que Trabe ha hecho, todo lo que hemos sido, ha pasado por las tripas de esta máquina. Parece que ha pasado un siglo.

El vetusto IBM ZPro que compré en una tienda de segunda mano cuando esta empresa no era ni un sueño descansa ahora en el almacén. Las cosas cambian. Es inevitable.

El ruido del nuevo servidor vuelve a poner en marcha el tiempo. La vida sigue sin ortega.

En mi post de ayer propuse una solución parar requerir gemas de GitHub con estilo, sin embargo me olvidé de una cuestión importante que me ha recordado Asís: el código depende de ActiveSupport, por lo tanto, ciertos scripts (por ejemplo console) no funcionan bien. La solución rápida es requerir ActiveSupport. La solución buena es eliminar la dependencia. Nuevo pastie al canto.

Mea culpa. Disculpen ustedes.

Llevaba tiempo pensando en simplificar la definición de dependencias de gemas de GitHub en el environment.rb de nuestras aplicaciones, pero no encontraba el momento. El domingo estuve leyendo un post de Bruce Williams en su blog CodeFluency: A GitHubby config.gem hack, donde propone una solución para pasar de esto:

config.gem 'yfactorial-utility_scopes', :version => '0.2.2', 
  :lib => 'utility_scopes', :source => 'http://gems.github.com'

...a esto:

config.gem 'yfactorial-utility_scopes', :version => '0.2.2', :github => true

Había dos cosas en su solución que no me gustaban: 1) el uso de un flag y 2) que la implementación sobreescribe el método gem. Así que me he animado y acabo de montar una versión que intenta paliar esos dos problemas. El código no tiene nada de especial. Podéis cogerlo de este pastie. Sólo hay que tirarlo en lib y requerirlo en environment.rb. Y con esto ya podemos escribir bloques de dependencias con estilo:

config.gem 'authlogic', :version => '1.3.8'
config.gem 'faker', :version => '0.3.1'  
config.gem 'spreadsheet', :version => '0.6.2.1'  

config.gem.github 'yfactorial-utility_scopes', :version => '0.2.2'
config.gem.github 'mislav-will_paginate', :version => '2.3.6' 
config.gem.github 'rubyist-aasm', :version => '2.0.5'

Actualización

Esta versión del código depende de ActiveSupport. En este post podéis encontrar una versión actualizada del código que no depende de AS.