Gracias Rails

Gracias a @tomaslin, me encuentro un más que interesante post llamado Thank you, Rails de Jacob Kaplan-Moss, presidente de la Django Software Foundation, con quien no podría estar más de acuerdo!

Es más que habitual ver gente de dentro de una comunidad de un framework inspirado en Rails hacer críticas más o menos feroces hacia el propio Rails, y comparar el framework de turno con Rails para “demostrar” que tiene mejor rendimiento, que escala mejor(en cualquier caso, pienso que sería más correcto decir que es más fácil escalar), etc., afirmaciones que pueden ser más o menos reales, aunque hay por ahí algunos benchmarks/comparativas que hay que cogerlos con pinzas.

A mi, en la mayoría de los casos, me parece una actitud negativa que “enfrenta” comunidades, a ver quien la tiene más larga, y no lleva a ninguna parte. Es mucho más inteligente observar, aplaudir y por qué no copiar o adaptar, los avances de frameworks diferentes al “mío”.

Para mi, el gran mérito de Rails, además de que se haya creado una comunidad más que interesante alrededor suyo, es que replanteó a muchos como se llevaba a cabo el desarrollo web, y por ello que hayan salido tantos frameworks web que lo han tenido como ejemplo para tener algo similar en otros lenguajes de programación (Grails, Django, CakePHP, Symfony, Roo, Zend, Play!, y otros muchos que me dejo).

Y volviendo al post de Jacob Kaplan-Moss, agradece principalmente dos cosas de Rails:

  • La programación debe ser divertida(pienso que Ruby dentro de Rails tiene mucha culpa en este punto): Creo que la mayoría que nos metimos en este mundillo, lo hicimos porque nos parecía que iba a ser divertido (bueno… otra razón era que la informática era el futuro y se iba a cobrar mucho dinero XD).

    Jacob habla de que la comunidad Python a veces se toma a ella misma demasiado en serio: necesitaba ser un lenguaje serio, usado por gente seria, para empresas serias y grandes desarrollos(a.k.a. “enterprisey”).

    Y llegó Rails para recordar que el desarrollo web debería ser algo divertido, la comunidad Rails en general desprende que se pueden desarrollar productos pequeños, divertidos, ligeros y además hacer dinero con ellos.

  • La simplicidad es una feature, o lo que sería menos es más: Pone como anti-ejemplo el caso de los CMS y la típica obsesión de cubrir el máximo de casos de uso posibles, terminando siendo productos mastodónticos. Aunque no exclusivo de los CMS, seguro que muchos de los que hemos trabajado con gestión de contenidos, lo hemos vivido.

    Rails, por un lado no pretende cubrir el máximo de casos de uso reales, para eso hay plugins que pueden facilitar la vida; y por otro, es un framework opinado (aquí entra lo de Convention over Configuration ;)). Lo que quiere decir que el framework tiene un funcionamiento por defecto que no es necesario configurar, para ahorrar decisiones al desarrollador, lo que lo hace más simple.

    Resumiendo, gracias a Rails, estos nuevos frameworks tratan de minimizar el trabajo “genérico” de los desarrolladores, sin querer llegar a cubrir cada caso de uso.

¿He dicho que el lenguaje con el que más he trabajado(y sigo trabajando) es Java? Considerado uno de los lenguajes más “serios” y más complejos en cuanto a configuraciones, especificaciones… pero sobre todo en la forma que se ha venido utilizando. Y gracias a Rails han aparecido algunos frameworks web interesantes como Grails o Play!, y creo que algunos otros de los que no hablo porque no tengo suficientes referencias, que son más divertidos y minimizan el trabajo.

Por esto, además de porque he trabajado con Rails y que tengo pendiente retomarlo XD, gracias!

2 comentarios en “Gracias Rails

  1. Hola, felicitaciones por el blog, tengo una consulta sobre Grails, ¿al generar un war los fuentes groovies son compilados a .class como si fueran clases Java? ¿En tiempo de ejecución hay código interpretado que penalice la performance si lo comparamos con un war tradicional?

    Gracias

    Federico

  2. Hola Federico.

    Sí, el war no tiene nada raro, las clases groovy se compilan a bytecode igual que las clases java.
    Y en los war no existe código interpretado, aunque es posible que tenga algo menos de performance que otros frameworks java puros, principalmente por que la “magia” de groovy evidentemente tiene un coste. Aunque hay que tener en cuenta que el principal cuello de botella de las aplicaciones web, tanto para escalar como para mejorar la performance, suele ser la base de datos(optimizar queries, índices, cachear, desnormalizar…).

    Pero bueno, yo te recomendaría que pruebes, compares y decidas :)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>