“More than forty percent of ThoughtWorks’ new consulting projects in the U.S are now developed using Ruby on Rails.” (enlace)

Esa frase, de ThoughtWorks, una empresa internacional de consultoría tecnológica, refleja el imparable aumento de Ruby on Rails en el sector empresarial, y como, poco a poco, se empieza a hacer un hueco entre lenguajes tan conocidos como Java o .NET

Hasta ahora, RoR (abreviatura para Ruby on Rails) no era demasiado conocido por gente que no estuviera muy en el ajo, o al corriente de lo que se mueve en desarrollo web. Yo he tenido que explicarles a todos mis compañeros de trabajo a los que he mencionado RoR, qué era, para qué se usaba, y por qué era interesante echarle un ojo. Ninguno lo conocía.
Ahora están más sensibilizados con la tecnología y, a cada poco, encuentran referencias al lenguaje e incluso empiezan a sentirse atraídos (sobre todo a raíz de que mi proyecto web 2.0 que saldrá a la luz en breve (espero) esté desarrollándolo en RoR).

Su potencial es enorme. Yo, como desarrollador J2EE con más de 3 años de experiencia, se lo veo, precisamente por el agotamiento y asqueamiento que muchos programadores J2EE empiezan a tener, al ver que los proyectos se hacen eternamente largos, monolíticamente complejos y poco mantenibles, y además se requiere conocer 101 frameworks y tecnologías para escribir un simple “Hola mundo” hoy en día en cualquier empresa.
Y eso sin contar que a veces nos gusta un soplo de aire fresco, y no hacer siempre lo mismo.

Sólo basta echar un ojo a cualquier oferta de empleo para ver que te piden J2EE si… y dominio de Struts, Hibernate, Spring y Spring MVC, JSF, JSTL, Maverick, JMS, Log4j y un sinfín de frameworks, herramientas y tecnologías diferentes.
Seguramente luego no las utilices todas, es más, es probable que acabes haciendo una MIERDA de proyecto de gestión de contenidos en Fatwire o Vignette, pero te exigirán todos esos conocimientos.

Yo conozco y he usado muchas de esas tecnologías, y soy consciente de lo difícil que es ser experto en algo, cuando necesitas estar al corriente y, al menos, “desenvolverte” en tantas tecnologías diferentes que se actualizan cada 2 meses. Sencillamente, tu tiempo de aprendizaje es limitado, con lo cuál, picotearás de muchas tecnologías, pero no serás experto de ninguna, o con suerte de 1 o 2.
Al final tu mundo se reduce a Java, y no te saquen de ahí porque ni siquiera conoces otra cosa. Te has cegado durante años y no ves vida más allá de Java.

Con Ruby on Rails es diferente. Se prima el “convention over configuration“. Es decir, si haces las cosas como te decimos, te va a funcionar a la primera, y no vas a tener que tirarte horas configurando nada porque así ya sabemos que funciona y además hemos concluído que es la forma más óptima y DRY (don’t repeat yourself) de hacerlo.
Después, cuando quieras ampliar tu sistema o conectar mil y un plugin que ya ha desarrollado el resto del mundo para cosas desde un paginador hasta un lector de News, no tendrás mayores problemas, pues esos plugin también usan el “convention over configuration” de Rails, y se comunicarán perfectamente con tu código.

En el “core” ya tienes todo lo que vas a poder utilizar para cualquier proyecto mediano y común. Desde el DAO hasta la paginación, pasando por todo el patrón MVC que TE OBLIGA a usar, o el sistema de logging. Igualmente la generación y consumo de servicios XML. Incluso la estructura de tu proyecto para no pensar donde va cada cosa metida.

Pensemos en tener todo eso en Java:

- el DAO a mano o con Hibernate, pero no te da nada hecho,
- la paginación a mano,
- el MVC pues con Spring o Struts (y ojo, su curva de aprendizaje es inclinada si no los conoces de antes)
- el logging pues a menos que te conformes con el System.out.println() usarás Log4j.
- para el XML pues necesitarás currartelos a mano con StringBuffer, o usar (primero aprenderlo) JAXP, Xerces, Dom4j, etc.
- Y luego pensar en como organizar tu proyecto (paquetes, directorios, properties, ficheros de configuración, etc)

Hay una diferencia ¿no?
Además, con Rails, si tienes que meter mano a algo para adaptarlo a tus necesidades, sabrás donde tocar porque las cosas siempre están en el mismo sitio y de la misma forma (si se ha seguido la “convención”). Es más, cuando necesites mantener un proyecto de otra persona, o contratar gente para que te apoyen, éstos se podrán poner manos a la obra en mucho menos tiempo pues como digo, sabrán donde tocar, sin tener que recorrer mil millones de clases, adaptarse a la estructura del proyecto y hacer ingeniería inversa como ocurre con J2EE, donde aunque se intenta mantener unas pautas de configuración standard, sencillamente, por mi experiencia, en la mayoría de proyectos no se siguen.

No pretendo evangelizar a nadie, pero desde luego a mi Rails me está enamorando. Soy completamente autodidacta y, sinceramente, de seguir así, en menos de 6 meses podría cambiar de trabajo a Rails sin ninguna pena de dejar Java después de tantos años.
Creo, humildemente, que después de Java, el lenguaje que a día de hoy mejor conozco es Rails, y eso que aún me faltan muchas cosas por aprender, pero podría desenvolverme sin problemas con mi nivel actual.
Mi proyecto web 2.0 personal, del que próximamente hablaré más, tiene en parte la culpa de que me haya tomado éste nuevo lenguaje muy en serio, y que haya aprendido el doble de rápido y mejor que si lo hubiera hecho de cualquier otra forma.

This entry was posted on Friday, August 24th, 2007 at 10:58 and is filed under Programming, Projects, Rails. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.