Hace un par de semanas pusimos online la versión 2.0 de certificacionpm, un simulador de exámenes para sacarse la certificación de Project Management Professional del PMI® que hemos desarrollado para con la empresa Lanarvi.
No lo publico aquí para hacerle publicidad (no creo que, por lo general, el público de este blog sea público objetivo de certificacionpm) pero puesto que la versión anterior estaba desarrollada en Java (JSF + JDO) y esta lo está en Rails, dos personas me han pedido que de forma poco sectarista explique las diferencias/mejoras/razones. Y lo voy a intentar.
Primero, a modo de disclaimer, decir que esta comparación es un tanto injusta, puesto que una migración siempre es más sencilla que hacer algo desde cero, puesto que ya llevas mucho aprendido. Aún así, una migración siempre hace también que acabes metiendo cosas nuevas. También podría ser que con otras herramientas Java el resultado hubiera sido distinto o ahora no hemos tenido que dedicarle excesivo tiempo a cuestiones de diseño/CSS. Digo esto porque no es tan sencillo como partir desde cero con el mismo conocimiento y realizar la aplicación. He intentado tener esto en cuenta y reducirlo a la parte de la lógica de la aplicación.
Diría que el tiempo empleado en el desarrollo en los aspectos comparables en la versión Rails ha sido aproximadamente el 40% del empleado en Java, quizás un poco menos. Las razones principalmente las siguientes:
- Active Record: nunca trabajar con la base de datos fué taaaaaaaan fácil. En serio, es para probarlo. Me quedo con la espinita de JPA, pero ni SpringDAO, ni Hibernate, ni JDO lo hacen tan sencillo.
- CSV: el soporte que trae Rails de serie para tratar ficheros CSV es increible. En Lanarvi gestionaban inicialmente el banco de preguntas en una Excel gigante, y lo cierto es que lo que con Java era un cierto sufrimiento, con Rails se solucionó en una tarde.
- Lenguaje no tipado. Mucho tiempo pensé que la compilación y los lenguajes tipados eran necesarios (?) para prevenir errores, que eran una ayuda. Lo cierto es que sobre todo para proyectos pequeños he dejado de creerlo. Tienen un coste que no compensa. El tiempo de compilar, probar, etc. es demasiado alto para el beneficio obtenido en este proyecto.
- Rails es (o puede ser) un todo. No sólo el framework de desarrollo, sino también el despliegue en remoto (caspistrano), la gestión de actualizaciones de la base de datos (migrations), etc. Reduce el tiempo destinado a estas cosas accesorias.
- El entorno de desarrollo. Reconozco que mi pobre Powerbook con 1,2GB de memoria ha pasado ya los 3 años, pero ha rejuvenecido un par de años en rendimiento al cambiar Eclipse+Java+Tomcat por Textmate+Ruby+Mongrel.
En todo caso, como nota final. En Lanarvi están contentos, pero os puedo asegurar que lo que menos les importa a ellos es la tecnología, sino simplemente que ahora tienen una mejor aplicación.
Por cierto, que espero que próximamente liberemos el código de la aplicación (que no las preguntas) como software libre. Es bastante genérico y se puede reutilizar para hacer más simuladores. Estamos que lo tiramos XD.
Buff, mira que mala suerte que leo esto ahora mismo. Cuando descubres que tu lenguaje dinámico of choice (fill here the gap) con su super framework de persistencia of choice (fill the other gap here) se toma la licencia de crear y rellenar automáticamente dos atributos como lastUpdated y dateCreated, de los que tú no tenías ni idea que existían, para ofrecerte “automatictimestamping” (toma eso), y encima se da la casualidad de que uno de esos nombres es el que has usado tú para uno de los atributos de una clase en tu modelo (porque son nombres bastante comunes), y te pasas dos horas pensando porque diablos no se insertan las fechas que quieres en la base de datos, y te lamentas de no tener herramientas, y de no poder depurar decentemente, y de que el dichoso framework no lance excepciones como se debe y te informe de lo que pasa, entonces y sólo entonces bajas a todos los santos y le pides perdón a tus (mios) pobres Eclipse y Java y Tomcat por haber hablado mal de él y dudado de ellos.
Lo siento, me tenía que desahogar.
Ahora en serio, mis opiniones respecto a este tipo de lenguajes (aunque mi experiencia es con grails ) son de amor/odio. Es una opinión personal, pero yo, en caso de volver empezar con lo que estoy haciendo ahora, creo que volvería a Java. De hecho, y mira como son las cosas, mientras hacía la comida y en medio del dolor comentado arriba cuando aún no sabía la solución estaba pensado cuanto costaría migrarlo a Spring MVC :D
Por cierto, que dicho esto y pasado el mal trago, el mundo vuelve a ser de rosa y hacer cosas como…
Position.countByDateGreaterThan(fecha)
… vuelven a tener otro color.
Creo que se entienden los dos mensajes.
Se entiende, Martín, se entiende, aunque quizás el primero de los problemas sea que le has dedicado menos tiempo a aprender grails de lo que antes le dedicabas a Java?.
Sobre Spring MVC… ese es el caso de Tabula iniciado en Spring, paso a paso migrado a Rails. En su momento estuve pensando migrar certiifcaiconpm a SpringMVC, pero me entró más pareza XD. Quizás ese sea otro criterio, el ratio de pereza XD. Las ganas de aprender algo nuevo y hacer las cosas de otra forma también cuentan. Supongo.