El pasado 6 de noviembre participé en una mesa redonda sobre frameworks en SIMO. Expertos en Drupal, Code Igniter, Zend Framework, .Net y Sun JSF expusieron su punto de vista sobre el estado del arte de los frameworks para desarrollo de aplicaciones web.

Yo por mi parte me encargué de explicar porqué hemos elegido Ruby on Rails como nuestra herramienta favorita para este tipo de proyectos. Podeis ver a continuación la explicación -más o menos fidedigna- que realicé en los 4 minutos de presentación que me correspondían.

Ruby on Rails es un framework para desarrollo de aplicaciones web escrito en el lenguaje de programación Ruby.

En ASPgems, donde todo el equipo tenemos experiencia en otros entornos sobre todo en proyectos grandes en el mundo corporativo, utilizamos Ruby on Rails porque nos permite desarrollar proyectos web de calidad en tiempos muy competitivos y usando metodologías de programación ágiles. Esto nos permite empezar a desarrollar un proyecto con un número mínimo de requisitos que sabemos que van a cambiar mucho durante la vida del proyecto, y que podemos aceptar cambios incluso en los días previos a la salida a producción sin que tengan un impacto significativo en la mayoría de los casos.

Encontramos varias ventajas en Rails sobre algunos otros frameworks. Por un lado, el lenguaje sobre el que se desarrolla, Ruby, es un lenguaje muy orientado a objetos, potente, y muy expresivo. Con pocas líneas de código puedo conseguir muchas cosas, con lo que la legibilidad del código es mayor y la probabilidad de errores se reduce.

Ruby on Rails, es un framework con opinión que se basa en el principio de “Convención sobre Configuración”, de forma que si yo utilizo las convenciones que el framework espera, Rails es capaz de hacer gran parte del trabajo por mí. En rails no hay que mantener ningún fichero XML para configuración de filtros, mapeos, validaciones o nada parecido. Además, al trabajar todo el mundo siguiendo las mismas convenciones, se puede incorporar gente a un proyecto en marcha o rotarla con un coste mínimo.

Otra gran ventaja de Rails, es la filosofía misma del framework. Rails está creado a partir de un proyecto real puesto en producción. Se desarrolló un proyecto web con Ruby siguiendo patrones de diseño estándar como MVC, Inversión de Control, Persistencia de Datos… y se vio que el proyecto funcionaba bien y que había varias partes reusables. Ese código reusable se extrajo para hacer un proyecto Open Source. Además, se le añadió un mecanismo de plugins para poder ampliar o modificar el comportamiento del framework de forma simple.

Como el código del framework es fácil de entender, y es sencillo crear un plugin, en seguida se consigue una comunidad de desarrolladores muy activa. Cuando un plugin se usa mucho dentro de la comunidad, se acaba incorporándo al núcleo del framework; y al contario, si una parte del framework no la usa casi nadie, se acaba sacando como plugin. Se puede seguir usando, pero no se mantiene dentro del framework, con lo que no se convierte en un framework monstruo donde cabe todo.

Debido a esto, tenemos un framework que está vivo y que se va modificando según los proyectos y las necesidades reales de la comunidad que lo usa en sus proyectos en producción.

El resultado es que, para una persona acostumbrada al desarrollo web, se puede desarrollar una aplicación completa con muy poco código. Te puedes centrar en la lógica de negocio y dejar muchos detalles de implementación al framework.

Esto choca con otros frameworks que están pensados en abstracto para cubrir cualquier caso posible, y acaban teniendo una arquitectura tan compleja que en muchos casos te da la impresión de que, más que desarrollar, estás luchando contra el framework.

Rails 2.0 está no muy lejos y nosotros vamos jugando ya con la pre-release o directamente Rails Edge. De hecho la conferencia de Javi en la Conferencia Rails Hispana sobre plugins incorporará novedades de la 2.0 sobre el tema, y la mía explicará las cosas sobre el código último. Tanto es así que los snippets de código de las slides se extraen en runtime de trunk.

Una de las funcionalidades nuevas que quise aplicar ipso facto fue rescue_from. La idea es que en un controlador puedes declarar handlers para excepciones:

rescue_from SomeException, :with => :some_action

De manera que si salta SomeException en una acción Rails llama al handler some_action.

Magnífico! Estamos desarrollando un web service RESTful donde esto viene de perlas, ya que en varios puntos del servicio se pueden lanzar excepciones acordadas para indicar errores y nos viene fenómeno poder manejarlas en un punto único. De saltar, lo que hay que hacer es responder al cliente con códigos 4xx o 5xx, según el caso.

Así que ahí estamos reescribiendo esa parte de la aplicación cuando me doy cuenta de que no funciona como esperaba: no se tenía en cuenta herencia de excepciones, y otros gotchas. Se registraba el nombre de la excepción en una tabla hash y luego se hacía un lookup por nombre. Útil, pero algo limitado.

Nosotros en esta aplicación tenemos una jerarquía de excepciones para tratar de ser específicos al reportar un problema, y lo interesante sería registrar un handler para la raíz de la jerarquía (cosa que emulábamos a mano con un rescue_action global al estilo pre-2.0). De otro modo habría que declarar un rescue_from por cada una de las excepciones, camino que tarde o temprano te conduce a un par de gelocatiles.

El rescue de Ruby se comporta de ese modo, de ahí que uno esperaría un comportamiento similar emulado. Además, sería deseable también poder expresar prioridades entre handlers y herencia de handlers.

Al core team le pareció en principio bien el planteamiento y sugirió alguna funcionalidad adicional, así que le hemos echado un par de cafés al tema y hemos enviado un parche que ya está en trunk.

Adelante!

7 reasons I switched back to PHP after 2 years on Rails - O’Reilly Ruby

Yo contestaría una por una con:

1. Esto ya lo sabíamos antes de cambiar a Ruby.
2. Como decimos a veces: “El mundo se pudo crear en 7 días porque no había base instalada”. También lo sabíamos antes de empezar.
3. Aunque algunos de nosotros conocen bien el core, no es mi caso, y tampoco pienso conocerlo. No es necesario conocer el core, y todo lo que no usas no molesta, aunque si algo no se usa siempre habrá que quitarlo.
4. Nuestras máquinas no son superordenadores. Y van estupendamente bien.
5. Yo también tengo mis gustos, pero prefiero confiar en el trabajo de un grupo de expertos que han encontrado una buena manera de hacer las cosas. Además trabajando en equipo mejor tener una forma de hacer las cosas y no varias.
6. Púes yo prefiero no usar SQL a no ser que sea imprescindible. Yo no pienso en tablas, pienso en objetos.
7. Sobre esto no puedo opinar, y o llevo con mi mujer desde hace mas de 20 años :-).

Yo creo que el artículo no es demasiado profundo, aunque si creo que hará ruido.

Hoy se está lanzando MiRubi.com la web que te paga por navegar.

Es un proyecto que hemos desarrollado en ASPgems, es para nosotros un claro exponente de los principios y tecnologías de desarrollo de software que defendemos porque:

• Está hecho con Ruby on Rails.
• Ha sido un desarrollo ágil, y muy basado en SCRUMgem.
• Es “menos es mas” ha sido una dura lucha en el diseño y la concepción para no poner todo lo que se nos ocurría.
• El tiempo de desarrollo no ha sufrido desviaciones sobre el previsto.

Yo creo que es un claro ejemplo de las cosas que la tecnología hace hoy posible.

Mucha suerte para MiRubi.com.

Este post es de DanimataOnRails: PDA y rails

Es el resultado de uno de nuestros proyectos.

My 2 cents es una expresion americana que ha sido recogida en la comundiad del software libre, para reflejar, que esta es posble gracias a pequeñas contribuciones de muchos.Javier Ramirez ha aportado los primeros dos centavos de ASPgems a Rails en http://dev.rubyonrails.org/ticket/3735

UN pequeño paso para la humanidad, pero importante para nosotros ;-)

Cerrado registro para estudiantes
No creiamos que ibamos a llegar, pero igual hasta no hay luego ni sitio.

Por cierto lo mejor de todo está siendo la experiencia de organziar esto, con el apoyo de unos pocos voluntarios.

En ASPgems estamos ayudando a la organización de la ConferenciaRails 2006

Hoy se ha abierto el plazo de inscripción. Promete ser un evento lleno de gente.

No están todos los que son y probablemente alguno está y no debería pero amén del discurso cara a cara, y que cada día tenemos mejor estructurado a los amigos que nos preguntan que hacemos yo les paso esta lista de links:

• 37signals
• Signal Vs. Noise
• Vitamin
• Rails
• Script.aculo.us (imprescindible).
• csszengarden

Algunas cosas que molan:

• Netvibes
• Wridea
• Writely
• Freshbooks

En España:

• the-cocktail

Y para ver Un video Web 2.0 y La paradoja de la elección dos videos sensacionales.

Como hoy ya van dos veces que lo mando, pues he decidio subirlo al blog.