Fixem

El segundo día mi serie de posts sobre mi aprendizaje de Rails empezó con el Capítulo 4 del libro “Agile Web Development With Ruby on Rails: Second Edition“. Para este capítulo el libro prometía crear una aplicación sencilla de demostración llamada simplemente “demo”. De manera más puntual, estas fueron mis impresiones…

• Creamos la aplicación a través de la línea de comando. Con simplemente escribir “rails nombre_aplicación” en la raíz del servidor, bastó para que Rails automágicamente generara el esqueleto de la aplicación, incluyendo estructura y archivos de configuración básicos. Buen comienzo que ahorra bastante tiempo en 1) crear cada uno de estos archivos manualmete y 2) pensar en la estructura de tus aplicaciones si no te has definido estándares (y aún así uno siempre busca mejorarlos cada vez que se empieza un proyecto nuevo)
• A través del comando “ruby script/server” en la raíz de tu proyecto nuevo, inicias un servidor WEBrick, el cuál trae una cónsola que hace trazas completas a todo lo que se esté ejecutando en la aplicación, ¡perfecto para debuggear! No más problemas con SQL’s extraños. Siempre quise algo así con PHP…
• Creamos nuestro primer controlador con el comando “ruby script/generate controller Nombre_Controlador“. Esto genera la estructura de carpetas y archivos necesarias para el funcionamiento del controlador. Lo interesante aquí es que Rails tiene su propia estandarización de nombre para todo, por ejemplo, si llamas a un controlador “Hola”, Rails automáticamente creará las clases HolaController que heredará las propiedades de la clase ApplicationController, las Vistas, los Helpers (métodos que ayudan a estandarizar funciones que generan HTML en las Vistas). Todo esto viene ya listo para simplemente crear nuestra lógica de negocios, sin preocuparnos por errores de nombramiento, herencias, enrutamientos, etc., en sus carpetas respectivas. Menos esfuerzo en determinar nombre y rutas de archivo = ahorro de tiempo = una maravilla.
• Nos explican la manera de Rails de manejar los URL’s. Básicamente todo lo que venga luego de la raíz del servidor es un controlador, y lo que venga después del controlador es una acción, es decir: http://urlejemplo.com/controlador/accion. Ejemplo: http://tiendaejemplo.com/productos/mostrar. En este ejemplo el controlador sería Productos y Mostrar la acción (mostrar la lista de todos los productos). Un controlador puede tener muchas acciones, siguiendo este ejemplo, el controlador Productos puede tener las acciones Mostrar, Agregar (agrega al carrito de compras), Detalle (muestra el detalle de un producto en específico), etc. Esta es, a la final, la manera cómo el navegador (y el usuario final) hace peticiones al sistema: pide un controlador y una acción del mismo. Así que hay que empezar a pensar con esa mentalidad.
• Creamos un controlador de ejemplo llamado “Say” (decir) con su acción “Hello” (hola) y nos pide entonces crear la Vista correspondiente para esa acción, que en pocas palabras será el HTML que muestre en el navegador todo aquello que queramos desplegar. La ruta predefinida de esa vista está en /app/views/say/hello.rhtml (noten que el archivo se debe llamar igual que la acción del controlador). Estos HTML pueden ser dinámicos, y para ello existen 2 técnicas: “Builder Templates”, para la cuál no entramos en detalles aún, y ERb, que es simplemente embebir código Ruby en los .rhtml, como se pueda hacer con PHP y JSP tradicional, entre los tags < %= %>. Es importante destacar que las Vistas heredan perfectamente las propiedades de los Controladores, de manera que si yo creo una variable en un Controlador, la puedo acceder en las Vistas correspondientes. Esto nos permitirá la gran ventaja de separar la capa de lógica de la presentación, y es imperativo mantenerlo siempre en cuenta, ya que de esto se trata el MVC y nos dará mayor flexibilidad al hacer actualizaciones futuras de código, especialmente si trabajamos el proyecto en un equipo. Todo tiene su lugar, es fácil de entender, debuggear y no hay necesidad de repetir el mismo código en distintas partes de nuestra aplicación.
• Nos muestran la manera de hacer links entre páginas. Si bien podríamos hacer los links convencionales con la etiqueta HTML respectiva, Rails trae un helper llamado “link_to” que no rompería los links si por alguna razón decidimos cambiar la estructura de URL’s de un site (por ejemplo, meter toda la aplicación en una carpeta). Ejemplo de uso: < %= link_to "Hola!", :action => “hello” %>, dónde “Hola!” es lo que se mostrará en el enlace y :action => "hello" es la acción que ejecutará del controlador.

Esto fué todo para el capítulo 4. Aprendimos de manera muy básica como hacer las cosas en Rails, como estructurar archivos, carpetas y trabajar con controladores y vistas. Éste quizá sea el cambio de paradigma más grande que pueda tener alguien que venga de PHP o Java tradicional, y les aseguro con toda firmeza que es para mejor. La facilidad de trabajar los proyectos de esta manera no tiene precio. Hasta ahora Rails sólo me ha dado entender que hubo mucho trabajo de ingenio y mucha experiencia detrás del framework, para llegar a este punto. Se siente bastante pulido.

No hay que olvidar la belleza de un lenguaje como Ruby. Ejemplos: < % 3.times do %> repite una acción 3 veces, < % 3.downto(1) %> cuenta en reversa de 3 a 1, < % Time.now %> de la hora actual, y mi favorito hasta ahora: < % 1.hour.from_now %> te da la hora dentro de una hora. Y esto imagino que sólo es la punta del iceberg. ¡No puedo esperar aprender más!

El siguiente capítulo va directo al grano y nos enseñará a hacer una aplicación de la vida real. Haremos un carrito de compras, por supuesto incluyendo base de datos.

Keep on railing!

Yo soy uno de esos que siempre llega tarde con las tendencias (y como “para muestra un botón”, ver las fechas de aquí y aquí).

Desde hace ya-no-se-cuanto-tiempo he seguido la noticia que rodea a Ruby on Rails, y por esa misma cantidad de tiempo lo he evitado. No porque nunca creí que fuera bueno, si no porque nunca tuve la necesidad de cambiar a mi querido PHP. A ver si me explico…

Mi Historia

Como muchos desarrolladores, con la ayuda de un amigo me inventé mis propias librerías en PHP que me facilitaran la vida. Obviamente estaban hechas a mi medida y con millones de hacks y parches que sólo yo conocía, y las utilizaba para cualquier proyecto freelance que me saliera.

Luego entré a trabajar para otros. Obviamente ahí mis librerías no iban a funcionar, así que empecé a investigar más a fondo las bondades de Rails y cómo llevarlas a PHP. Me familiaricé entonces con el modelo MVC (el cual ya venía escuchando desde que investigué sobre Struts cuando trabajaba con Java) y me pareció una maravilla, pero aún me empeñaba en hacerlo en PHP. Encontré CakePHP, Symphony, Prado, QCodo y finalmente seguí con atención la evolución del Zend Framework desde su primer beta, cuyo objetivo primordial era llevar la filosofía de Rails a PHP. Ninguno me terminó de convencer, había algo en PHP que no lo hacía como la gente decía que era Rails. Sin embargo, no es el objetivo de este artículo comparar estos frameworks y es suficiente con decir que los probé casi todos y llegué a utilizar a fondo el Zend Framework.

He leído innumerable cantidad de veces debates sobre si este o aquél lenguaje de programación es mejor, si este o aquél framework es mejor, si este o aquél IDE es mejor. La verdad es que es irrelevante, como buen desarrollador uno debe saber hasta dónde arroparse con una tecnología. Existe un principio primordial en el desarrollo web, el cuál siempre he tenido en cuenta: hay que utilizar la herramienta adecuada para cada situación. Java es perfecto para cuando se necesite que una aplicación sea robusta, estable, confiable, etc., pero es un dolor de trasero desarrollar con él. PHP es versátil y se adapta a muchas situaciones, escala bien y es fácil de aprender. Y así podemos ir con ASP.Net, Python, Perl, Ruby, etc. Lo cierto es que no se trata de cuál tecnología es mejor, se trata de cual se adapta mejor a mi proyecto particular.

Hoy en día trabajo con varios desarrolladores en una empresa propia, con mayor libertad tecnológica pero con mayor presión en tiempos de respuesta a los clientes, y estamos frente a un proyecto de desarrollo de un sistema para una empresa. La necesidad de un framework versátil, poderoso y sencillo, es evidente. No nos preocupa mucho la escalabilidad, porque va a tener un número de usuarios limitados que nunca va a ser muy grande. Lo que nos preocupa es la simplicidad, las facilidad para debuggear y la posibilidad de hacer mucho en poco tiempo. Después de todo aquí el tiempo es dinero.

Finalmente es hora de darle a Ruby on Rails (RoR) esa oportunidad que se merece. RoR se vende como todo lo que necesito: versatilidad, simplicidad, hacer mucho en poco tiempo. Así que desempolvé los libros, los viejos links, y es hora de montarme en estos rieles.

A partir de este momento voy a hacer una serie de artículos documentando los pasos que he seguido para pasar de completo novato a, con suerte y esfuerzo, un experto en el asunto. Vamos a ver cómo me va con todo esto.

Día 1

• He empezado por dónde se debe empezar: en la página oficial de RoR. Vi los screencasts y leí sobre los próximos pasos a seguir, como instalar, qué leer, qué usar.
• De ahí pues, siguiendo las sugerencias, descargué InstantRails ya que estoy en Windows. Ahora, una nota aquí: he descargado la versión 1.7, que trae Rails v1.2.3. ¿Por qué si ya salió Rails v2.0.1? Sencillo: la mayor parte de la documentación, entiéndase por esto libros, tutoriales en internet, etc… están hechos para Rails 1.2. Rails 2.0 tiene un mes de antigüedad, y creo que lo más sano es empezar con algo que esté bien documentado.
• InstantRails instalado sin problemas. Sólo descomprimí la carpetica a una ruta sin espacios, corrí el .exe y creé un proyecto nuevo en el menú de “Rails Applications” > “Manage Rails Applications”, y al aparecer la cónsola de Rails ejecuté el comando “rails nombre_proyecto”. Inicié el servicio con Mongrel, y listo! Apunté Firefox a http://localhost:3000 y tenía mi primera applicación corriendo sin problemas.
• Ahora toca elegir un editor o un IDE. Tengo dos opciones identificadas: Radrails, basado en el monstruo que es Eclipse, o eTextEditor, un clon de TextMate. Ya he usado antes Eclipse y Aptana, no dudo que sea un excelente IDE para desarrollar, sin embargo me voy a quedar por ahora con eTextEditor. He escuchado maravillas de Textmate, así que lo más sano es buscar su parecido en Windows y mantener la filosofía de simplicidad que estos predican. Ya estoy un poco cansado de los IDE grandes, y quiero algo distinto y que me recuerde a Notepad++, el cual me gustó muchisimo una vez que lo utilicé cuando trabajaba con Zend Framework.
• Aja, ¿y ahora?. Me debatí entre si seguir alguno de los múltiples tutoriales online que tengo como referencia, o leer el famoso libro “Agile Web Development with Rails: Second Edition“. Como en la página de Rails lo recomiendan, prefiero irme por ésta última opción así que… ¡a leer!
• Leí hasta la página 43. Hasta ahora excelente. Me familiaricé con el modelo MVC, con Ruby como lenguaje, con el Active Record y el Action Pack del framework, con la linea de comando de Rails (ES UNA MARAVILLA!) y una explicación detallada de como instalar y configurar Rails con la base de datos de mi elección. ¡Dejo para mañana empezar con mi primera aplicación!

Hoy quedé maravillado con la línea de comandos. Estoy familiarizado con los ambientes Unix, con Linux en particular, y que con un solo comando puedas crear toda la estructura de un proyecto Rails, con otro comando actualices las versiones (a lo apt-get de Debian/Ubuntu/otros Linux), con otro comando iniciar un servidor WEBrick y con otro generar la estructura de las vistas/controladores… no tiene precio. Muy rápido todo realmente. Además, puedes debuggear una aplicación siguiendo los logs en tiempo real en la cónsola. No más “echo($sql)” ni “print_r($array)” de PHP. Thank God!

Poco a poco voy a ir siguiendo el libro, que hasta ahora me ha gustado su manera de explicar las cosas. El próximo artículo de esta serie hablará sobre mi primera aplicación.

Keep Riding the Rails!

Actualización:

Lista de editores (en el wiki oficial): http://wiki.rubyonrails.com/rails/pages/Editors