A vueltas con el Tokyo Project

Hace algunas semanas hablé sobre el Tokyo Project por aquí pero hoy os voy a contar un poco mas sobre el tema.

La cosa empezó cuando encontré por casualidad un framework para Ruby llamado Padrino. Me pareció interesante porque llevaba buscando frameworks alternativos a Rails ya que de un tiempo a esta parte se ha hecho cada vez mas «lento» y «grande», y para la mayoría de aplicaciones web de estar por casa se comienza a quedar grande.

En fin, me puse a aprender Padrino y como cada vez que comienzo a aprender algo hice un proyecto pequeño para probar lo que iba aprendiendo. Al mismo tiempo llevaba tiempo con la idea de hacer algo con mis fotos a parte de subirlas a flickr o mostrarlas por aquí de vez en cuando.

Mi idea inicial era mezclar relatos cortos con imágenes, algo parecido a lo que hago por aquí, pero sin el contexto tan personal del blog.
Así que hice una primera versión del Tokyo Project centrada para mostrar textos e intercalar mis fotos del flickr con los párrafos.

Como proyecto de aprendizaje fue entretenido, pero el resultado final no me gustó. Así que seguí iterando sobre la idea y al final decidí invertirla. Crear una especie de carrusel de imágenes con un pequeño texto identificando la imagen.
También se me ocurrió inicialmente poder escribir textos para cada imagen en varios idiomas, así me fuerzo a practicar Japonés y refresco el Inglés.

Y así, sumando ideas, escuchando comentarios y ajustando estilos y colores surgió el actual Tokyo Project 🙂

Hay un par de ideas que tengo para este sitio, y creo que será algo que me tendrá ocupado hasta finales de este año o quizás hasta bien entrado 2014, pero todavía no quiero contar mucho no sea que se gafen las cosas.

A raíz de una sugerencia, y a parte de que ya lo estaba pensando desde hace algún tiempo, estoy tratando de darle una identidad al sitio, algo que lo haga reconocible. Así que lo primero que se me vino a la cabeza fue crear un logo.

Jorge Salazar, un buen amigo y un increíble diseñador siempre me ha ayudado con todo lo relacionado con logos. Fue el creador del logo del antiguo donderis.net y varios otros proyectos pasados. Pero en esta ocasión no quise volver a abusar de él y terminé usando 99designs para tratar de dar con un logo. El concurso terminará mañana con un ganador, aunque todavía no tengo ni idea de cual 🙂

A estas alturas todos los logos seleccionados para la final me gustan, pero ya no se trata solo de que me guste a mi, si no de que sea lo suficientemente atractivo como para crear una identidad para el sitio. Así que estoy haciendo un poco de todo para sondear cuales son las reacciones de la gente.

Ya os contaré, una vez que termine el proceso y haya elegido el logo ganador, cual ha sido el proceso. No deja de ser curioso.

RailsConf 2009

Me contaba ayer mi colega Brian que va a estar hablando en la RailsConf 2009.
Las RailsConf son, por así decirlo, como el sueño húmedo de cualquier programador de RoR, donde se reúne lo mejor de lo mejor para compartir sus experiencias, dar consejos y en general conversar de todo lo relacionado con esta tecnología.

La convocatoria es del 5 al 7 de Mayo en Las Vegas, Nevada. Me pilla un tanto lejos, así que probablemente me la tenga que perder, pero si tenéis la oportunidad de asistir al evento y os gusta Ruby on Rails, yo no me lo pensaría 2 veces.

Enseñando trucos nuevos a un perro viejo

Hace algunos días, Miguel Rodríguez hacía esta pregunta en su twitter:

¿Está Rails listo para las empresas? la pregunta correcta es ¿Las Empresas estan lista para el desarrollo AGIL en Rails?

Esto es algo en lo que llevo pensando los últimos meses, no específicamente con Rails, pero sí con el desarrollo ágil en general.

Paradójicamente la industria del software, que debiera adaptarse mejor que cualquier otra industria a los cambios teniendo en cuenta el producto que manufactura, es en cierto modo reticente a los cambios drásticos.
Pero cuando hablo de industria de software me refiero tanto a proveedores como a clientes.

Parece mentira que a día de hoy, sigan existiendo empresas que utilicen el desarrollo en cascada para desarrollar sus proyectos.

Esto está empíricamente probado que no funciona!

Entonces la pregunta que yo me hago es:

¿Qué impulsa a las empresas y a los clientes a usar metodologías viejas y obsoletas, blindarse con contratos de desarrollo y entregas definidas en fechas a priori sin tener especificaciones detalladas o en ocasiones, sin conocer realmente el producto que se desea desarrollar ?
Este tipo de proyectos y contratos suelen acabar en frases como esta por parte del cliente:
«Esto es justo lo que te pedí, pero no es lo que quiero»

El software desde mi humilde punto de vista, es como la materialización digital de una idea.
Pero trabajar con algo tan abstracto como una idea requiere agilidad, adaptación, imaginación… algo que desde mi punto de vista choca frontalmente con reglas fijas, diseños «grabados en piedra», documentos de funcionalidad intocables, etc.

Cualquiera que sepa algo de tecnología, o haya tenido algo de experiencia, por poca que sea, en el desarrollo de software debe saber que el software jamás queda «escrito en piedra», está en su naturaleza mutar, evolucionar (si, algo así como los pokemons) y en general estar sujeto a todo tipo de cambios.

Poco a poco han surgido diferentes metodologías, y frameworks que, una vez comprobado que lo rígido no funciona, han desarrollado una tendencia ágil para desarrollar software.

En general estas metodologías y frameworks, se adaptan en mayor o menor medida al desarrollo en espiral el cual es mucho más flexible en cuanto a incorporar cambios a nuestro producto.


Imagen cortesía de la Wikipedia

En concreto Rails, es un framework ágil para Ruby, uno de los lenguajes que considero que tiene más potencial de cara al futuro (flame wars aparte)

Rails es uno de tantos frameworks (Grails, Spring, Tapestry…) que ayudan a incorporarse en esta nueva tendencia del desarrollo ágil, pero de nada sirve tener un buen framework si no modificamos nuestra mentalidad en cuanto al desarrollo de software.

Documentación sobre desarrollo ágil hay a patadas, Extreme Programming, Scrum son sólo algunos ejemplos de los muchos que se pueden encontrar.

Pero mi punto es que, de nada sirve (o al menos de muy poco) la revolución ágil, si la industria (aka. proveedores y clientes) no cambian hacia lo ágil, y en mi opinión esta es una asignatura pendiente para las grandes corporaciones y en los programadores.

Poco a poco se está demostrando que pequeños grupos de trabajo entregados al desarrollo ágil, con clientes que apuesten por éste y se involucren en el proyecto, resultan mucho más productivos y sus productos mucho más satisfactorios que aquellos gestionados/implementado con viejos estándares, cláusulas, y documentos de funcionalidad «escritos en piedra».

Pasará como con los dinosaurios y las grandes corporaciones de software estarán condenadas a la extinción?

Cambiar hacia lo ágil está lleno de retos, hay q cambiar de mentalidad, eliminar la pereza de modificar las cosas ya realizadas y probadas, adaptarse a los cambios del cliente, e incluso incentivar a éste para que participe, se involucre, pruebe, haga y deshaga…
No hay nada escrito en piedra, todo está sujeto al cambio, es más, el cambio es el motor del mismo desarrollo…

Es la revolución ágil, te apuntas?