Bien batido y revuelto

Seguimos con Ruby on Rails y ahora se trata de las migraciones y los problemas que pueden aparecer cuando se trabaja en un equipo. No es un problema exclusivo de RoR, pero puesto que Rails invita a las buenas prácticas y ofrece un mecanismo interesante para definir la base de datos (las migracionadas), nos puede pasar desapercibido y olvidemos el problema de la estructura de la base de datos hasta que demos de lleno con el problema.

Cuando trabajamos en un equipo de desarrolladores en una aplicación Ruby on Rails puedes encontrarte con la situación de que 2 personas creen al mismo tiempo una migración. Puesto que el nombre del fichero contiene una primera parte con un número de migración es bastante posible que dos desarrolladores creen un fichero con el mismo número en su copia local, y por culpa de ello luego pueda resultar complicado salir del paso. Quien se haya encontrado con este problema sabrá de que estoy hablando, pero por si acaso mejor usaré un ejemplo:

Supongamos que estamos desarrollando una aplicación en la que existen usuarios (User) que escriben comentarios (Comment). En un determinado momento la base de datos está en la versión 12, y uno de los desarrolladores decide crear un sistema de roles y para ello crea 2 migraciones


$ script/generate migration add modify_user
exists db/migrate
create db/migrate/013_modify_user.rb
$ script/generate migration add create_roles
exists db/migrate
create db/migrate/014_create_roles.rb
$ rake migrate


Al mismo tiempo otro desarrollador está añadiendo la funcionalidad de tener comentarios anidados:


$ script/generate migration add modify_comments
exists db/migrate
create db/migrate/013_modify_comments.rb
$ rake migrate


Cuando terminan de implementar la funcionalidad que empezaron a desarrollar cada programador actualiza del repositorio y su copia local (svn update && svn ci), y en el caso del primer desarrollador, al hacer un rake migrate no se aplicará ningún cambio puesto que el fichero que subió el segundo desarrollador es un cambio para una versión 13, mientras que el segundo desarrollador al actualizar aplicará el cambio que modifica los roles. Además, los dos usuarios tendrán una versión de la base de datos no funcional y los cambios en el código dejarán una aplicación “rota” puesto que la base de datos no está tal y como la aplicación espera.

Quizás los primero que se nos pase por la cabeza para esquivar este problema sea subir al gestor de versiones las migraciones tal y como las creamos, pero esto puede crear nuevos problemas, porque quizás el cambio haga que la aplicación deje de funcionar del todo. Un ejemplo típico de ese caso podría ser que decidimos cambiar la forma en la que se guardan las direcciones de los usuarios y el campo Address desaparece y aparecen los campos ZIP, City y demás; en este ejemplo no podríamos subir la migración hasta que no hayamos completado algo el código.

Si bien es cierto que unas buenas prácticas como Integración Continua (por cierto, tengo pendiente mirar CruiseControl.rb) detectarían el problema, la realidad es que no es algo trivial de solucionar. De hecho hay algunas propuestas como migraciones con marcas temporales, llevar un control de las migraciones que hay en el repositorio, o bien detectar la colisión en el commit pero en todas ellas encuentro diversos problemas que no se superan del todo. Creo que al final la mejor solución es evitar cualquier remedio técnico al problema y usar una la comunicación para conocer las intenciones de modificar la base de datos. Posiblemente sea la solución con menos contras ¿o tenéis alguna otra?

Eso es lo que me pregunto. Hace poco, como ya comenté, me pasé a Ubuntu 64, y la verdad es que no me apetece ponerme a instalar Flash en un entorno de 32 bits que corra en mi sistema de 64 bits, así que puede que me toque esperar hasta que Macromedia decida publicar una versión nativa.

Hasta hace poco podría haber pensado que Flash no era tan imprescindible, pero desde hace algún tiempo se ha vuelto casi imprescindible para visitar sitios como YouTube, de hecho casi se ha convertido en el estándar de facto para ver vídeo online (y hoy en día hay mucho material en forma de screencasts), así que me pregunto ¿cuánto tiempo creeis que estaré sin Flash? A veces uso mutt y links así que puedo estar medio acostumbrado, pero la verdad es que me está siendo duro. ¿Alguien más está en mi misma posición? Juntos tendremos más voluntad :-)

Desarrollar en una plataforma como RoR no siempre es tan sencillo como uno piensa, a veces hay cosas que uno no ve coherente: los ActiveRecord tienen un class de Array pero el método find es el de AR no el find de un Enumerable (mi pequeño trauma con Rails). Aparte también hay que tener cuidado con la versión de Rails que estés utilizando, ya que pueden ocurrirte cosas como este problema con Gettext que hace que no se puedan guardar datos.

Estoy de acuerdo en que el problema que menciono es un problema con una librería de un tercero, pero mejor no entremos en ese tema porque aún sigo sin comprender como una plataforma creada por un danés en un lenguaje diseñado por un japonés no soporta internacionalización.

Si no lo decía reventaba.

Entre los favoritos de del.icio.us me topo con este ‘microtutorial’ para crear guía de estilo para un sitio web. La idea es tan simple que uno se sonroja de no haberla pensado antes. Tan sólo se trata de crear un documento HTML en el que se usen todos los estilos que se usarán en el sitio, describiendo su uso con una frase para cada elemento.

Creo que es un muy buen complemento al método de desglosar las páginas antes de diseñarlas. De hecho los autores del microtutorial han decidido que los sitios empezarán a crearlos desde la guía de estilo. Habrá que estudiar esa opción.

Me ha parecido interesante un artículo que menciona fernand0 sobre un error de la aplicación notepad.exe cuando escribe y lee un fichero: this API can break. El error aparece al intentar reconocer el juego de carácteres en el que está grabado el fichero. Lo que me recuerda a que mencioné aquí un trocito de código que intentaba identificar una cadena UTF-8.

Por cierto que me encanta la cita con la que termina el artículo

In the face of ambiguity, refuse the temptation to guess.

Seguramente en muchas ocasiones nos hemos visto envueltos en una rutina de reuniones de trabajo que hemos considerado poco productivas. La realidad es que conseguir que las reuniones sean interesantes no es tarea fácil, de hecho incluso hay muchos que las consideran como un mal a erradicar. En The Daily Stand Up y en la segunda parte del artículo describen unos métodos para hacer reuniones de forma rápida y sin perder el interés.

Algunos de los métodos que describen es utilizar un elemento que señale quien tiene la palabra (un balón o algo así), o bien seguir un estricto turno aleatorio (utilizando tarjetas numeradas). Aunque la realidad supongo que será mucho más compleja que con coger un mecanismo y aplicarlo, con todo lo que hay escrito sobre gestión de proyectos, como para pretender sentar cátedra.

Ya he hablado sobre cómo fijar precios para productos, así que me pareció interesante enlazar a Don’t forget the premiun plan.

It’s $80 more than the Pro plan ($19 vs. $99), and we were worried that it might be a bit too expensive. Holy crap, were we wrong.

Y explica la experiencia de un producto web que ha conseguido aumentar sus ingresos gracias a un producto. Otro enlace interesante, sobre un caso típico de los precios la enlazan en los comentarios. Además, así también he descubierto Vitamin un sitio que parece bastante interesante para ir observando el momento punto-com 2.0 desde un punto de vista optimista y constructivo.

Descubro un artículo sobre las lecciones que pueden aprenderse de la gestión de un proyecto como Debian en Debian lessons (vía fernand0). Se explican las cosas que se han hecho bien, y las que podrían mejorarse, para conseguir llevar adelante un proyecto tan gigantesco como es Debian.

Do not worry about time tables; keep goals realistic. In big volunteer projects, time tables will always slip. That is not a catastrophe, and it must be tolerated, but there should still be some effort in keeping them. Goals must be kept realistic.

Y relacionado con la gestión de equipos de desarrollo, Spolsky habla sobre cómo el gestor debe convertirse en una capa de abstracción entre los desarrolladores y el mundo real: “The Development Abstraction Layer“

Software is a conversation, between the software developer and the user. But for that conversation to happen requires a lot of work beyond the software development. It takes marketing, yes, but also sales, and public relations, and an office, and a network, and infrastructure, and air conditioning in the office, and customer service, and accounting, and a bunch of other support tasks.

El momento “Web 2.0″ está trayendo muchas cosas que no tienen nada que ver con AJAX ni con estándares; está haciendo que se hable de cómo se deben afrontar los proyectos, se están creando formas de desarrollo más rápidas y el software libre está sirviendo como gran fuente de inspiración y campo de pruebas. Es cierto que hay mucho ruido sobre metodologías, gestión de pequeños grupos y demás pero ¿es real? ¿o son pensamientos amplificados por la lente de la blogosfera?

Hoy esta bitácora está desnuda. ¿Por qué? Porque merece la pena.

Descubro “ 5 claves por las que interesa cuidar el ritmo de posteo en un blog “. Quizás debería aplicarme el cuento. Digo yo.

A través de la lista de AccesoWeb me topo con un artículo sobre accesibilidad en las webs de universidades españolas. ¿La conclusión? Muy mala. Las instituciones no han demostrado ningún interés por mejorar sus sitios, incluso ha llegado a empeorar.

Menos mal que tenemos una legislación al respecto ¿no?

Esta es para Windows. Una vez escribí sobre un método para tener varias versiones de MSIE, y ahora no recuerdo dónde me he encontrado con Runing IE7 Beta 2 Preview next to IE6en el que se describe como poder utilizar los dos navegadores simultaneamente. Desde el artículo original sobre las distintas versiones podemos llegar a IE7 Standalone Launch Script que también nos servirá para tener un MSIE 7 junto a otras versiones.

Tristemente la realidad nos impone (casi no podemos evitarlo) que las páginas tengan que ser soportadas por MSIE, un navegador abandonado en el aspecto del CSS y culpable de muchas horas de trabajo extra para los pica-HTML.

En los blogs kdeveleopers me topo con “How to simulate a slow network“, un articulo sobre el uso de tc (la herramienta para control de trafico del kernel Linux) para simular una red con alta latencia.

Debo confesar que nunca se me habia ocurrido, ni siquiera conocia esa posibilidad. Sabia lo de controlar el ancho de banda y lo he usado para trastear y simular anchos de banda mas reducidos, pero lo de la latencia no lo conocia. Tomo nota.

Una breve historia

Podemos remontarnos a ASCII-7, una tabla de caracteres de 7 bits que representaba los carácteres más usuales del mundo anglosajón. Sin embargo ¿qué pasaba con los carácteres extranjeros? Para solucionarlo se creó ASCII extendido, esta vez con 8 bits y 256 carácteres disponibles, pero aún así no era suficiente para contentar a todo el mundo, porque entre tildes, letras raras, signos y demás no podiamos meter todos los caracteres no-ingleses que necesitabamos en 128 carácteres que eran lo que nos dejaba ASCII extendido. Así que la solución fué crear distintos ASCII
extendidos, las famosas iso-8859. Cada tabla de carácteres iso-8859 especificaba distintos carácteres, así cada país podía utilizar el juego de carácteres que mejor se adaptara a su grafía. En el caso español usábamos iso-8859-1 que incluía la mayoría de carácteres europeos occidentales.

Problema resuelto ¿no? Pues puede que sí, al menos parcialmente. A menos que necesites escribir un texto con ñ (iso-8859-1) y un carácter arábico (iso-8859-6) pero tampoco es para tanto, vamos digo yo. Aunque ahora que lo pienso, si alguien me envía un texto con carácteres extendidos ¿cómo se que tabla está usando? Vaya, no puedo descubrirlo… pero tampoco es tan grave, ya lo resolverán las aplicaciones: los servidores web envían la codificación del fichero, y lo mismo ocurre en casi todas las demás cosas. Aunque todavía me queda saber cómo hace el servidor web para saber qué tipo de codificación utiliza un fichero HTML o .txt determinado. ¿Quizás no puede adivinarlo? Vaya, entonces tenemos un problema. Empiezo a pensar que esto de ASCII no es tan buena idea… 128 carácteres fijos y 128 que pueden cambiar y no se cuándo se usa cual no me parece divertido.

Ya hemos descubierto el problema, ahora la solución

Nos ha quedado claro que el problema que nos encontramos es que no podemos limitarnos a tener 128 carácteres fijos y luego que cada documento tenga un juego de 128 carácteres extendidos, porque no soluciona el problema del intercambio de documentos ni permite usar los carácteres que necesitemos en cada momento, nos vemos limitados a un juego.

Así que como solución surge Unicode. Un juego de carácteres universal capaz de identificar 2^32 carácteres (4.294.967.296), y en tantos carácteres pueden codificarse todas las grafias del mundo (incluso se intentó codificar la grafía Klingon :) ), presentes y pasadas. Así que genial, ahora tenemos un sistema de codificación que nos permite utilizar cualquier carácter y nuestros documentos podrán ser leidos por cualquiera. Si es que ya les pasó cuando hicieron ASCII extendido para ampliar ASCII-7, que se conformaron con duplicar las opciones y tendrían que haber ido a lo grande, pero nunca es tarde si la dicha es buena.

Los peros

Así que tenemos claro que usaremos Unicode para representar cadenas de texto, con sus 32 bits nos permiten codificar cualquier texto imaginable aunque esto tiene 2 graves consecuencias. El primero y más obvio es el tamaño de las cadenas. Este texto tiene unos 6.700 carácteres, lo que codificado como ISO-8859-15 son 6.700 bytes, sin embargo en Unicode eso serían casi 27.000 bytes, y aunque el ancho de banda y el espacio en memoria cada vez es menos problemático para almacenar texto, sigue siendo multiplicar por cuatro.

El otro inconveniente viene de utilizar un sistema de codificación nuevo y totalmente distinto. Hay que reescribir todas las funciones que estén relacionadas con las cadenas: medir el tamaño de una cadena, representarla, leerla, partirlas, unirlas, ordenaralas…. nada de lo que teniamos sirve y todo hay que reescribirlo.

Y a todo esto podemos tener una idea de lo engorroso que es mantener al mismo tiempo texto en Unicode y otros formatos, aunque tampoco es demasiado distinto a tener que trabajar con distintas codificaciones.

Así que como solución a parte de los problemas se crearon UTF-16 y UTF-8. El primero es una representación en palabras de 16 bits de los carácteres, de forma que la mayoría de carácteres puedan ser representados en 16 bits. Pero sigue teniendo la pega de que nos es necesario tener código capaz de trabajar, representar y leer esas cadenas. El otro invento fue UTF-8, que codifica los carácteres más utilizados en 8 bits y ahorra mucho espacio, y la realidad nos demuestra que vino para quedarse.

Y el enemigo número 1: UTF-8

UTF-8 no es tan malo: nos permite utilizar Unicode y ahorramos espacio ¿no? Sí, eso es verdad. Pero eso son efectos colaterales del verdadero objetivo del uso de UTF-8 que podemos descubrir recurriendo a un poco de historia.

Se supone que el primer email de la historia fue un texto de prueba, algo como QUERTYIOP y que tras
esa prueba se enviaron otros mensajes. Ese primer mail se envió en 1971 y podriamos apostar a que estaba escrito en ASCII (que se presentó en 1967). Así que imaginad que cogemos todos esos mails que se enviaron hace más de 30 años en ASCII y que causaron tantos problemas de intercomunicación entre distintos idiomas, que dieron tantos quebraderos de cabeza (todo el que haya tenido que configurar consolas sabe de que estoy hablando) y de repente por arte de magia ¡son textos internacionales¡ ¡bendigamos a UTF-8!

Unicode pretende ser la respuesta a un problema complejo que se vió acentuado por el intercambio de información en a las redes informáticas. Solucionar el problema es engorroso: durante un periodo se producirán incompatibilidades entre programas y usuarios de Unicode y aplicaciones y usuarios que siguieran con juegos de caráceteres variados e incompatibles.

Si Unicode y todos los iso-8859 conviviesen existirían problemas en los que los textos serían totalmente incompatibles: una herramienta que no soporte Unicode mostrará un montón de basura ilegible y no podrá hacer nada con él, y lo mismo ocurriría en el caso contrario. Sin embargo UTF-8 surge como un intento de camuflar ese problema, de repente la solución es “compatible hacia atrás” y todos los textos escritos en ASCII-7 son también Unicode (UTF-8, pero Unicode a fin de cuentas). Y las rutinas de clasificación, de partir cadenas, los filtros, todo funciona perfectamente. Siempre y cuando sea ASCII-7, suficiente para los anglosajones.

En resumen, con UTF-8 se consigue adaptar una solución y degradarla para que no resulte demasiado molesta. Para que sólo “los que tienen el problema” tengan que lidiar con ella, con una solución intermedia, para no tener que saltar todos al tren del Unicode.

Por eso odio UTF-8. Porque es el mal menor y lo han hecho a posta.

PS: Un excelente artículo sobre esta historia es “Characters vs. Bytes“.

Supongo que no seré el único que tenga en su agregador a Jakob Nielsen así que quizás conozcáis ya el artículo, pero esta vez suelta otra verdad de perogrullo: si vas a montar la web de una empresa céntrate en los contenidos principales.

• Communicating clearly so that users understand you. Users allocate minimal time to initial website visits, so you must quickly convince them that the site’s worthwhile.
• Providing information users want. Users must be able to easily determine whether your services meet their needs and why they should do business with you.
• Offering simple, consistent page design, clear navigation, and an information architecture that puts things where users expect to find them.

Get these three right, and you’ll enhance your site’s credibility, ease a user’s way through the site, and thus do far more for the site’s business value than any JavaScript trick.

Creo que la mayoría estamos de acuerdo en que muchas veces la visión técnica de las cosas nos hace olvidar otros aspectos, y más cuando estamos hablando de negocios o de llegar a “usuarios normales”, y muchas veces queremos centrarnos más en poder usar AJAX, en aspectos espectaculares o en aplicaciones Flash antes que centrarnos en el contenido.

Al menos a mi me pasa.

En The Best of Web 2.0 se hacen eco de los mejores sitios “web 2.0″ (sea lo que sea eso). Interesante para saber a dónde estamos llegando tarde :-)

Ajaxian es una de mis fuentes de noticias, y esta vez lo que me impresionó fue la cita sobre el nuevo servicio de Yahoo! Photos (más Web 2.0 y tal), respecto a porqué Yahoo! se empeñaba en mantener su servicio de fotos después de haber adquirido Flickr. Y he aquí la respuesta:

But what most people don’t know (I didn’t) is that around 30 million unique monthly visitors come to Yahoo Photos (the other Yahoo photo service) v. about 8 million on Flickr.

Pocos servicios web tienen tantos enlaces, tantas referencias y tantos usuarios hablando de sus bondades como Flickr, y sin embargo sus números quedan eclipsados por los de un producto que “nadie” usa, que “nadie” quiere y que viene de una compañía “obsoleta”, tan de los 90. ¿Realmente el murmullo de la blogosfera es representativo de algo?

Estas navidades le regalé a mi novia una Nintendo DS con el juego Nintendogs ¡y quedé enganchado al cacharrito! Tanto que se me pasa por la cabeza quizás intentar conseguir si pudiera una DS Lite. Pues mi deseo se ha visto incrementado cuando me entero de que Opera sacará un navegador para la DS y así poder aprovechar aún más su WiFi.

Acabaré volviendo a ver Super Mario.

Jeremy Zawodny transforma una presentación sobre el futuro de la Web en una serie de consejos para managers y me han parecido muy interesante las dos ideas.

Figure out what data is important, how it will be stored, represented, and transferred. Think about the generic services that one can build on top of that repository. Only then should you get the wireframe geeks and/or the photshop geeks involved.