Para algunos, ilusión, deseo, fantasía, para otros algo próximo a concretarse y para otros como Manuel Aristarán y Michel Martens pura realidad. Han desarrollado en RoR una aplicación web con todas las letras, hablemos de nombre, cantidad de visitas, exposición, tiempos de desarrollo. Si señores, gracias a estos dos muchachos Argentinos Madame Le Figaro esta online y completamente en RoR. Que tal? Algunos mitos, van cayendo y de a poco se van animando a usar RoR en entornos más grandes. Me pareció interesante hacerle una especie de reportaje (no soy periodista) a Michel y a Manuel para que nos cuenten algunas cosas sobre el proyecto y su experiencia, creo que nos puede servir a todos para difundir esta tecnología que nos da tantas satisfacciones.
Reportaje a Michel Martens y Manuel Aristaran: Proyecto Madame Le-Figaro en Ruby on Rails
El reportaje se divide en 2 partes. La primera una transcripcion del chat con Michel Martens el 31/12 y la segunda las preguntas que respondio en un google doc Manuel Aristaran
me: Cómo se gesto el proyecto? estaban decididos por RoR?
Michel: El proyecto surgió por iniciativa de Laurent Rojot, un francés que fue director de Elle.fr durante varios años y la convirtió en la revista online líder del segmento. Para este proyecto decidió contratar a Marca Tatem para la programación y a la agencia Area 17 para el diseño. Como los plazos del proyecto eran muy cortos, Marca decidió desarrollarlo con Ruby on Rails.
me: Marca tenia experiencia anterior en proyectos RoR?
Michel: Había realizado algunos proyectos entre medianos y chicos, pero fundamentalmente estaba muy al tanto de lo que significaba utilizar esta tecnología. Al principio la idea era que coordinara el equipo de programadores que realiza trabajos para Le Figaro habitualmente, pero como no fue posible, dado que todos programaban PHP, tuvo que salir a buscar programadores freelance para armar un equipo.
me: Cual fue el impacto en diferencia de tiempo contra otras tecnologias, se conoce esa información, digamos, estimaron cuanto le podría haber llevado el mismo proyecto con otra tecnología?
Michel: Lo único que sabemos al respecto es que todos (la agencia, la dirección del diario) estimaban que en el plazo de tres meses no había forma de que lo lográramos. Un detalle significativo es que al equipo de programadores PHP se le encargó el desarrollo de un minisite con la guía de regalos navideños, algo relativamente sencillo, y demoraron un mes y medio en entregarlo.
me: Con la compu adelante y un proyecto semejante, RoR y sus mitos, cuales fueron las sensaciones, temores, desafios, etc?
Michel: Creo que el temor desde el primer momento fue la performance. El proyecto era enorme (180 modelos, 300 vistas, 110 controladores), pero en cuanto al desarrollo nos teníamos algo de confianza.
me: Yendo un poco a lo tecnico, como se manejaron con esa cantidad de controllers y modelos?
Michel: En cuanto a la organización de los archivos, creo que no hicimos nada en especial. Los modelos estaban en subdirectorios, eso es todo. Lo que sí nos sirvió bastante fue que empapelamos toda la oficina con screenshots del diseño, creo que fue una muy buena idea porque nos permitió familiarizarnos con el producto final aún antes de empezar el desarrollo del frontend. bq. Y además había bastante comunicación entre nosotros, a pesar de que en esa oficina se hablaban tres idiomas diferentes.
buenas again tenes ganas de seguir un poco?
Michel: Dale, hasta que esté la cena.
Como impacto el ser un extranjero en el desarrollo, si hubiesen estado en argentina hubiese salido mejor o mas rápido?
Manuel acota: bq. Lo que rescato es la buena recepción que tuvimos allá. Llegué al proyecto sin saber una palabra de francés. A pesar de lo celosos de su cultura e idioma que son los franceses, eso no fue problema. Al mes de empezado el proyecto y ante la necesidad de otro programador, recomendé a Michel (otro argentino!) y fue contratado.
Michel: Creo que en gran medida nos jugó a favor, porque había mucho respeto por lo que proponíamos. Durante nuestra estadía en las oficinas de Le Figaro escuchamos cómo el director del área comentaba a sus colegas que habían traído expertos de Argentina. Creo que gracias a que nos percibían de esa manera pudimos trabajar a gusto. La única incomodidad fue el idioma, pero tampoco fue grave.
me: Cconsideras que en argentina no hay tanto respeto por los desarrolladores?
Michel: En ciesta medida sí. Algo que me llamó mucho la atención allá fue el grado de especialización de cada uno de los que trabajaba en el proyecto. No me refiero sólo a los programadores, sino a quienes tenían a cargo la concepción estética del website, de quienes escribían, quienes corregían, los fotógrafos, los diseñadores gráficos.
Había una persona que se encargaba de recortar las fotos. Sólo eso. El director artístico del proyecto era la autoridad máxima en cuanto al diseño, y no dejaba que el director de Madame Figaro metiera bocado. Acá esos límites no se respetan demasiado.
Y por otra parte, creo que ese entrenamiento al que estamos sujetos los argentinos nos juega a favor en proyectos como este. Manuel es muy buen programador pero además es muy buen administrador de sistemas, es bueno optimizando bases de datos, etc. Allá no es común tanta versatilidad.
me: Aplicaron metodologías ágiles? Cuales y que les dejo?
11:12 PM Michel: Bueno, lo que se dio naturalmente fue que cada uno se fue dedicando a lo que más sabía. Manuel y yo trabajamos mucho juntos (pair programming), y desde el primer momento tuvimos en mente la optimización que queríamos lograr.
me: Cual es la parte o problema que mas les gusto como lo resolvieron?
Michel: Dos problemas interesantes eran el caching y la creación de formularios y vistas para el backend. No era posible usar sistemas de scaffolding porque los requerimientos eran muy específicos, así que Manuel se despachó con AutoAdmin, un scaffolding muy flexible que nos permitía describir en diez líneas lo que de otra manera hubiera demandado decenas de acciones en cientos de controladores. Para el caching hice Sweep/Observe, una librería que permite guardar el resultado de una acción en memoria y expirarlo automaticamente ante una modificación en los modelos observados sin la necesidad de crear sweepers ni declarar explícitamente las rutas que deberían expirarse.
Cuales fueron las cosas que mas molestaron (esas que siempre aparecen hasta en los lenguajes amigos de los programadores)?
Michel: Las vistas. Nada más tedioso que las vistas, y en esto creo que Manuel va a coincidir conmigo.
me: Creés que hay una deuda pendiente de RoR en la forma en que hoy resuelve las vistas?
Michel: Es un problema complicado y no sé si existe una solución satisfactoria. ERB es por lejos lo menos elegante de Rails, y otras propuestas como HAML y Markaby ya se alejan demasiado de lo que puede manejar un diseñador. No sé bien qué prefiero. En conclusión, te diría que sí es una deuda pendiente, pero tampoco tengo muy claro lo que quiero.
me: tirate 3 tips para alguien que va a encarar un proyecto similar
Michel: Lo principal es rodearse de gente inteligente.
Michel: Algo que me gustó de Marca, quien lideraba el proyecto, es que ante un pedido de incorporar o modificar algo del proyecto, respondía con un “Perfecto, lo lo podemos hacer para la versión 2”. Es una respuesta a la que yo no estaba acostumbrado y me parece genial, así que el segundo tip es que se hagan respetar y que hagan respetar lo convenido.
me: y en cuanto a lo tecnico seguramente te gustaria dar un par de sugerencias
Michel: En cuanto a lo técnico, a mí me resulta muy útil escribir especificaciones con rspec. Y también creo que es importante no ser demasiado respetuoso con el código ajeno.
Con esto me refiero a no tener miedo de modificar un plugin o alguna librería de Rails.
me: como resolvieron el tema performance?
Michel: Ugh, ya está la comida. Disculpame. La seguimos después?
me: * dale y me voy al sobre toy frito
Michel: Nos vemos
me: ya me quedan pocas preg me: buen provecho Michel: Chaus Gracias
Offline
Cómo fue que los convocaron desde Francia?
Manuel: Inicialmente me contactó el director del desarrollo, Marca Tatem por email. Luego de varios días de charlas por chat, teléfono y mail, se confirmó el contrato y empecé a preparar el viaje.
Una vez allá, al mes de empezado el proyecto, se planteó la necesidad de otro programador y recomendé a Michel a quien ya conocía de hace tiempo, y fue mi “sensei” de Ruby hace ya casi 2 años.
Que requerimientos en cuanto a calidad de codigo tenian, digamos unittests, coverage, etc?
Salvo Michel que, por iniciativa propia, usó RSpec para un par de modelos, no utilizamos tests en ninguna parte del sistema. El único requerimiento de calidad fue un sistema que funcione :)
Que errores cometieron (sie es que cometieron, o se animan a contar) y recomiendan evitar?
El mayor error fue no utilizar tests bq. Seriamente, el haber definido tests para los modelos (Unit testing) nos hubiera evitado algunas inconsistencias y momentos de desesperación cuando aparecían bugs misteriosos. Además, hubiera mejorado la comprensión y la calidad del código en algunas partes críticas. Los tests demuestran el buen funcionamiento de un sistema al menos para los casos testeados, pero también tienen el efecto de mejorar la calidad del código. El código que permite ser testeado fácilmente es código bueno. bq. En cuanto a los tests funcionales, los encuentro tediosos. Dado el deadline increíblemente corto que teníamos, creo que no hubiéramos sacado buen provecho de ellos.
Preguntas: top 5 plugins?
- AutoAdmin (nuestro “scaffolding”)
- SweepObserve (nuestro sistema de caching)
- file_column (viejo y no demasiado bueno. La próxima voy a usar acts_as_attachment)
- Partitioned ID
- acts_as_authenticated
Van a compartir algo?
Personalmente, me gustaría mejorar y reescribir algunas partes de AutoAdmin para poder liberarlo. Actualmente es muy dependiente de funciones y particularidades específicas de Madame Figaro. Hasta que lo libere, vale decir que AutoAdmin es Django on Rails: provee un DSL para definir declarativamente un formulario de ABM y un listado correspondiente a un modelo. Este enfoque no tiene la bendición de, oh, el gran jefe DHH; sin embargo resultó muy bueno para el proyecto.
SweepObserve va a ser liberado en breve.
Nota: a los dos días de haber bautizado al plugin con el nombre de AutoAdmin, otro de los programadores del proyecto me hizo saber que existía otro plugin para Rails con exactamente el mismo nombre y características terroríficamente similares. Aclaro que no sabía de la existencia de ese AutoAdmin cuando le puse un nombre tan poco imaginativo a mi plugin :)
Sabés que vamos a estar orgullosos de comentar el lanzamiento del plugin made in argentina :-) “Autobackend” ese no esta registrado aún
Usaron capistrano para deploy?
Sí. bq. Dado el setup de 6 servidores, el script de deployment para capistrano no es trivial. Además, usamos un servidor separado para ‘staging’ y la receta de deployment funciona para ambos entornos (production y staging). bq. De todo el stack de herramientas que se asocian a Rails, creo que capistrano es la que más se destaca por su calidad. Además de las recetas ‘default’ para el deployment de una aplicación Rails en un entorno típico, capistrano permite ejecutar remotamente cualquier tarea en un servidor Unix. Es una herramienta MUY flexible, bien documentada y eficiente.
Michel: Manuel es un cap-wizard, nos dejó boquiabiertos a todos.
Me imagino que el laburo mayor fue el backend, o me equivoco?
Personalmente disfruté más laburar en el backend. Quizás sea porque el frontend lo programamos en el último mes del proyecto, cuando ya estábamos todos quemados :). bq. El backend fue más uniforme, en el sentido de que programamos un conjunto de herramientas, librerías y elementos de interface que reutilizamos para implementar todas las funciones. En cambio en el frontend, cada página o sección nueva que encarábamos era una sorpresa que nos daba la gente que diseñó la gráfica y la interacción.
La anécdota graciosa del proyecto?
No tiene mucho que ver con el proyecto, pero nunca me voy a olvidar haber visto el 80-70 de Argentina-Francia en el mundial de básquet en el televisor que tenían los periodistas de Sport24.com, que trabajaban al lado nuestro.
Gracias por el tiempo y ayudar a difundir esta tecnologia que nos da tantas satisfaccciones a todos!
A los numeros:
Duracion del proyecto: 4 meses
Cantidad de desarrolladores: 4 (un francés, un franco-australiano y dos argentinos)
cantidad de requests/day: 1.000.000 a los servidores de aplicación (aproximadamente)
cantidad de modelos: 164
cantidad de vistas: ~400
cantidad de controllers: 114
