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.

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.

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.

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.

Planes premium en la web

SegFault — Sat, 06 May 2006 15:41:59 +0000

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.

Por su seguridad Iberia recomienda no usar Windows

SegFault — Sun, 23 Apr 2006 21:36:51 +0000

Gestion de proyectos 2.0

SegFault — Thu, 20 Apr 2006 14:00:00 +0000

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?

Desnudo

SegFault — Wed, 05 Apr 2006 07:10:44 +0000

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