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.

En el más reciente artículo de A List Apart, “12 Lessons for Those Afraid of CSS and Standards“, el autor nos da 12 consejos a tener en cuenta a la hora de iniciarse en el diseño web con estándares y CSS. La principal idea a tener en cuenta es que será muy duro, y el primer consejo casi lo define todo:

Lesson No. 1: Everything you know is wrong… sort of
Just so we’re on the same wavelength, I want to underscore the fact that if you’re starting to work with CSS, everything you’ve learned to this point probably feels useless, or worse than useless.

Una lectura interesante para aquellos que quieran pelear con (X)HTML.

A través de Versión Cero descubro que en Navegapolis están publico unos artículos en formato PDF sobre ingeniería del software, centrándose en las metodologías ágiles. Por ahora llevan 3 series de apuntes:

• Gestión de proyectos
• SCRUM
• Gestión ágil de proyectos

Por cierto, que no conocía Navegapolis, y ya lo tengo apuntado para poder seguirlo. Parece muy interesante.

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.

A través de Microsiervos descubrí una interesante gráfica sobre el tiempo dedicado al diseño web.

Real como la vida misma.

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.

Me topé con un par de enlaces, el primero sobre como editar plantillas de Wordpress con DreamWeaver. No es una de las herramientas que uso, pero me pareció interesante ya que algunas veces me planteo cómo deberían trabajar los diseñadores web en conjunción con los programadores (por experiencia juraría que gran parte del trabajo con el (X)HTML queda como trabajo del programador).

El segundo enlace es “Design Tips for Building Tag Clouds”, en el que se dan algunas sugerencias y consejos sobre como presentar las nubes de etiquetas, sin ninguna explicación técnica (nada de programación ni HTML), sólo es una breve discusión sobre cómo hacerlas más útiles.

Y ya puestos a dar enlaces quiero rescatar algunos que considero interesantes sobre diseño líquido. El primero, “Liquid layouts the easy way” en el que se da una introducción a los diseños líquidos en HTML (distribuciones de páginas que no tienen un tamaño prefijado y que se adaptan al navegador y/o al dispositivo). El segundo artículo “Liquid CSS Layouts - Design Alternative to Table Based Websites” es algo más extenso y entra en más detalle sobre las implementaciones. Son técnicas antiguas y seguramente muchos las conoceréis, pero no está de más intentar adoptar esa nueva forma de diseñar para hacer una web más usable y accesible ¿no créeis?

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.

En un artículo con una feroz crítica a las WCAG 2 (hay una traducción del borrador en Sidar) Joe Clark anuncia la creación de WCAG Samurai, que pretenden publicar correciones y mejoras de las WCAG 1.0 (también está disponible una traducción), que a pesar de tener más de 7 años consideran que puede ser un buen punto de partida.

Leyendo la crítica en la que se anuncia la creación de este grupo podemos adivinar que el objetivo es tener una un conjunto de reglas claras, bien definidas y basadas en estándares como HTML (parte de las quejas hacia WCAG 2.0 se centran en que ¡no es necesario tener (X)HTML válido!). También parece que quiera darse importancia a “la accesibilidad que no pueden comprobar las máquinas”, ofreciendo un lenguaje claro, alternativas para las personas con problemas de visión o sordera, una buena plataforma sobre la que desarrollar multimedia accesible.

Realmente me parece muy interesante el proyecto, creo que WCAG 1.0 a pesar de sus lagunas puede ser un buen punto de partida, y el espiritú que transmite el anuncio (centrarse en estándares y en lo que se ha aprendido en la realidad) me hace ilusionarme por unas WCAG 1.1-Samurai o como vayan a llamarlas. ¿Qué deseas ser miembro y aportar tus experiencias? Me temo que no podrá ser:

WCAG Samurai will toil in obscurity for the foreseeable future. Membership rolls will not be published, and membership is by invitation only. Don’t call us; we’ll call you.

En el mismo artículo explica que quizás no sea la opción más justa, pero que creen que para este tipo de documentos y especificaciones es la mejor forma de trabajar. Esperamos vuestro trabajo con los brazos abiertos, samurais.

Por cierto, Joe Clark trabaja como consultor experto en accesibilidad, escribió Building Accessible Websites, y colabora regularmente en ALA.

En “The web is excellent for distraction” no descubren nada nuevo, pero no viene mal que de vez en cuando lo recordemos.

‘Surfing’ is a really misleading metaphor, right? Surfing evokes images of beaches, bikinis, fun times and waves in the sun. Sitting glued to a monitor, clicking-away into the never-never is the furthest thing from this possible (OK, so may be there’s a few bikinis).

¿Os hace ser muy improductivos tener un navegador a vuestra disposición en cualquier momento? Yo debo admitir que sitios como Slashdot, Barrapunto y Bloglines más de una vez hacen que me salga de mi camino. No me extraña la aparición de términos como infoxicados (aunque debo admitir que me gusta más el término information overload.

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?

Varios apuntes sobre el tema, el primero va sobre envío de emails con Zend. Desde la aparición de su framework están haciendo mucho para conseguir que PHP sea más que un lenguaje y crear una plataforma unificada para adaptarse a los nuevos tiempos y a la nueva forma de desarrollar aplicaciones web.

Seguimos con un proceso automatizado para generar releases del software escrito por el autor de Solar (¡seguimos con los frameworks!) en el que explica como ha desarrollado un sistema para crear releases de su software de forma automática (algo más complejo que hacer un tar.gz ;-) )

Y ya por último, a través de Schifflet, en O’Reilly hablan sobre la escalabilidad de Digg y PHP. Un interesante artículo escrito por un desarrollador Java que viene a confirmar las posibilidades de un sistema share nothing, como explica Rasmus Lerdorf cuando habla sobre la escalabilidad de PHP.

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.