ORM, el moshito de Ruby on Rails…

La manera “tradicional” si queremos verlo asi para desarrollar aplicaciones es separar las diferentes capas existentes dentro del modelo planteado para la solución, una que maneje la lógica del negocio, otra que maneje la interacción con los datos almacenados…en fin…a la larga conforme la aplicación crece empiezan a surgir problemas, que si bien pueden resolverse mediante técnicas de SQL y programación pueden convertirse en tediosas y poco eficientes para los desarrolladores.

Pongamos un ejemplo sencillo, supongamos que tenemos una pequeña aplicación que maneja el impuesto que debe ser calculado sobre datos almacenados en alguna entidad en particular. Si se nos dice que ahora tenemos que almacenar en la entidad a que hora y en que fecha el impuesto fue calculado pues lo más lógico es que agreguemos una columna en la entidad que va a ser afectada y luego agregar el contenido de dicha columna dentro del loop del update. Hasta alli todos felices y contentos, la aplicación funciona, el gerente tiene lo que se le pidió y nadie es despedido. PERO….que pasa si dicha fecha y hora del cálculo del impuesto debe ser almacenado en múltiples entidades? y no vayamos al simple hecho de que todas estén en la misma base de datos, ya que puede haber replicación de datos en múltiples bases de datos, tendriamos que revisar todo el modelo de base de datos para poder ver en cuales la nueva columna “fecha y hora de calculo de impuesto” debe ser agregada, si olvidamos alguna entidad…nada bueno nos espera….lo más probable es que nos digan…”mm, sabe que!!!…sabe que!!!!…honestamente!!!!….(omito las palabras obsenas) :D

Una de las ideas que surge para solucionar dicho problema es el encapsulamiento, teniendo todo en una clase y simplemente actualizarla cuando las regulaciones cambian. Pues los tipos éstos, siii..los que se dedican a las bases de datos extendieron este concepto, la idea es realmente simple pero infinitamente funcional: manejar el acceso a la base de datos a través de una capa de clases. El resto de nuestra aplicación interactúa con éstas clases, nunca con la información almacenada directamente.

La implementación de éste concepto en la vida real es un poco más complejo, ya que como en el ejemplo anterior…las bases de datos están relacionadas, y lidiar con problemas de consistencia y rendimiento pueden convertirse en un reto. Acá es donde entra Ruby on Rails al rescate, ya que utiliza el Object Relational Mapping (Mapeo de objetos-cositas relacionales).

Mmmm….pero aun no me has dicho que hace ORM….

ORM básicamente mapea tablas que se encuentran en la base de datos en clases, por ejemplo si tenemos una tabla que se llama “patito”, las librerias de ORM crearán la clase “patito”. Las filas que se encuentran en nuestra tabla son mapeadas a objetos, todas las columnas de cada tupla se convierten en atributos del objeto creado.

Genial, no!!!!?….(emotion de deditos)….pero Rails va mucho más allá de eso, ya que provee métodos que operan sobre las tablas, como el siguiente:

Order.find(:all, :conditions => “name=’dave’” ).each do |order|
order.discount = 0.5
order.save
end

Encuentra todas las ordenes en donde el nombre sea “dave”, aplica para cada registro un descuento y almacena nuevamente el registro.

Object Relational Mapping
Object Relational Mapping

Chilero, y como hace todo eso que dices?…

Rails utiliza la tecnología Active Record para poder lograr sus objetivos. En futuras actualizaciones de éste sitio seguiremos viendo su funcionamiento.

Hay mucha y entiéndase mucha tela que cortar cuando hablamos de ORM, también pueden ver la herramienta Hiberante acá: http://www.hibernate.org/ hasta una próxima ocasión, Saludos. (^_^)

oye amigo…¿por que utilizar Ruby on Rails?

rails_logo2Ruby on Rails nace como un framework de desarrollo web especialmente diseñado con un fin en especifico, hacer la vida más fácil a las personas que desarrollan aplicaciones para la gran red.

Muchas de estas personas quiza se sientan frustradas con tecnologias como PHP, Java, o .NET que si bien son buenas conllevan problemas de carga de recursos y una complejidad innecesaria. Ruby on Rails es simplemente más facil.

Ruby on Rails utiliza la arquitectura de MVC para poder administrar sus recursos, si bien Java utiliza utiliza frameworks como Tapestry o Struts basados en MVC, Ruby on Rails lleva el concepto mucho mas allá debido a que hay un lugar específico para cada parte del codigo y cada componente de nuestra aplicación funciona de manera estándar, es como si empezaramos una aplicacion con el esqueleto previamente ya armado.

El uso de Rails conlleva a escribir menos código, también es óptimo para la realización de pruebas ya que el framework provee componentes para pruebas de funcionalidad.

mmm….que bonito pero….que lenguaje utiliza?

Rails utiliza el lenguaje orientado a objetos llamado Ruby, este framework explota las capacidades del lenguaje haciendolo flexible, fácil de entender,escribir y modificar, como dice el mismo creador de Ruby: “el propósito de la vida es al menos en parte, ser feliz”…y eso es lo que busca Ruby programar de tal manera que disfrutemos haciéndolo, dandonos como herramientas todo lo que necesitamos para desarrollar aplicaciones de cualquier tipo.

La forma de trabajar de Ruby es simple, limpia y ordenada, aca tenemos un ejemplo de una pequeña clase:

class patito

def tiene_patitos

puts “quack!”

end

end

El diseño de Rails fue contruido sobre dos conceptos clave, uno denominado DRY “Don’t Repeat Yourself” que básicamente expresa que cada pieza del conocimiento aplicado a un sistema debe ser expresada en un solo lugar, Rails utiliza Ruby para poder lograr dicho fin.

La segunda es “Convencion sobre Configuración”, significa que Rails tiene sensibilidad por default para el manejo de cada recurso de nuestra aplicacion, esto se reduce en escribir menos codigo que en una aplicacion Java tradicional.

Rails es Agil

Ser ágil es una de las primisas de Rails, es una tecnología que está siempre evolucionando hacia el desarrollo de aplicaciones cada vez más robustas pero manteniendo siempre la facilidad que caracteriza a este maravilloso framework.

Rails se basa principalmente en individuos y la interacción entre ellos, no se requieren pesadas herramientas de codificación, configuraciones complicadas ni tampoco procesos elaborados. Solo tenemos algunos grupos de desarrolladores, algunos cuantos editores y trozos de código Ruby. Todo esto conlleva a la transparencia; lo que los desarrolladores hacen se ve reflejado inmediatamente en lo que los usuarios ven, es intrínsecamente un proceso interactivo.

El concepto DRY mencionado anteriormente ayuda en el hecho de que los cambios en aplicaciones de Rails afectan a mucho menos código que en otros frameworks. Todos los cambios que se realicen sobre la aplicación son fácilmente manejados ya que el código Ruby permite una facilidad sin precedentes sobre los diferentes elementos presentes.

Encontrando nuestro camino…

Durante el desarrollo de este pequeño tutorial en linea de Rails, veremos secciones de código, como el que aparece a continuación:

class rails

….codigo Ruby….

end

Tambien encontrarás tips y consejos para poder desarrollar aplicaciones robustas de manera divertida con este framework tan fácil e interesante.

La version de Rails que tenemos disponible es la 2.2.2 pero estaremos pendientes a cualquier versión o patch lanzado, puedes descargar Rails de esta página: http://rubyonrails.org/download

En proximas actualizaciones de este sitio estaremos publicando la instalación tanto en sistemas Linux, en particular Gentoo 2008.0 Kubuntu 8.10 como bajo plataforma Microsoft Windows.

ruby-slogan

Ya quiero empezar!!!

Entonces hagamos el famoso “Hola Mundo!!!” …

puts “Hello World!”

Y donde esta el “main”!!!! tan facil es Ruby que tan solo con esta linea de codigo ya esta hecho nuestro hola mundo!
Rayos!!

Y quien invento Ruby?? en que esta hecho??
Ruby es un lenguaje con un balance cuidado. Su creador, Yukihiro “matz” Matsumoto, mezcló partes de sus lenguajes favoritos (Perl, Smalltalk, Eiffel, Ada, y Lisp) para formar un nuevo lenguaje que incorporara tanto la programación funcional como la programación imperativa.

chinito

A menudo ha manifestado que está “tratando de hacer que Ruby sea natural, no simple”, de una forma que se asemeje a la vida real.
Continuando sobre esto, agrega:
Ruby es simple en apariencia, pero complejo por dentro, como el cuerpo humano.
mmmm!!!

Aja y ademas Ruby esta creciendo! :-D
Desde su liberación pública en 1995, Ruby ha atraído devotos desarrolladores de todo el mundo. En el 2006, Ruby alcanzó reconocimiento masivo, formándose grupos de usuarios activos en las ciudades más importantes del mundo y llenando las capacidades de las conferencias relacionadas a Ruby.

Hablemos de Ruby

En Ruby todo es un objeto
La programación orientada a objetos llama a las propiedades variables de instancia y las acciones son conocidas como métodos. La orientación a objetos pura de Ruby se suele demostrar con un simple código que aplica una acción a un número.

5.times { print “Nos *encanta* Ruby — ¡es fuera de serie!” }

En muchos lenguajes, los números y otros tipos primitivos no son objetos. Ruby sigue la influencia del lenguaje Smalltalk pudiendo poner métodos y variables de instancia a todos sus tipos de datos. Esto facilita el uso de Ruby, porque las reglas que se aplican a los objetos son aplicables a todo Ruby.

Es un lenguaje flexible por que permite a sus usuarios alterarlo libremente
Las partes esenciales de Ruby pueden ser quitadas o redefinidas a placer. Se puede agregar funcionalidad a partes ya existentes. Ruby intenta no restringir al desarrollador.

Los bloques de Ruby son también vistos como una fuente de gran flexibilidad. El desarrollador puede anexar una cláusula a cualquier método, describiendo cómo debe actuar.
A diferencia de otros lenguajes de programación orientada a objetos, Ruby se caracteriza por su intencional herencia simple.

Yo quiero probar!!!

Pues si quieres probar antes de descargarlo a ver si te gusta o no, puedes probarlo desde tu navegador y asi tambien aprender un poco mas acerca del lenguaje y veras lo facil que es!!!
Va ya ya!

ruby_2

Y donde lo descargo o q?
Lo puedes descargar de la pagina principal
http://www.ruby-lang.org/es/downloads/

Y si quiero documentacion y eso??
http://www.ruby-lang.org/es/documentation/

Iníciate, ¡es fácil!

download

Arquitectura de Ruby on Rails

Ahi por el año de 1979 surgió una arquitectura para el desarrollo de aplicaciones interactivas, en este diseño las aplicaciones fueron divididas en Modelos, Vistas y Controladores.

El Modelo es el responsable de mantener el ESTADO de la aplicación. Algunas veces éste estado no es relevante, pero algunas veces es permanente y será almacenado fuera de la aplicación, regularmente en la base de datos.

Un modelo es más que simplemente datos; refuerza todas las reglas del negocio que son aplicables a los datos. Por ejemplo, si un descuento no debe realizarse a ordenes menores de Q50.00, el modelo debe reforzar la restricción. Ésto es lo que le da sentido al modelo, poniendo la implementacion de éstas políticas de negocio en el modelo, nos aseguramos que nada en la aplicación pueda hacer nuestros datos inválidos. El modelo actúa como el Guardián y almacén de datos.

La vista es la responsable de generar las interfaces para los usuarios, normalmente basadas en datos contenidos en el modelo. Por ejemplo, una tienda en línea quiere tener una lista de productos y desea que dicha lista sea desplegada en la pantalla. Esta lista será accesible desde el modelo, pero será una vista la que acceda al modelo y le dé formato para el usuario final. La vista puede proveer al usuario con diferentes tipos de datos de entrada, PERO no maneja por si misma los datos entrantes. El trabajo de la vista termina cuando la información es desplegada con éxito.

Pueden haber varias vistas que accedan al mismo modelo de datos, en ocasiones por diferentes propósitos. En la tienda en línea puede que hayan vistas tanto para desplegar listados de productos como aquellas que son utilizadas por los administradores para editar y agregar nuevos productos.

El tercer componente son los controladores, éstos son los que “armonizan” la sincronización de todos los componentes, reciben eventos del mundo exterior, interactúan con el modelo y despliegan la vista que corresponde a los usuarios.

mvc2

Este modelo fue originalmente creado para aplicaciones GUI tradicionales, donde los desarrolladores encontraban que la separación de componentes hacia la codificación más fácil, tanto para escribir como para mantener. Cada concepto o acción fue expresada EN UN MISMO LUGAR.

Rails también utiliza este modelo. Refuerza la estructura de nuestra aplicación, desarrollamos modelos, vistas y controladores como partes separadas de funcionalidad y se unen cuando nuestro programa se ejecuta. Una de las cosas mas divertidas de Rails es que la unión de todos los componentes está basada en el uso de estándares inteligentes asi que no debemos preocuparnos por configuración externa ni nada por el estilo. Este es un ejemplo de la filosofía de Rails “Convención sobre la configuración”.

En una aplicación de Rails, las peticiones entrantes son enviadas como primer paso hacia el router, que trabaja fuera de donde se hizo la petición y de donde dicha petición debió ser parseada. Esta accion define un metodo en particular (llamado accion en la jerga de Rails), en algun lugar del controlador.

La accion podria pedir ver datos en la petición misma, podría interactuar con el modelo, y podría hacer que otras acciones fueran invocadas. Eventualmente la acción prepara la información para la vista, que renderiza algo para el usuario final.

En la figura anterior se ve como Rails maneja una petición entrante. En ese ejemplo un catalogo de productos es mostrado, el usuario ha dado clic en el boton “agregar al carrito de compras” al lado de uno de los productos, dicho boton esta asociado a una acción en nuestra aplicación manejada de manera interna,claro.

El componente de ruteo recive la petición entrante e inmediatamente la hace pedazitos. En este caso sencillo, toma la primera parte del path, “store” como nombre del controlador y la segunda parte “agregar_carrito” como el nombre de la acción. Como resultado del análisis el router sabe que debe invocar al metodo “agregar_carrito” en el controlador llamado “StoreController”.

El metodo “agregar_carrito” maneja las peticiones de los usuarios. En este caso encuentra el carrito de compras del usuario en cuestión (que es un objeto manejado por el modelo). También pregunta al modelo en donde se encuentra la información del producto deseado. Luego le dice al carrito de compras que agregue dicho producto asi mismo. Nótese como el modelo es usado para mantener el seguimiento de todos los datos del negocio, el controlador dice QUE hacer, el modelo sabe COMO hacerlo :P

Ahora que el carrito incluye el nuevo producto, podemos mostrarlo al usuario utilizando una vista. El controlador arregla las cosas de tal forma que la vista tenga acceso al objeto dentro del carrito obtenido del modelo, y luego invoca al código de la vista. En Rails esta invocación es muchas veces implícita.

Y eso es básicamente MVC, descubriremos que utilizarlo hará que nuestras aplicaciones sean fáciles de extender y mantener. Se ve bien :P ….al menos yo lo haría….

MVC no es más que particionar nuestro código de una manera en particular, aca es en donde viene el chiste de Rails, Rails se encargará de mantener la coordinación entre los direfentes componentes de ésta arquitectura, a través de archivos de configuración y control.

Mapeo Objetos Relacionales

Una de las fuentes del poder de Ruby on Rails, pero esa…es otra historia…

Nos vemos en una siguiente oportunidad…Vivi y Many (^_^)