Mexico On Rails

Este artículo es una traducción de Getting Started with Ruby on Rails hecha por mi. El artículo original fue escrito por Dan Benjamin en A List Apart

If this translation breaks some copyright and/or hurts someone’s feelings, please let me know. Thanks

Probablemente has escuchado acerca de Ruby on Rails a estas alturas. Tus amigos desarrolladores están delirando sobre él -hablando sobre cómo escribieron una aplicación en menos de la mitad del tiempo que hubiera llevado usando alguna otra tecnología- cómo disfrutaron realmente en vez de estresarse, y luego usaron su tiempo extra en la playa. Rails seguro que suena como una tecnología obligada. Pero ¿qué es, y cómo cabe dentro de la gran imagen del desarrollo web?

Si eres un diseñador, arquitecto de interfaz de usuario, escritor o un desarrollador de software que todavía no conoce Rails, debes estar preguntándote de qué trata toda esta tecnología. ¿Puede realmente transformate, del suave no-desarrollador, al programador de aplicaciones web en una noche? ¿es Rails realmente la todopoderosa plataforma de desarrollo? ¿Qué demonios son Subversion y Git? ¿Necesito aprender todo esto sólo para hacer diseño para Rails?

En este artículo, te ayudaré a prepararte para este primer saqueo dentro de Rails explicando qué es, cómo funciona, y dónde cabe dentro del espectro del desarrollo web y diseño. Trataré los temas de arriba y más, con respuestas enfocadas hacia desarrolladores no-Rails, diseñadores, y otros profesionales creativos.

Este artículo no es un tutorial de programación Rails. No escribiremos código aquí, pero te introduciré a algunos conceptos importantes críticos para entender cómo funciona el framework Rails. Además explicaré lo que necesitas para saber cómo trabajar con desarrolladores Rails e integrar tu XHTML y CSS dentro de proyectos Rails.

Me centraré en los tópicos y temas que he aprendido son los más importantes para la gente creativa en vez de aburrirte con espantosos detalles técnicos. Sí, tendrás que aprender lo que significan términos como “MVC” por ejemplo pero sólo en el contexto de tener las cosas hechas.

¿Qué es Rails, y por qué usarlo?

David Heinemeier Hansson, un socio en 37signals, creó Ruby on Rails. Conforme cronstruyó Basecamp, su aplicación insignia, David extrajo la base de la aplicación y creó código que pudiera usar y reutilizar para el software que quisiera construir en el camino.

El framework que él creó probó ser extensible, expandible, y multi-propósito. Él decidió compartirlo como software de código abierto. Un pequeño grupo de desarrolladores, ahora conocido como el Rails Core Team, formó, mejoró y expandió el framework. Después de un gran esfuerzo, Ruby on Rails maduró y se volvió una plataforma de desarrollo de software robusta, sólida. Hoy, Rails tiene una fuerte comunidad y buena documentación, y es usado por miles de desarrolladores para dar poder a cientos de sitios web, como Twitter, Blinksale, y el mismo sitio que estás leyendo ahora (artículo original). Incluso hay una lista más grande de sitios en Working with Rails.

Rails está diseñado para hacer la construcción de aplicaciones web más simple y fácil. Rails provee a los desarrolladores con un largo, fácil de expandir set de bloques de construcción que pueden usar (y reusar) para crear aplicaciones web. Los desarrolladores pueden usar, integrar, y personalizar estos componentes de código en cualquier modo que quieran, para crear la funcionalidad única que necesiten para sus aplicaciones. Construyendo software de esta manera realmente ayuda a reducir el tiempo que toma para los desarrolladores el crear y después mantener sus aplicaciones. Además ayuda a estandarizar la manera en la que las aplicaciones son construídas, haciendo más fácil para muchos desarrolladores el colaborar y escribir más código uniforme.

Los diseñadores web tienen trucos de CSS probados con el tiempo como punto de comienzo, estándares web a los cuales adherirse, y los flujos de trabajo de Photoshop con los que pueden contar. Como estas herramientas, Rails provee estándares, convenciones, herramientas, y una fundación sobre la cual los desarrolladores pueden construir aplicaciones escribiendo código personalizado usando las librerías pre-construídas de Rails.

Rails vs. PHP

Una de las preguntas que la gente hace frecuentemente acerca de Rails es cómo difiere con PHP. PHP es un lenguaje de scripts con fines generales que puede ser embebido justo dentro de páginas HTML, haciendo fácil para los desarrolladores el crear dinámicamente páginas web generadas rápida y fácilmente. Muchos diseñadores web y la mayoría de los desarrolladores web han usado PHP en alguna capacidad. A causa de su proliferación (es generalmente instalado por defecto en la mayoría de los webhosts), PHP es comúnmente el lenguaje preferido para manejar tareas simples como mantener la navegación de tu sitio actual, aleatorizar imágenes en un sitio web, e incluso crear un sistema para manejo de contenido simple. PHP es además útil para crear aplicaciones de código abierto auténticas y aplicaciones web comerciales como WordPress, y HelpSpot, ambas aplicaciones PHP.

Técnicamente hablando, no deberíamos comparar PHP, un lenguaje de programación, con Rails, un framework de aplicaciones web. En lugar de eso, deberíamos comparar PHP con el lenguaje de programación Ruby sobre el cual Rails fue construído. Ruby fue creado en 1995 por Yukihiro “Matz” Matsumoto, y lentamente ha obtenido un seguimiento, explotando en popularidad y obteniendo más atención en 2006, en gran parte por la popularidad de Rails. En el momento de este escrito, Ruby se encuentra en el 9o. lugar de los lenguajes más populares en el mundo.

La cita del sitio de Ruby, “Ruby es un lenguaje de programación dinámico y de código abierto enfocado a la simplicidad y productividad. Su elegante sintaxis se siente natural al leerla y fácil al escribirla”. Esta elegancia y enfoque a la simplicidad hace a Ruby un lenguaje muy accesible para gente nueva en la programación, y ofrece un refrescante cambio de ritmo sazonado a los desarroladores.

Veamos através de un ejemplo rápido, sólo para tener un “sentimiento” de lo que estamos hablando. Digamos que queremos contar de 1 a 10. En PHP, el código podría lucir así:

for($i = 1; $i <= 10; $i++) {
  echo $i;
}

Si estás familiarizado con C, Java, u otras estructuras de control al estilo C, esto es sencillo para ti. Pero si eres nuevo en esto, podría parecer intimidante. Aquí está el mismo código en Ruby:

10.times do |i|
  puts i
end

Ruby además tiene sus propios trucos y atajos que deberían hacer incluso a un hacker de Perl feliz. La siguiente línea hace la misma cosa que los ejemplos de arriba:

puts *(1..10)

Este tipo de flexibilidad y simplicidad hace a Ruby un lenguaje accesible para desarrolladores de software y diseñadores web de todos los niveles.

Mientras PHP es un lenguaje de programación amigable a la web, Rails es un framework de aplicaciones web escrito en Ruby (y con acceso a toda la funcionalidad de Ruby para el arranque). Y por la manera en la que funciona Rails, cada aplicación que construyas vive en la forma de un proyecto, con archivos y carpetas específicas. A diferencia de muchas aplicaciones PHP que a menudo “funcionan sólo” con subirlas a un webserver, las aplicaciones Rails dependen de su propio framework y una infraestructura de hosting personalizada (frecuentemente llamada un “stack” [pila]). Como resultado, las aplicaciones Rails pueden ser un poco más difícil de desplegar. Afortunadamente, un número de compañías de web hosting se especializan en desplegamiento, hosting, y administración de aplicaciones Rails.

Entonces ¿cómo podrías saber cuándo usar Rails y cuándo usar PHP? No hay nada que uno no pueda hacer en Rails que no se pueda hacer en PHP (o viceversa), así que al final es cuestión de elección. Para mí personalmente, tengo una regla simple: si estoy añadiendo funcionalidad simple (como rotar encabezados de imágenes) a un sitio web sencillo, usaré a menudo PHP. Si estoy construyendo una aplicación web, especialmente con una base de datos, usaré Rails. De nuevo, ambos pueden hacer lo mismo, pero para mí el framework Rails es maravilloso para el tipo de desarrollo de aplicaciones web que me gusta hacer.

Cabe señalar que hay frameworks con metas similares a las de Ruby on Rails que están escritas en PHP, tales como CakePHP y CodeIgniter.

Mitos de Rails

Antes de ahondar un poco más a fondo en lo que es en realidad Rails, qué hace, y cómo lo podrías usar, quiero disipar unos cuantos mitos que los no-desarrolladores a menudo tienen sobre el framework. Esta lista en realidad viene de preguntas reales que gente real me ha preguntado sobre Rails en los últimos años.

Mito #1: Rails es un sistema para gestión de contenido (CMS)

He mencionado que Rails hace súper fácil el crear aplicaciones web rápidamente -que tiene un montón de funcionalidad y componentes preconstruídos. Pero lo que en realidad Rails te da -el framework del que estamos hablando- es código. Rails no es una pieza de software plug-and-play que se acostumbre adaptar a aplicaciones específicas, mientras sólo se integra algo de diseño a lo largo del camino. Puedes pensar en Rails como si fuera un elaborado menú de código del que los desarrolladores pueden escoger, modificar, y extender para crear un aplicación completamente personalizada.

Mito # 2: Rails te deja hacer aplicaciones mil millones de veces más rápido

En cierto modo, la excelente campaña de publicidad “Rails lo hace fácil” de hecho ha dañado algunas tiendas independientes de desarrollo Rails. Los consumidores esperan que las aplicaciones Rails se rueden en días independientemente del set de sus características. En realidad, las aplicaciones Rails no son escritas para tí automáticamente. Rails ahorra tiempo a los desarrolladores dejándolos concentrarse en la funcionalidad específica de la aplicación en vez de cosas como la interconectividad con la base de datos. Se ocupa de todo el trabajo necesario para construír la interacción del usuario. Los desarrolladores pueden usar este código pre-construído, y utilizar más tiempo haciendo aplicaciones que son más fiables y fácil de usar. Aún los proyectos Rails pueden ser un poco complicados. Los desarrolladores Rail deben seguir escribiendo código real (y a menudo complejo), interacciones, y pruebas. Rails hace el desarrollo más divertido y elimina gran parte del tedio que participa en la construcción de aplicaciones web, pero no las construye para ti.

Mito #3: No necesitas ser programador para hacer aplicaciones Rails

Escucho esto mucho, y por supuesto es falso. En realidad, los desarrolladores Rails hacen mucho más que ensamblar componentes. Seguro, ellos usan convenciones de Rails y construyen encima de una plataforma comprensiva, pero aún así escriben código nuevo y único.

Es verdad, sin embargo, que no podrías necesitar ser un desarrollador experimentado para crear una aplicación Rails como lo necesitarías ser para construír, por ejemplo, una aplicación PHP, Java, o C. Esto es debido a la simplicidad del framework Rails y a la elegancia y legibilidad del lenguaje de programación Ruby, sobre el cual Rails se sienta. Aún necesitas aprender a escribir código.

Empezando

Tener Rails en marcha en tu computadora está fuera del alcance de este artículo. Afortunadamente, la última versión de Mac OS X 10.5 (Leopard) viene con Rails pre-instalado (o puedes hacerlo tú mismo). He escrito un tutorial para instalar Rails en versiones anteriores de Mac OS X. Hay un One-Click Installer para windows. También puedes descargar el código fuente o encontrar recursos adicionales en el sitio de Ruby on Rails para ayudarte a tener las cosas en marcha. (N.T. También puedes instalar Rails en linux).

En lugar de esperar a ir através de los pasos para tener Rails instalado por primera vez, por ahora, he creado un proyecto Rails por defecto que puedes descargar y mirar en cualquier computadora, independientemente de si tienes Rails instalado o no. Toma el archivo y descomprimelo en algún lugar que puedas encontrarlo.

Nota: Las carpetas y archivos que encontrarás en el archivo son idénticos a lo que Rails hubiera creado si corrieras rails demo en la línea de comandos, seguido por script/generate scaffold article body:string. De nuevo, estos son comandos que jamás podrías correr, pero los desarrolladores Rails los usan para ayudarse a crear el código que usan en sus proyectos.

MVC

Hablando de crear código, hay algunos conceptos de desarrollo de software que deberías conocer -incluso como diseñador- antes de entrar de lleno a Rails. Entender estos conceptos te ayudará a entender la estructura de Rails, y hacerte más fácil el trabajo con el framework mismo.

Rails implementa una técnica de ingeniería de software llamada modelo-vista-controlador (model-view-controller), comúnmente abreviada como MVC. Esta técnica (o patrón) separa la lógica de negocios (cosas como interacción con la base de datos) de la interfaz de usuario, la cual llamamos lógica de presentación. Esta separación en realidad hace la vida del diseñador mucho más fácil, porque a diferencia de otros web frameworks, la cantidad de código Rails que un diseñador tiene que ver y acomodar alrededor es significativamente reducida.

En Rails, cada una de estas diferentes piezas de la aplicación se mantienen en diferentes carpetas. La lógica de negocios (los modelos y los controladores) son guardados separadamente de las vistas. Lo que es importante entender aquí es que MVC significa que el XHTML y CSS que tu creas es almacenado lo más separado posible de los niveles más profundos de código. Desarrolladores puros ven menos diseño, mientras los diseñadores se meten menos con el código.

(N.T. Entendiendo el flujo de una aplicación Rails)

Cómo editar archivos Rails

Rails guarda sus archivos como texto plano, por lo que puedes escoger cualquier editor de texto para editar los archivos en un proyecto Rails. Yo prefiero una aplicación de Mac OS X llamada TextMate, la cual es ideal para trabajar con Rails. BBEdit, otra aplicación de Mac OS X, también funciona bien, como lo hacen muchos editores de texto en Windows. Linux, también tiene su parte de editores capaces. Algunos editores hacen un mejor trabajo mostrando el código Rails usando edición de sintáxis y destacado de código con color, haciendo que el código se vea bastante bien. Otros editores no reconocen código de Ruby on Rails del todo. Abajo se muestra un ejemplo de código siendo editado en TextMate:

Ejemplo de sintáxis de Ruby on Rails

Bonito, eh?

Textmate (y BBEdit) tienen la ventaja de ser capaces de abrir y mostrar proyectos enteros en su entorno, permitiendote localizar y editar un archivo rápidamente.

(N.T. Netbeans 6+ también es una buena opción para editar proyectos Rails en cualquier plataforma)

Todo en el lugar correcto

Los proyectos Rails están hechos de montones y montones de capretas y archivos -la mayoría de los cuales Rails genera durante la creación inicial de la aplicación. Si estás acostumbrado a tratar con proyectos más pequeños, esto puede al principio parecer algo como una cantidad intimidante de contenido.

Usar carpetas de esta manera hace más fácil el separar los modelos, controladores, y vistas. Y justo todo lo que los no-desarrolladores necesitarán conocer estará en el mismo lugar en cada proyecto Rails -lejos del profundo código que pertenece a la capa de lógica de negocios. Veamos los archivos y carpetas que Rails creó.

Ejemplo de la estructura de carpetas por defecto de Rails

Estos archivos y carpetas serán muy parecidos no importa con qué aplicación Rails estés trabajando. Incluso aplicaciones Rails muy largas y complicadas tendrán esta estructura idéntica. Y aún mejor, tus archivos y la lógica de presentación irán siempre en el mismo lugar.

De hecho es seguro para tí ignorar la mayoría de lo que ves aquí por ahora. Las carpetas a las que debes poner atención son app/views, app/views/layouts, public/images, y public/stylesheets, señaladas abajo.

Carpetas importantes

Insertando código Rails en HTML

Típicamente, cuando trabajas con desarrolladores Rails, tú crearás un diseño y ellos insertarán el código Rails en él. Pero en ocasiones, se trabajará de la otra forma -los desarrolladores Rails tendrán ya los archivos básicos y tú necesitarás “diseñar alrededor” de su código.

Si estás familiarizado con la forma en la que las plantillas trabajan en software de blogging como Movable Type o WordPress, entonces también te será familiar la forma en la que las layouts y vistas trabajan en Rails. Rails permite a los desarrolladores separar la funcionalidad de una aplicación dentro de grupos de vistas relacionados. Si estamos desarrollando diferentes maneras para crear, editar, y desplegar un artículo de una revista web, Rails querrá que pongamos estas vistas dentro de una carpeta llamada articles en la carpeta app/views.

Las plantillas que contienen el HTML que los usarios realmente verán no terminan en .html como los archivos HTML normales. En cambio, estas tienen tienen extensiones de archivo especiales: .html.erb. La adición de .erb le dice a Rails que estos archivos contienen código Ruby insertando, y usarán tecnología de plantillas de Ruby. Esta tecnología permite a desarrolladores Rails insertar código Ruby on Rails justo dentro de cualquier plantilla muy fácilmente. Echa un vistazo al archivo app/views/articles/edit.html.erb:

Ejemplo de código Ruby insertado dentro de una plantilla HTML.

Puedes notar etiquetas (tags) que normalmente no verías en un archivo HTML. Estas etiquetas especiales le dicen a Rails dónde está el código insertado. Cuando Rails las ve, ejecuta el código dentro ellas y muestra el resultado justo en el navegador del usuario como va haciendo la página.

Las etiquetas <%= y <% indican el inicio del código Rails o Ruby, mientras que la etiqueta %> indica el cierre de ambas etiquetas. Como un no-programador, es seguro poner tu HTML alrededor y dentro de estas etiquetas, pero ten cuidado con mantener lo que hay en el interior de las etiquetas intacto. Sin embargo, puedes mover este bloque de código a donde quieras dentro de tu HTML, o editar el HTML dentro y alrededor de este bloque como se necesite. Por ejemploi, podrías cambiar el fragmento de arriba para que luzca como el ejemplo de abajo sin afectar nada del código Rails:

Rails es versátil: puede ser movido dentro y fuera del HTML existente con poco esfuerzo.

Pudiste haber cambiado completamente cómo se muestra la página, pero la funcionalidad permanece intacta.

En Rails, hay una plantilla primaria -un archivo usualmente encontrado en app/views/layouts/application.html.erb. Este archivo contiene la “envoltura” del XHTML que rodea el contenido que la aplicación despliega a los usuarios. Si abres este archivo ahora, verás exactamente de lo que estoy hablando.

En muchos sistemas de blogging, los diseñadores acostumbran “cortar” sus diseños -separando cosas como el encabezado, pie de página, y lateral dentro de diferentes archivos. Aunque Rails soporta esto, el patrón usual es poner estos elementos justo dentro del archivo application.html.erb y usar Rails para colocar el contenido en su lugar.

Si quisieras personalizar el diseño de un sitio Rails, este es el lugar donde deberías empezar. Y eres libre de personalizar todo lo que quieras -sólo mantén un ojo en la línea que luce asi:

<%= yield %>

Este es el trozo especial de Rails que dice “pon el contenido para esta página aquí.” La ubicación de esta única línea determina en dónde aparece el contenido principal de cada página.

Los desarrolladores Rails tienen técnicas para variar el contenido que aparece en diferentes áreas de la plantilla principal, como el título de una página, diferentes hojas de estilo para incluir, o contenido variable de la barra lateral.

Si recordamos la discusión sobre Modelo/Vista/Controlador de arriba, recordarás que nuestra principal atención se centrará en el trabajo con las vistas. Cada área general de funcionalidad de una aplicación Rails tendrá su propia carpeta en la carpeta de las vistas (app/views). Por ejemplo, si estubieramos trabajando en los diseños para una revista web como la que estás leyendo ahora (artículo original), habría vistas especiales dedicadas a mostrar artículos, y esas vistas siempre vivirán en la carpeta app/views/articles.

Es cierto que no todas las aplicaciones Rails tendrán artículos, pero Rails especifica que cada área del sitio web -artículos, comentarios, temas, facturas, etc.- tendrá su propia carpeta en el directorio de las vistas. Es parte del patrón de Rails.

La carpeta pública (public)

A diferencia del resto de los archivos en una aplicación Rails, todo lo que se encuentra en el folder public es visible al mundo externo. En la carpeta public hay dos folders a los que querrás poner especial atención: images y stylesheets. Aunque no hay reglas estrictas que digan que tus imágenes y hojas de estilo deben vivir en estas ubicaciones, colocándolas ahí es una bendición para los desarrolladores Rails, para que puedan fácilmente llamarlas desde el código como sea necesario.

Control de código

Cualquiera que cree archivos que cambian con el tiempo necesitará probablemente, en algún punto, ayuda para mantener seguimiento de cómo cambian los archivos, y naturalmente querrá tener un respaldo de esos cambios. Esto es aún más importante cuando estás compartiendo el proyecto y archivos de código con otras personas quienes harán cambios también.

Afortunadamente hay un software especial, usualmente referido como control de código o sistema de control de versiones, para ayudarnos a gestionar este proceso. El sistema más comúnmente usado con proyectos Rails es llamado Subversion (también conocido como SVN). Subversion es una solución de código abierto gratuita, disponible para la mayoría de las plataformas. Este recuerda cada cambio que se ha hecho a los archivos y directorios en tus proyectos. Esto te permite recuperar versiones anteriores de tu información, o examinar la historia de cómo ha cambiado la misma.

Los sistemas de control de código reemplazan el método “cambia un archivo y súbelo al servidor con FTP” para actualizar archivos -creando en cambio una forma consistente de hacer tus cambios disponibles a todos en tu equipo simultáneamente, y mantener todo actualizado e integrado en un paso.

Git, un sistema de control de código alternativo, ha ganado popularidad recientemente, tanto que el Rails Core Team está actualmente usándolo para administrar el código de Rails mismo.

Aunque el proceso y comandos que usarás para administrar los cambios que haces varían entre diferentes sistemas de control de código, el concepto es similar sin importar la tecnología que se use. Y aunque pueda parecer un tanto difícil de entender, una vez que lo empieces a utilizar los beneficios de usar un sistema de control de código para administrar un proyecto Rails fácilmente superan la curva de aprendizaje.

Las instrucciones para administrar proyectos usando Subversion y Git están fuera del alcance de este artículo y a menudo varían en base al sistema usado así como al equipo que lo usa. Pero es importante saber que probablemente será necesario que uses este tipo de sistema, y que eso involucrará escribir comandos en la línea de comandos o usar una nueva aplicación de control de código para hacer el tipo de cosas que solías hacer sin cualquier complicación adicional.

Siguientes pasos

Si estás interesado en aprender más acerca de Ruby on Rails, hay muchos lugares para empezar. Una excelente forma de aprender Rails es observando algunos de los excelentes screencasts de Rails.

También hay un montón de buena documentación disponible, con algunos puntos de partida en la página de documentación de Ruby on Rails.

Puedes aprender todo lo que siempre quiciste saber sobre Subversion y gestión de control de código leyendo la versión (gratuita) de Version Control with Subversion.

Además hay muchos, muchos maravillosos blogs, podcasts, artículos, tutoriales, y screencasts disponibles en línea que se centran en aprender Rails. Sólo checa esta lista en Google si quieres un buen lugar para empezar.

Conclusión

Espero que esta suave introducción a Rails responda algunas preguntas y tal vez disipe unos cuantos de los mitos alrededor de Rails. Y aunque Rails es una gran plataforma, aún necesita más gente como tú -diseñadores, arquitectos de interfaz, y escritores- para ayudar a guiar y dirigir su futuro. Es una plataforma lo suficientemente joven para que gente con tu experiencia pueda realmente determinar en lo que se transforma ahora y en los próximos años.