Curso de Ruby on Rails - 1ª parte

De todos los compendios de lenguajes de programación empleados por los sitios más punteros, el Ruby on Rails se manifiesta como la favorita por mayoría por desarrolladores y webmasters. Esta compilación es una de las más completas y versátiles

Redacción

Curso de Ruby on Rails - 1ª parte

26 noviembre 2007

Paso 1

El rubí que llegó en monorraíl

A nadie que esté medianamente al día en el entorno del desarrollo web se le escapa el hecho de que en los últimos dos o tres años se ha establecido una clara tendencia en el uso masivo de frameworks para desarrollar aplicaciones. Con ello, se pretende establecer esquemas de trabajo basados en patrones de programación y normas que, en la práctica, conducen al aprovechamiento del tiempo, optimización de las tareas y la perdurabilidad y escalabilidad de las aplicaciones.

A lo largo de las próximas cuatro entregas de este curso, intentaré explicar el porqué de esta fiebre por los frameworks y qué pueden aportar a un desarrollador que nunca ha trabajado con ellos y está en la tesitura de emprender una migración hacia una web menos estática y con más posibilidades de interacción con el cibernauta y de migración a otras plataformas móviles.

Paso 2

Programando en la oscuridad

Para todos los programadores que en su día decidimos cruzar el umbral que separa las aplicaciones de escritorio de las aplicaciones web, el primer handicap que nos encontrábamos era la nada milagrosa multiplicación de lenguajes y metalenguajes que teníamos que comenzar a manejar: uno de servidor (PHP, Perl, Python, Java...), otro de acceso a bases de datos (SQL), otro de hipertexto (HTML), otro ejecutable en el cliente (JavaScript) y, con el tiempo, uno de maquetación (CSS).

A este babeliano panorama, se le sumaba la dramática dificultad extra de la compatibilidad entre distintos navegadores de los tres últimos lenguajes citados (clamorosamente antipopular y kafkiana es la disidencia de los estándares de Internet Explorer).

Normalmente esta situación se resolvía separando las tareas en dos vertientes de programación que se vinieron a denominar programadores de backend y de frontend. Los primeros cubrían los aspectos de programación del código de servidor y los segundos se ocupaban de toda la parte de maquetación y diseño web, ya que el diseño gráfico de los interfaces lo podía ejecutar un tercer perfil de naturaleza no técnica.

Este esquema de trabajo, aparentemente simple en la teoría, se hacía algo más complejo en la práctica salvo que hubiese una gran compenetración entre los dos perfiles mencionados, y esto no era especialmente frecuente.

Si el escenario no parecía el óptimo desde un punto de vista técnico, AJAX no ha venido sino a hacer las cosas más difíciles aportando un poco más de entropía y complejidad a las arquitecturas de las aplicaciones web. AJAX, aparte de unas archiconocidas siglas (Asyncronous JavaScript and XML), es sólo una combinación de tecnologías bien extendidas que, debidamente combinadas entre sí y gracias al objeto DOM, que actualmente incorporan como tal todos los navegadores punteros del mercado, permiten modificar el HTML que forman las páginas web de forma parcial, extendiendo la interacción tradicional con un documento web, antaño limitada a la dualidad clic/carga de página.

Paso 3

Un poco de luz en el camino

Una vez quedan claras las razones que nos hacen entender por qué la irrupción de los frameworks ha sido acogida con tanta euforia por el entorno del desarrollo web, el siguiente paso lógico es explicar de qué forma éstos intentan satisfacer las no pocas necesidades que un desarrollador agradecería que le solucionasen.

En líneas generales, estos moldes se ciñen a una filosofía extremadamente pragmática de trabajo, intentando evitar las tareas reiteradas, dando soluciones a problemáticas que se presentan de forma repetida cada vez que desarrollamos una aplicación web y minimizando las posibilidades de incurrir en errores o despistes de esos que tanto cuesta localizar a posteriori.

Dicha filosofía, si bien acota las posibilidades de desarrollo a un subconjunto de casuísticas y necesidades, es una practiquísima solución para dichos casos, y éste era exactamente el objetivo perseguido.
En esta primera entrega vamos a definir, por tanto, una lista de características bastante generales, pero que resulten comunes a la mayoría de los frameworks, para poder hacernos una idea más concreta de qué tipo de ventajas aportan en la práctica.

Paso 4

Convención

Ésta es una de las palabras clave, ya que incide directamente sobre la filosofía de trabajo a la que estamos acostumbrados. Mediante una generosa colección de convenciones, podemos asumir que el framework resuelva decisiones que tendríamos que tomar nosotros, con la consiguiente pérdida de tiempo y probable error en muchos casos.

Un ejemplo muy claro y extendido entre los frameworks es la propia arquitectura de la aplicación y la definición de sus capas y estructuración. Esto, que podría ser un quebradero de cabeza para alguien con no demasiada experiencia en el desarrollo de aplicaciones web, la práctica totalidad de los frameworks lo resuelven apostando por un patrón MVC (Model-View-Controller).

Estas convenciones no sólo se quedan en un nivel conceptual, sino que se acercan mucho más a los aspectos terrenales de la programación, como es la propia nomenclatura de casi todos los actores que intervienen en la aplicación: tablas, modelos, controladores, vistas e incluso clases y métodos, amén de la propia sintaxis.

Paso 5

Modularidad

Esto no es nada nuevo, cierto; desde tiempos inmemoriales los desarrolladores hemos intentado separar las distintas partes de nuestras aplicaciones agrupándolas en librerías, componentes, clases, etc. con una funcionalidad determinada: el arte de abstraer, vamos. Quizá la novedad es que ahora esa separación funcional nos viene preconcebida y con unas habitualmente extensas colecciones de librerías muy bien pensadas para la ocasión. Es decir, además de la propia modulación, contamos con buena parte del trabajo hecho gracias a estas librerías que se suelen agrupar en función del ámbito de la aplicación que resuelven.

Entre los componentes más frecuentes que los frameworks ponen a disposición del desarrollador encontramos los de abstracción de acceso datos persistentes (mediante DataObjects o Registros Activos, que en los frameworks más avanzados pueden incluir los muy llamativos Scaffoldings), los de enrutamiento de peticiones o gestores de controladores y acciones, los de generación de código de marcado en las vistas (frecuentemente denominados Helpers) y, ya en casos más actuales, los encapsuladores de WebServices o APIs (tanto para incorporar una API a tu aplicación como para utilizar las de otros servicios) y los Generadores de JavaScript que tan útiles resultan para introducir AJAX en nuestras aplicaciones.

Paso 6

Homogeneización sintáctica

Algunos lenguajes se pueden «evitar» con unas buenas librerías que nos abstraigan de escribirlos directamente. Por ejemplo, el SQL se puede generar automáticamente a través de las numerosas librerías que transforman las estructuras tabulares en objetos de datos (especialmente conocidos y cómodos los Active Records), el HTML se puede también generar mediante colecciones de Helpers que reemplazan el lenguaje de marcado por funciones muy simples que lo escriben por ti, y lo mismo ocurre con el JavaScript y los JavaScript Generators, que traducen un lenguaje de servidor al citado lenguaje ejecutable en el navegador.

Los dos últimos casos tienen la ventaja añadida de que el código, tanto de marcado como ejecutable, será estándar y válido para todos los navegadores.

Paso 7

Gestión de múltiples entornos y herramientas de testing

Lo primero consiste en poder trabajar con entornos de desarrollo, pruebas y producción de la forma más sencilla posible, y sin para ello tener que replicar constantemente la plataforma en diversos servidores. Los frameworks, en la mayoría de los casos, dan soporte multientorno a través de una sencilla configuración de enviroments.

Respecto a las herramientas de testing, suponen una excelente forma de evitar problemas de escalabilidad de una aplicación o afrontar refactorizaciones con ciertas garantías de que no te volverás loco buscando los ilocalizables errores encadenados.

Los tests son comprobaciones en forma de expresiones lógicas de código, que deben cumplirse siempre para poder considerar que tu aplicación es consistente y está funcionando de forma adecuada. Huelga decir que la propia conceptualización y programación de estos tests corre de nuestra cuenta, pero un esfuerzo extra en este sentido, se verá recompensado con la infalibilidad de nuestro código.

Paso 8

Internacionalización y localización

Casi todos los frameworks se han esforzado en facilitar tan frecuente tarea a los programadores. Si necesitamos una aplicación multilenguaje y adaptada a localismos tales como divisas, medidas, formatos de fecha y hora, etc., en casi cualquier caso podremos contar con algún soporte nativo ofrecido desde el propio framework.

Si bien es cierto que no son excesivamente novedosas respecto a las ya anteriormente existentes, y probablemente conocidas por muchos desarrolladores.

Paso 9

¿Qué framework elegir entonces?

Ante la abundante y creciente oferta de opciones, vamos a comentar algunas de las variables que deberíais tener en cuenta para hacer una elección si no contáis con experiencia previa alguna.
Es evidente que una variable muy importante a la hora de elegir un framework es el lenguaje de programación en el que éste se apoya. Sin embargo, resulta paradójico que el que al menos inicialmente se ha llevado todos los honores en cuanto a reconocimiento como modelo a seguir por los demás, el archiconocido Ruby on Rails, se basase en un lenguaje totalmente desconocido como Ruby (creado allá por los mediados años 90 por el japonés Yukihiro Matsumoto), obviando lenguajes mucho más extendidos y populares como Java o PHP u otros más cercanos a Ruby filosóficamente, como Perl o Python.

El mediático creador de Rails de apellidos impronunciables David Heinemeier Hansson, de origen danés, siempre ha justificado esta decisión basándose en necesidades de dinamismo en el lenguaje y el tratamiento de los objetos para poder concebir su framework de forma óptima. Profundizaremos en esto en entregas futuras.

Lo cierto es que a pesar del notorio liderazgo de Ruby on Rails de la carrera de los frameworks (la comparativa del gráfico nos da una idea objetiva de que llega casi al 44% de las webs más visitadas), hay una buena gama de posibilidades para aquellos que no están dispuestos a tirar por la borda años de experiencia con otro lenguaje de programación.

En este sentido, y dado que profundizar en el análisis de la generosa oferta de frameworks que existen ahora mismo escapa a mis posibilidades y al objetivo de este mini curso, me limitaré a hacer una somera comparativa de funcionalidades básicas en la tabla adjunta (que podéis descargar en PDF).

He intentado separar en dicha tabla los frameworks realmente representativos de los que han proliferado como setas en una auténtica fiebre, por ello no he incluido J2EE y toda la pléyade de frameworks comerciales para Java, por estimarlos anteriores y bastante al margen del movimiento que pretendemos abordar. En el próximo capítulo, abandonamos la teoría y nos centraremos en un caso real.

Paso 10

Direcciones de interés

Apache Struts: http://struts.apache.org/

CakePHP: http://cakephp.org/

Catalyst: http://www.catalystframework.org/

Django: http://django.com/

Ruby on Rails (en castellano): http://rubyonrails.org.es/

Seaside: http://www.seaside.st/

Symfony: http://symfony-project.com/

TurboGears: http://turbogears.org/

ZEND Framework: http://framework.zend.com/