Llevo ya bastante tiempo trabajando con Ruby on Rails y pensando en hablar acerca de este lenguaje y este framework que, la verdad, me está conquistando conforme va pasando el tiempo. En este post, me gustaría explicar por qué me he decidido a realizar, como mínimo, 5 proyectos reales para clientes usando Ruby on Rails, de los cuales os iré hablando, porque la verdad es que me parecen bastante interesantes también.
Normalmente dedico alguna hora al día a hacer formación, investigar nuevas tendencias, hacer cursos con lenguajes nuevos que no he tocado, en fin, intentando no estancarme. En estos intentos decidí empezar a trabajar con un lenguaje que me permitiera trabajar mas rápido que con php, que aún siendo el más extendido me parece bastante poco eficiente a la hora de programar aplicaciones grandes y para varias plataformas, en fin, será cuestión de opiniones, y no digo que php no sea un gran lenguaje, que lo es, pero habiéndome acostumbrado a programar para iOS, y habiéndome acostumbrado a desarrollar teniendo muy en cuenta el paradigma MVC, punto en el que php deja mucho que desear.
En definitiva, como he dicho, por cuestión de gustos andaba buscando una alternativa y oí muy buenas cosas de python y estuve unos meses haciendo aplicaciones de prueba con python y debo decir que me encantó el lenguaje, simple, limpio y claro, y sobre todo rápido y marcadamente orientado a objetos, programar en python es muy rápido y limpio, es el lenguaje con la curva de aprendizaje más rápida que me he encontrado. Una vez ya me había gustado el lenguaje me encontré con dos problemas que me echaron bastante para atrás.
- Fragmentación del lenguaje. aún mucha gente utiliza la versión 2 del lenguaje Python, aunque la versión 3 ya está disponible desde hace bastante tiempo. La mitad de los cursos que hice de python estaban en la versión 2.7 cuando ya estaba disponible desde hace bastante tiempo la versión 3.4. En fin el tema de fragmentación no me hacía mucha gracia, aunque para empezar, está claro que tampoco es que me afectara demasiado, mis aplicaciones serían aplicaciones nuevas y directamente empezaría en la última versión disponible, claro está.
- Frameworks. Aquí es donde me desanimé más a la hora de elegir python, estuve tiempo probando dos frameworks para construir apps web con python, Flask y Django y la verdad ambos me parecieron bastante complicados de manejar y configurar, mientras que python como lenguaje me ha encantado, los frameworks me han decepcionado bastante. Por poner un ejemplo, estuve varios días simplemente intentando llevarme un hola mundo a un dominio real en producción, en el servidor local de desarrollo todo perfecto, pero estuve durante días intentando configurar la app (llamarlo app es ser muy pretencioso la verdad, era solo una prueba) y me costó lo indecible.
Estaba en estas tribulaciones cuando me decidí un día a empezar un curso de Ruby on Rails que tenía aparcado desde hacía tiempo, a ver que tal me dije, y la verdad es que genial, en menos de 48 horas tenía un blog completamente operativo en un servidor en producción, empecé a darle temática incluso y se convirtió en un par de días en juegodetronos.me si queréis podéis echarle un vistazo y registraros para postear como vuestro personaje favorito de juego de tronos, es una tontería muy simple, pero, para empezar, me sorprendió la velocidad con la que estaba operativo y había creado toda la interfaz CRUD y todo lo relacionado con la gestión de la base de datos. Voy a dar algunas razones que me encantaron desde que empecé con Rails y que me han ido convenciendo con el tiempo
- Simple y rápido. Si hay algo que define la programación de Ruby on Rails es la rapidez con la que se puede realizar una aplicación web bastante decente, una intranet, un sistema de tickets, etc.
- Orientado completamente a MVC. El paradigma modelo vista controlador forma parte propiamente dicha de la forma de programar en Ruby on Rails, cuando estás desarrollando, directamente lo haces teniendo esto en cuenta, lo cual facilita mucho el desarrollo de aplicaciones grandes, tener esto en mente hace que la estructura de tus aplicaciones sea mucho más clara y sencilla de manejar
- ActiveRecord. Active Record es la manera que tiene Rails de gestionar la comunicación con la base de datos, no hace falta que hagamos todos los procesos y toda la generación de claves externas y tipos de relaciones a mano, Active Record gestiona toda la creación y mantenimiento de la base de datos, además, se encarga de que especifiquemos los tipos de relaciones y así, evitar errores a la hora de crear la base de datos de los que luego nos podemos pasar horas y horas viendo donde nos hemos equivocado. No solo eso, las consultas son muy sencillas de manejar, hablaré de este tema mucho más en detalle en otros posts, pero, de verdad, la forma que tiene Rails de gestionar la base de datos es, quizá, lo que más me guste del framework.
- Las gemas (Ruby Gems). El concepto de Gema es un paso mas en el concepto de librería, mientras que una librería nos permite añadir funcionalidad a nuestros programas, normalmente mediante una colección de clases y métodos que podemos usar, una gema va un paso más allá, una gema se centra en una funcionalidad concreta y la integra en Rails, de forma que ni siquiera tienes que preocuparte de todos los métodos y funciones que tienes para construir funcionalidades, sino que tienes la funcionalidad directamente accesible directamente en tus controladores o en tus vistas, muy a groso modo, y por favor, perdonad la comparación, solo es para que lo entendáis, es como instalar un plugin en WordPress, normalmente te aporta la funcionalidad en el framework sin tener que programarla, lo que acelera mucho programar cosas específicas.
- HAML. Este ha sido un gran descubrimiento y me ha hecho enamorarme, en realidad es una gema, y no es exclusivo de Ruby on Rails aunque es donde más se usa hasta donde yo sé. HAML es una abstracción del lenguaje HTML, no voy a entrar en detalles, pero si conoces HTML, por favor, échale un vistazo a este tutorial de HAML, no son más de 5 minutos y te aseguro que si no te enamoras de HAML es que estás muerto por dentro. La cantidad de horas de programación que me he ahorrado no sabría decirlas, y lo limpio y claro que queda un archivo HTML, tienes que verlo, te dejo que te convenzas por ti mismo.
Por ahora voy a mencionar solo estas, que han sido las que finalmente me han hecho decantarme por este framework y este lenguaje de programación, Ruby. Aquí me ha pasado un poco lo contrario, ha sido el framework el que me ha hecho decantarme por el lenguaje, ya que debo reconocer, que como lenguaje, Python me gusta más que Ruby, pero desde hace un tiempo ya me siento mucho más cómodo con Ruby, no descarto, más adelante, volver a coger Python y darle otra oportunidad, pero por ahora, y durante un tiempo, mis proyectos van a ir en Ruby on Rails. Ya tengo algún cliente agradecido por esta decisión, os iré comentando algunos proyectos para que veáis las posibilidades de este lenguaje.
Me encantará oír tus comentarios al respecto, si piensas que llevo razón, si quieres darle una oportunidad a Rails, si piensas que estoy loco y que no tengo ni idea de lo que hablo, en fin, cualquier comentario desde el respeto será bienvenido.
Un saludo
Ahora te digo yo el motivo de porque no usarlo, esta muy bien que no quieras crear dependencia con la base de datos, peroooooo cosas que no permite y no tiene sentido que no te deje hacerlo sin hacer trampas, primero no te deja definir el campo que a ti te de la gana como timestamp es decir solo puedes meter t.timestamps y el te crea el created_at y update_at, si somos puristas no puedes usar secuenciales a dia de hoy que todo necesita secuenciales incluso para cuando no necesitas crear una tabla con una unica columna que te devuelva un valor unico para poder asociarlo a varios registros por ejemplo, como un codigo de envio, los secuenciales existen desde sql85 una cosa es querer que funcione en cualquier base de datos y otra muy distinta atarse al pasado, y otra cosa que no me gusta se carga por completo el modelo entidad relacion de la base de datos utilizandolo como un fichero de texto plano con sql, lentitud grave en tablas grandes o con muchas relaciones, motivo, la relacion la hace a nivel de programacion no existen constrains como tales, solo las basicas de no ser null y demas, pero eso es otra cosa que me escama dice de no querer utilizar cosas propias de bases de datos, pero eso no lo hace ya el adaptador?
es decir el adaptador de base de datos es el que se encarga, pues crea algo que sea un secuencial en tu codigo y luego lo traduces en el adaptador
en su dia creamos una gema para oracle pero nos encontramos con otra limitante pero ya no de bbdd sino a nivel de lenguaje ruby no diferencia entre vacio y nil con lo cual para utilizar oracle tienes un problema. db2 lo mismo sql server creo que también diferencia, con lo que no puede usarse ruby on rails directamente en una empresa grandecita en la que suelen utilizar uno de esos 3 servidores de bases de datos, con lo que hasta que no se solvente esto para mi ruby on rails solo servirá para los arranques de pequeñas y medianas empresas por ser barato, pero en cuanto la empresa crece un poco y empieza a fallar por numero de registros acaba siendo desechado sobre todo por su rendimiento pero no ya por el rendimiento del lenguaje en si sino por el rendimiento de como hace las cosas a nivel de base de datos que para mi es pésimo, cada cosa es para lo que es el mvc esta bien para lo que es pero no quieras hacer pasar una cadena de bicicleta por una polea porque hijo mio la cuerda siempre correrá y deslizara mejor en la polea que la cadena de bicicleta por muy robusta que esta sea.
Hola Antonio, excelente artículo, ahora mismo estoy tratando de decidirme entre Python con Django o Ruby con Rails, tu artículo es de hace 3 años y quería consultarte si en la actualidad (2019) y con tu experiencia me recomiendas elegir Ruby on Rails; saludos y de antemano te agradezco por tu ayuda.
Muy buenas Gabriel, gracias por comentar en primer lugar, en segundo lugar y respondiendo a tu pregunta, definitivamente si, te recomiendo Ruby on Rails. Vamos a ver, ambas son buenas opciones pero, desde mi punto de vista, Rails es muy agradecido, es muy rápido y cómodo desarrollar con Rails. Yo sigo trabajando con Rails desde hace bastantes años. Además, las salidas profesionales de Rails son muchas, creeme, muchas, los desarrolladores de Rails están muy demandados y bastante bien remunerados, así que, adelante. Por otra parte, si te gusta el tema del big data y te gustaría orientar tu carrera profesional hacia ese campo, en ese punto Python es la mejor opción, es un lenguaje que se está enfocando mucho en ese campo del análisis y procesamiento de datos. Como ves, en esto no hay nunca una respuesta absoluta, todo depende de lo que quieras hacer. Espero te haya resultado útil, en el podcast tengo algunos programas en los que hablo de rails, incluso con algún invitado de Python.