Mina de rubíes (uno)

Editor invitado Mariano “merunga” Crowe

Así como ya se ha dicho anteriormente, ruby on rails, es una tecnología que se basa en un lenguaje puro orientado a objetos (ruby), principalmente pensado para el desarrollo ágil de aplicaciones web, y en el fácil mantenimiento de éstas. Esto último íntimamente relacionado con la arquitectura MVC.

Programación Orientada a Objetos (POO)
Bien ahora por partes, que es aquello de POO? Bueno, es simplemente un paradigma de la programación, que fundamentalmente se basa en la interacción entre entidades, abstraídas éstas de terceros que las tengan que manipular.

Ellas solas se mandan mensajes, se preguntan cosas, se piden favores o directamente se dan órdenes, pudiendo cada una de ellas entender éstos mensajes o no.

Esta situación le da a cada uno de éstos personajes un papel específico, que nadie mejor que ellos puede llevar a cabo.

Y consecuencia inmediata de esto, es la capacidad de reutilizar estas entidades a lo largo del tiempo, incorporándoles o no cambios, haciéndolas evolucionar, convirtiéndolas en entes cada vez más poderosos y/o que tienen cada vez más lacayos para acatar sus designios, cada uno de éstos especializado en una tarea diminuta, que él/ella sabe hacer mejor que nadie Al mejor estilo Lemmings o Lost Vikings.

Lo que esto permite es una programación constructiva y evolutiva, intentando siempre que sea posible (o esa es mi firme creencia) evitar reprogramar from scratch, y arrancar de lo anterior como piso.

Ruby
OK, Ruby es un lenguaje puro orientado a objetos, pero que cuernos significa eso de que sea “puro”?

Esto quiere decir que absolutamente TODO dentro del mundo ruby es un objeto, uno de estos entes que tiene la capacidad de entender mensajes.

Por ejemplo, en los lenguajes orientados a objetos llamados “híbridos” (aquellos que están en la vereda de enfrente de los “puros”), es imposible preguntarle cosas a los tipos más primitivos (entiéndase por primitivos, a los todos los números, las letras, y las entidades lógicas -verdadero/falso-)

Por ejemplo
Aclaración: La notación del punto, implica que a la “persona” a la izquierda de él se le está enviando un mensaje (el texto que está a la derecha).
Lenguaje Híbrido:
Matemática.negar(1)
Lenguajes Puros (Ruby…)
1.niégate

Bueno, en ambos casos obtendríamos el número -1, pero en el primero, le estaríamos pidiendo a la matemática que niegue al número 1. En cambio, en el segundo caso, le estaríamos pidiendo al número 1 que lo haga por si solo, porque en Ruby, el puede, el tiene esa capacidad. Fácil, no?

Si, muy lindo todo, muy simpáticos los personajes, pero de que sirve? Puro fetiche? Algunos dirán que si, pero creo que la mayor y quizás única ventaja que tiene este enfoque, es que no existe diferencia entre los actores. Todos son manipulados de la misma manera, permitiendo un estilo de programación más cómodo, más coherente y principalmente más claro. Uno se encuentra con un código más fácil de desarrollar, menos extenso y ante todo más fácil de leer y, por lo tanto, de entender.

Y todo esto es fundamental, teniendo en cuenta los niveles de complicación a los que han llegado los problemas a resolver actualmente.

Ruby on Rails (intro)
¿Qué es exactamente Ruby on Rails? RoR es un framework específicamente orientado a la programación web (2.0), bajo la arquitectura MVC.

Framework?
Principalmente es un conjunto de elementos que ya realizan operaciones, (muchas) de aquellas que son generalmente necesarias y muy utilizadas. Esto lo que permite es que uno sólo tenga que encargarse de los comportamientos específicos de la aplicación que desarrolla, y no de los comportamientos que ésta comparte con el resto de las aplicaciones web del planeta (que a grandes rasgos siempre son las mismas).

Arquitectura MVC? (este pibe se está yendo al joraca)
Es una idea bastante antigua, pero que ha sido revalorada en la época de la Red. Se basa en ese concepto tan simple y que a esta altura verán que aparece recurrentemente, “repartir las tareas”.
Rápido y mal sería algo así como que el Modelo se encarga de manejar el estado de la aplicación (independientemente si esta es transitoria o persistente -en este último caso presisaríamos de algún medio de almacenamiento, el ejemplo más clásico sería una base de datos-).

La Vista sólo se encarga de facilitarle las cosas al usuario (o por lo menos así debería ser) y de mostrar la información, pero no la procesa, ya la recibe masticada.

Y por último el Controlador es el nexo entre los otros dos, en como el DT del equipo. La vista recibe una orden del usuario, le avisa al controlador, éste decide como va actuar, da la orden al modelo, este la procesa la, produce un resultado que por algún camino vuelve al punto de origen, la vista (según la flexibilidad con la que emplee el concepto, este último paso se puede realizar con el controlador como intermediario, o no). Y el círculo se cierra en el momento que el usuario ve esa información manifestarla. Y el ciclo comienza “wieder von vorne”.

Agile Web Development
Otro de los pilares del Rails es el concepto de Agile Web Development, que como su nombre permite intuir, contiene pautas que, EN TEORÍA, permitiría producir software a los niveles que se necesita actualmente. El agile manifesto (http://agilemanifesto.org/) cuenta con varios puntos, pero principalmente los que sigue Rails son los siguientes:

– Individuos e interacción, antes que procesos y herramientas.
– Priorizar software que camine a buena documentación y planeamiento.
– Colaboración del cliente (el interesado en el producto) en lugar de negociación y contratos.
– Evolucionar a los cambios en vez de seguir un plan.

Lo cual da una pauta, las cosas se tienen que hacer rápido y lo más flexibles posible. Y esto no solamente es una bandera, Rails se empapa de esto y da las herramientas como para que no sea solamente puro bla bla.

Para la próxima: Las funcionalidades específicas de RoR, Web 2.0 y un poco más de Agile Web Development y comparación de Ruby (y quizás algúna otra tecnología similar) con los métodos “que utilizaban nuestro padres” fundamentado principalmente por el hecho de que no se puede pretender desarrollar una nueva web, con las herramientas que fueron creadas para la vieja… y obviamente, algunas referencias históricas obligadas.