Bien batido y revuelto

Migraciones y trabajo en equipo

SegFault — Thu, 15 Mar 2007 18:48:59 +0000

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?

¿Cuánto tiempo se puede estar sin Flash?

SegFault — Sat, 17 Feb 2007 20:14:55 +0000

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 :-)

Rails: moving target

SegFault — Tue, 06 Feb 2007 06:57:52 +0000

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.

Doce consejos para iniciarse en CSS y estándares

SegFault — Wed, 27 Sep 2006 16:37:36 +0000

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.

Apuntes sobre ingeniería del software

SegFault — Tue, 19 Sep 2006 21:41:23 +0000

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:

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

Guía de estilo para un sitio web

SegFault — Wed, 23 Aug 2006 11:36:47 +0000

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.

Reparto del tiempo dedicado al diseño web

SegFault — Mon, 17 Jul 2006 20:59:40 +0000

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

Real como la vida misma.

Problema de notepad con Unicode

SegFault — Thu, 15 Jun 2006 19:33:39 +0000

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.

Algunos enlaces sobre HTML y familia

SegFault — Sun, 11 Jun 2006 21:48:58 +0000

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?

Sobre como gestionar las reuniones

SegFault — Mon, 29 May 2006 20:38:23 +0000

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.