26/08/2018 SargantanaCode ¡Hola, Ruby on Rails!

¡Hola, Ruby on Rails!

Aunque puede que no os hayáis dado cuenta, la web del proyecto SargantanaCode ha cambiado radicalmente. Hasta este fin de semana la web estaba desarrollada con PHP, utilizando para ello el framework Symfony (tenéis acceso al código en nuestro viejo repositorio de GitHub), pero todo esto pasó a la historia. Para qué andarse con rodeos si el título ya os hace un spoiler: ¡hola, Ruby on Rails!

Hacía tiempo que entre mis planes estaba mejorar el código de la web, porque no estaba todo lo bien que me gustaría… Pensando qué y cómo hacerlo se me ocurrió que ya que me ponía mejor cambiarlo de lenguaje a uno que me gustase más y aprender otro framework de paso. Esto se tradujo inmediatamente en hacerla con Python y con el framework Django. Conozco Python y me encanta: el lenguaje, su síntaxis, sus guías de convenciones oficiales, la simplicidad con la que pueden hacerse cosas complejas… Atención, opinión personal: pero una cosa es Python, y otra bien distinta Django.

Empecé a informarme sobre cómo trabajar con Django, transformando las ideas de mi cabeza y todo lo que quería implementar a código Django y a la mejor forma de estructurarlo. También quería centrarme en el TDD (Test Driven Development) y especialmente en los tests de aceptación, porque en el anterior código tenía algunos tests unitarios para probar los modelos pero nada más. Sé que me faltan muchísimos tipos de tests por implementar, entre los de más bajo nivel (unitarios) y los de más alto nivel (aceptación), pero tiempo al tiempo. Con esto de momento para este proyecto creo que es suficiente.

¿Y qué pasó después de tanta investigación? Que mi cerebro casi explota. Directamente hacer TDD con Django es un dolor de cabeza. Y para los tests de aceptación… Bueno, había que lidiar directamente con Selenium y esto era algo que no me parecía demasiado atractivo. Además de que la sintaxis de los tests en Django se parece más bien poco a lo preciosa y legible que pretende ser la sintaxis de Python…

Hasta que por casualidad descubrí Rails. Buscando por YouTube cómo hacer algo simple en Django sin demasiado éxito me topé con un vídeo que explicaba cómo hacer eso mismo pero en Rails. No me lo podía creer: super simple, super fácil, legible y todo ordenado. He de decir que la sintaxis de Python me gusta más que la de Ruby (quizá dejar de usar { y } para empezar a usar do y end no fue de las mejores ideas…), pero creo que el trabajo que se ha realizado con Ruby on Rails le da mil vueltas al que se ha hecho con Django. Y aunque en el fondo creo que Ruby no tiene tanta magia como Python, y está lejos de tener unas convenciones o guías de estilo oficiales como la PEP8 de Python, sin duda el framework me maravilló. Así que ni me lo pensé: pasé de página y me olvidé de Django para centrarme en Ruby on Rails.

Y después de este making of sobre cómo Rails llegó a mí, os diré que esta aventura me ha permitido aprender a trabajar con Rails (lógicamente), pero creo que en algunos puntos del desarrollo de una manera más profunda, más allá de las cosas que suelen aprenderse cuando aprendes a utilizar un framework… También me ha permitido conocer RSpec (una de las herramientas para hacer testing en Ruby) y Capybara (una herramienta para hacer tests de aceptación; una especie de capa de abstracción de Selenium). Seguro que en algún momento parte de lo que he aprendido lo plasmaré aquí para que vosotros podáis aprenderlo más fácilmente que leyendo la documentación oficial (aunque esto siempre es una gran forma de aprender).

En la parte que es visible, digamos el frontend de la aplicación, es casi idéntico. Algunos detalles cambian, el CSS está algo más depurado y algunas partes mejoradas pero la mayoría es a nivel de código porque el resultado he procurado que fuese igual ya que estoy contento con el diseño tal cual está y no quería meterme con él en este momento ya que de lo que se trataba era de hacer un cambio del backend. El mayor cambio en los estilos puede ser que en lugar de poner los prefijos -webkit o -ms que algunos navegadores necesitan para visualizar correctamente algunas características de CSS más recientes mediante el uso de mixins en Sass ahora lo escribo sin prefijos y de eso se encarga el plugin autoprefixer para postcss.

La experiencia ha sido muy enriquecedora, aprovechar el verano para aprender algo de forma autodidacta siempre es genial y muy satisfactorio. Y ya sabéis, como siempre decimos en SargantanaCode: ¡nunca dejéis de programar!

Javi Palacios

Javi Palacios

Editor

El primer día que programé supe que quería seguir haciéndolo durante el resto de mi vida. Compilando cosas en Linux desde 2003 y disfrutando de la estabilidad de macOS desde 2006. Amante de la tecnología y del software libre.

Nuevo comentario

Escribe tu nombre y correo electrónico para poder comentar, o inicia sesión para que estos campos se rellenen automáticamente.