Una de las cosas que me dejó el 2012 fué conocer Ruby on Rails. Luego de haber navegado un poco por PHP, haber conocido CodeIgniter y luego probado Django con la guía de Maestros del Web, puedo llegar a la conclusión de que si tuviera que programar en un solo lenguaje para la web, lo haría usando Ruby a través de Rails.
Hace poco escuché hablar en mejorando.la a @freddier y @cvander de que promoverían Ruby onRails en 2013. Si has escuchado hablar o aún no has decidido si vale la pena aprender Rails en el año que iniciamos, voy a darte algunas razones que puedan motivarte a aprender Rails.

Está escrito en Ruby
Ruby es un lenguaje de programación orientado a objetos creado por un japonés de nombre Yukihiro Matsumoto, mejor conocido entre la comunidad como Matz. Esta persona decidió crear un lenguaje en el que fuera divertido programar. Sin lugar a duda, Ruby es un lenguaje poco convencional puesto que la sintaxis que utiliza es en varios aspectos distinta a la que estamos acostumbrados si aprendimos a programar con lenguajes como C, JAVA o PHP. Una de las cosas que me gusta de Ruby es que es lleva al extremo el paradigma de los objetos, en Ruby "CASI" todo es un objeto, de hecho hay discusiones incluso sobre si los métodos de los objetos son objetos... Parece confuso cuando empiezas a adentrarte en el lenguaje pero al final es una herramienta poderosa.
Otra de las razones por las que probablemente te guste Ruby es que puedes re escribir el comportamiento de cada parte del lenguaje, es decir, si deseas que la sentencia if se comporte de distinta manera, ¿adivina? Puedes hacerlo. Aquí un ejemplo:
Código :
classFloat defround_to(x) (self * 10**x).round.to_f / 10**x end end flotante = 0.0123123 flotante.round_to(2)
En el ejemplo anterior modificamos el comportamiento de un flotante (que también es un objeto) para añadir la función rond_to y más adelante lo usamos en un ejemplo. Esto es algo de lo mucho que puedes hacer con Ruby.
Promueve las buenas prácticas
No cabe duda que, sin importar qué lenguaje sea, si uno escribe mal código, así lo hará; mientras que por el contrario quien está acostumbrado a escribir buen código así lo hará. En Ruby y en Rails hay un sin fin de maneras de evitar repetir código (DRY) por ejemplo con el uso de layouts, lambdas y blocks, tenemos helpers, podemos ejecutar métodos antes de cualquier otro dentro de un controlador de modo que el código que escribimos una vez, no lo repitamos de nuevo. Consideremos el siguiente ejemplo:
Código :
classAppController<ApplicationController defindex client = YouTubeIt::Client.new(:dev_key => "my_dev_key") @canal = client.profile("mejorandola") end def videos client = YouTubeIt::Client.new(:dev_key => "my_dev_key") @canal = client.profile("mejorandola") @videos = client.videos_by(user: "mejorandola") end end
Donde tenemos un controlador con código repetido en dos diferentes funciones que podríamos reciclar de la siguiente manera:
Código :
class AppController < ApplicationController before_filter :get_client def get_client @client = YouTubeIt::Client.new(:dev_key => "my_dev_key") @canal = client.profile("mejorandola") end def index end def videos @videos = @client.videos_by(user: "mejorandola") end end
Y ahorramos líneas de código, cumplimos con el principio Don'tRepeatYourself y además hacemos el mantenimiento mucho más sencillo.
¿Frontend ninja?
Ruby onRails viene configurado por default para poder escribir javascript utilizando CoffeeScript y CSS utilizando SASS. De modo que si eres frontenddeveloper no puedes evitar querer aprender Rails, si no conoces SASS, esto es lo que te ofrece, entre otras cosas:
- Hacer uso de funciones en CSS
- Utilizar operaciones matemáticas y operaciones con colores.
- Permite crear mixins, que es incluir un bloque de CSS en múltiples partes.
- Tiene ciclos for, condicionales y variables.
¿Y CoffeeScript? Es escribir javascript de una manera más limpia con una sintaxis parecida a la de Python, sin puntos y coma, llaves y con sintaxis para los objetos mucho más limpia que utilizando la de javascript crudo, que por cierto CoffeeScript no tiene ningún problema con frameworks de javaScript como jQuery.
La arquitectura
Ruby onRails está construido bajo la arquitectura MVC (Modelo, Vista, Controlador) con lo que busca dividir el trabajo de un aplicación en diferentes puntos, el modelo se encarga de los datos, la vista del despliegue de los mismos y el controlador de pedir/recibir información del Modelo y enviársela a la vista para que el usuario pueda verla. El modelo MVC tiene un sin fin de beneficios, como por ejemplo, que puedas dividir el desarrollo con tu equipo de trabajo dependiendo de la habilidad de cada persona, el frontend sólo se encargaría de la vista, y los backendsdevelopers del controlador y el modelo.
Además, Rails cumple con los principios de otro modelo, el modelo REST. Sin querer ponerse muy técnico, entre varias cosas esto significa que utiliza las acciones CRUD (Create, Read, Update, Delete) del protocolo HTTP, en código eso se traduce en utilizar POST, GET, PUT Y DELETE como debe hacerse, y en cuestiones de beneficios eso significa que la misma URL puede llamar a las distintas acciones que te mencionaba, es decir:
Código :
http://miaplicacion/productos/1
Que esa URL puede servir para mostrar el producto 1, borrarlo, actualizarlo y crearlo. Puede parecerte confuso al principio porque, por ejemplo, si deseas loguear a alguien, eso se traduce en CREAR una sesión, por lo contrario, el log out significa DESTRUIR la sesion.
Las Gemas
Entiendo que en Python tienen pip, y en PHP también hay un equivalente a las gemas (no recuerdo el nombre). Sin embargo, las gemas de Rails son un punto más alto, y eso me lleva a contarte algo, en la comunidad de Rubyeros hay un lema que dice
Comunidad Ruby :
O al menos ese fue mi intento de traducir "Matz is nice, so we are nice" y es que la idea es querer aportar algo al mundo del que vivimos (programamos), así es como han crecido las gemas, hay gemas muy famosas para trabajos complejos, por ejemplo aquellas que te permiten trabajar con SASS y CoffeeScript, otras que te permiten integrar Facebook o Twitter en tus aplicaciones, algunas más para crear sistemas de logueo como Device, en fin, existen tantas que incluso hay una sobre NyanCat.
La comunidad de Ruby es amplia y tiene ganas de ayudar, encontrarás múltiples recursos que facilitarán, pero sobre todo, agilizarán tu proceso de desarrollo, y un ejemplo muy claro es el sin número de Gemas que hay allá afuera.

Inspiró a otros
No es por querer armar polémica, pero comúnmente me digo, si hay otros frameworks que han sido inspirados por Rails (ejemplo Grails o CakePHP) ¿por qué usar un derivado en lugar del original? Sé que las razones tienen que ver con el gusto al lenguaje que más te guste, pero si hay frameworks construidos para mimetizar Rails en otros lenguajes, debe ser por algo ¿no?.
Algunas cosas más
Aún hay mucho que hablar sobre beneficios de Rails, sin embargo, con la intención de no hacer más largo el post las mencionaré a grandes rasgos sin que signifique que son menos importantes.
El manejo de base de datos es amor al programador en Rails, es genial. Puedes trabajar en una BD y luego con toda la facilidad del mundo cambiar de gestor sin que esto sea un dolor de cabeza, pasar de PostgressSQL a Mysql o Sqlite no debería ser cuestión de pánico en Rails. ¿Hiciste una modificación a la estructura equivocada? No te preocupes, en Rails hay un concepto que se llama migraciones que son modificaciones a la base de datos que se guardan en una especie de pila y puedes revertir cambios que no te hayan gustado, de nuevo, sin que esto te quiebre la cabeza.
Rails está bien respaldado, en sus inicios Twitter estaba hecho sobre el framework, Github utiliza rails también, Heroku y un sin fin de startups deciden programar en Rails, hay gente que cree que no es escalable basados en el argumento de que Twitter tuvo que mudarse a Scala, en lo personal creo que cuando llegas al nivel de Facebook, Twitter, es inevitable que tengas que hacer algunas cosas oscuras en el servidor para soportar el tráfico que ellos reciben, y por otro lado se ve Rails funcionando en otros lugares con mucho tráfico sin problemas.
Como mencionaba antes, muchos startups, agencias de desarrollo y demás eligen Rails como primera opción para el desarrollo de productos, lo que para tí como programador significa trabajo, mucho trabajo y muy bien pagado, leía que un programador de Rails puede llegar a ganar 300USD por hora en Estados Unidos, y según una encuesta de Software Gurú, Ruby es el tercer lenguaje mejor pagado detrás de Objective-C y Cobol.
Ruby on Rails en el 2013
Aún cuando no hay fechas para al salida de la versión 4 del framework, puede esperarse en este año puesto que ya se han revelado varias de las características que se añaden al core de Rails, por ejemplo:
- Parámetros fuertes, el filtro de parámetros se hará ahora desde el controlador.
- ActiveSupport::Queue
- Cache Digests
- Y algunas improvisaciones al ActiveRecord y el manejo de los routes.
En fin, los beneficios de Rails son muchos, y probablemente faltó mencionar el manejo sencillo de relaciones en Rails, el ActiveRecord, migraciones más a detalle, la configuración de los Routers, que al menos en mi experiencia al trabajar con otros frameworks, son otras razones por las cuales programar en Rails es una buena opción.
Si deseas aprender Ruby o Ruby on Rails, puedes visitar la página de Código Facilito. aunque es mi intención subir algunos tutoriales sobre el framework.
¿Sabes SQL? ¿No-SQL? Aprende MySQL, PostgreSQL, MongoDB, Redis y más con el Curso Profesional de Bases de Datos que empieza el martes, en vivo.
"classFloat", "defround_to" y vi otros mas.
Suerte con Ruby.
Por ramb0Ram el 03 de Enero de 2013
Saludos
Por ssergi el 03 de Enero de 2013
Por vicman el 03 de Enero de 2013
Por ahora entre mis planes no está considerar volver al que puede ser un buen lenguaje, pero con una pobre comunidad.
Saludos.
Por teskostudio el 04 de Enero de 2013
Y Ruby on Rails?. Como programador web no acabo de entender de que va el asunto o como hacerlo servir.
Twitter en un inicio estaba basado en Rails, de hecho algunas partes de twitter aun usar Rails.
HTML, CSS y Javascript se usan en el cliente y solo son para hacer dinámica la parte del navegador, pero que pasa si por ejemplo quieres hacer un sistema de usuarios, o un blog. Para eso sirven los lenguajes de servidor.
Saludos y espero haberte aclarado.
Por pyner el 04 de Enero de 2013
Por eduardo78d el 04 de Enero de 2013
Por leojg el 05 de Enero de 2013
Pd: a cristalab le falta optimizacion para moviles. Es un martirio escribir un comentario
Ruby on Rails no viene por defecto para escribir con CoffeeScript ni SASS.
CoffeeScript tiene más inclinación hacia Ruby.
Heroku no está escrito en Rails, fue hecho en un inicio para Rails, sin embargo, ya soporta otros lenguajes.
Como aportación, la nueva versión de Rails soportará también Arrays en la base de datos de manera nativa.
Igualmente, lo que van iniciando con Ruby, les recomiendo los Ruby Koans.
Por samuel el 05 de Enero de 2013
en python tambien todo es un objecto pienso que rails es maravilloso pero para entenderlo bien tienes que ser primero un hacker de ruby....
Por Raxiro el 07 de Enero de 2013
Por samuel el 09 de Enero de 2013
Por kernel19 el 10 de Enero de 2013
Por Nico el 11 de Enero de 2013
Yo personalmente nunca había hecho nada "serio" con django o rails, pero una vez que dominas los patrones de diseño más corrientes y comprendes todos los componentes del paradigma OOP poco cuesta aprender un nuevo lenguaje/framework.
La decantación inicial fue por ruby, al comenzar a hacer las primeras pruebas nos enamoramos de rails, de hecho me compré un libro en amazon los primeros días que comenzamos a trastear, todo muy intuitivo, muy productivo, la metaprogramación muy bien aprovechada y ajustada.
Lo que se suele hacer cuando se implementa una tecnología "nueva" en nuestro equipo es realizar un proyecto de baja escala con buen margen de tiempo, lo que permite que los desarrolladores obtengan formación y generen ganancias al mismo tiempo, con casos de uso reales, etc. Fué lo que hicimos.
Durante el desarrollo de este "mini" proyecto (era una web comercial con noticias, eventos... simple) todo fué bien, de fábula diría yo, los desarrolladores estábamos muy contentos con rails y ruby. Todo bien hasta que llegó la hora de implantar en producción las primeras pruebas. Fue ahi donde vimos un abismo gigante en rails.
Las diferencias entre plataformas, arquitecturas, sistemas operativos de nuestro sistema (servidores de desarrollo, servidores de producción, replicación, balanceo de carga) no permitían mantener una versión de rails unificada y (lo más importante) actualizada entre ellos. Y eso que estamos hablando de 100% Unix en muchas variantes. El cambio de rails entre la versión (ejemplo/exageración no me acuerdo) 2.0.1 a la 2.0.2 hacían directamente que tu código no funcione, (la retrocompatibilidad brilla por su ausencia). Terminamos con Django, que día a día nos ofrece el mismo nivel de productividad y facilidades que rails, pero sin su problemas de portabilidad.
Ojalá que hayan solucionado ese gran problema o lo solucionen en un futuro ya que rails me pareció increíblemente claro y elegante. Tenganlo en cuenta para proyectos de grandes escalas si aún es así. Saludos.
Por kernel19 el 13 de Enero de 2013
Por Pablo el 09 de Agosto de 2013
Por Pepe el 16 de Agosto de 2013
Por Cristian el 24 de Octubre de 2013
Por RTJ el 18 de Febrero de 2014
Tengo mas de 6 años de experiencia como programador PHP(con frameworks unos 3) y unos 2 años con python / django.
Ahora he probado Rails y no cre que vuelva a hacer algo ni con php ni con django. es verdad que al principio te echa para atras... pero hace unos 6 meses decidi forzarme y usarlo en un proyecto... desde entonces solo uso rails y me encanta, lo que al principio puede parecer dificil luego e enamora.
Y aunque algunos dicen que hay frameworks como larave en php que pueden ser incluso mejores.... mentira.. he trabajado con laravel, cakephp, fuelphp etc... y auqnue intentan parecerce a RoR, Ruby on rails es mucho mejor con diferencia.... este es mi punto de vista
Saludos.