Durante este primer trimestre hemos recibido muchos mensajes preguntándonos por los productos de Peepcode, si íbamos a sacar más, cuando iban a salir, etc. La verdad es que el progreso de este proyecto esta siendo más lento de lo que nos gustaría por diferentes razones. Para empezar, Geoffrey Grosenbach va a ser padre posiblemente esa semana (Congrats Geoffrey!) y obviamente tardará un poco en ponerse al día de tan maravilloso acontecimiento.

Ademas multitud de empresas han seguido nuestro ejemplo y han decidido trabajar con Peepcode para ofrecer más material formativo en otros idiomas, lo cual ha hecho que Peepcode tenga que reestructurar el flujo de trabajo y edición interno que utilizamos los editores y colaboradores. El nuevo workflow estará soportado por git (de hecho en Peepcode tenéis un magnifico screencast sobre este sistema de control de versiones) mientras que el antiguo lo estaba por Subversion, y se adaptará mejor a todas las operación de branching y comparación que debemos realizar. Además todo los chicos cool han empezado a utilizarlo ;-).

Por nuestra parte tenemos prácticamente terminada la traducción de nuestro próximo PDF: Active Merchant.

Para los que no lo sepáis Active Merchant es un librería Ruby para facilitar la gestión de pagos con tarjetas de crédito. Con ella vuestros clientes podrán realizar pagos con tarjetas de crédito en vuestras aplicaciones Ruby on Rails. De hecho es la librería que estamos usando para implementar los pagos en nuestros dos proyectos en curso: Tabula y Stage. Debido a los cambios en el infraestructura que comentábamos antes, la publicación del PDF tendrá que esperar un par de semanas, pero no dudéis que finalmente llegará.

¿Siguiente objetivo?. Con un 99% de posibilidades… Meet Merb, un PDF sobre este interesante nuevo framework que tan buenas críticas esta recibiendo por todos lados. En resumidas cuentas, seguimos trabajando con Peepcode en el lanzamiento de material formativo en Rails de la más alta calidad, para que todos, tanto vosotros como nosotros y la comunidad Rails Hispana en general sea cada vez más productiva, competente y capaz.

Parece que en Google están preparando un buen sarao:

Siempre que veo estas cosas me da una pena tremenda que por este lado del charco las posibilidades de interactuar con otros desarrolladores y empresas sean tan escasas.

En el último año me han preguntado en muchas ocasiones las razones por las que la mayoría (¿todas?) de las cosas que hacemos en Linking Paths las hacemos en Rails. Parece ser que mucha gente no comprende que si yo fundé javahispano ahora lo deje por otro lenguaje. ¡Ni que fuera el primero! (obviamente no lo soy). Pero me voy a permitir explicarme en un pequeño post.

Podría decir que la elección de Rails ha sido más bien circunstancial, causada sobre todo por Aitor (Aitor Garcia, de Linking Paths, ese chico que suele escribir por aquí también), ya que le tenía al lado hablándome todo el día de Rails, y me pareció una buena opción. Y no me arrepiento, es una gran herramienta (no es milagrosa, pero es buena en lo que se supone que tiene que hacer), lo mismo que muchas otras son buenas (hace tiempo que tengo claro que la tecnología no es lo definitivo y lo he dicho por aquí) y lo mismo que con Rails también se pueden hacer barbaridades, ni vale para todo (como nada vale para todo), por lo que no encontrareis aquí sectarismo de ningún tipo. Pero esto es el resultado, no la causa. De modo que, ¿por qué dejé Java?.

Primero. No es que lo haya dejado al 100%, simplemente si tengo que empezar algún proyecto web nuevo, es muy probable que no lo haga en Java.

Y segundo, y definitivo. La razón por la que dejé Java fué que me parecía ya demasiado complicado. Me daba pereza. Tan simple como eso. Tan habitual como eso. ¿No esta el mundo java últimamente loco por Groovy/Grails?. Conozco a muchos javeros de antaño (no, no daré nombres, que lo hagan ellos) que están optando por simplificar sus desarrollos con opciones como Groovy. Otros con JRuby, muchos con Rails, también me he encontrado con gente que realmente respeto que se está pasando al PHP (a este si tengo que protegerlo, pobrecito si se entera la gente), e incluso a alguno que dice que si es sencillo, opta por el antaño maltido jsp-spagetti. Y dentro de unos años volverá a cambiarse la gente, no hay nada malo en ello.

Cuando he hablado con toda esta gente que se cambia, o mejor dicho, que ‘aligera’ el desarrollo Java, todos hemos coincidido: unos por otros lo hemos hecho realmente complicado. Para empezar un proyecto web Java, en la mayoría de los casos “empresariales” (ejem) necesitas conocer el framework web de turno, entre 5 y 10 librerias de Jakarta Commons, el API de Servlets, Spring, Hibernate o similar, ant o maven, 10 patrones, una máquina potente para que tire con el IDE y los plugins, tomcat, etc. Seguramente me dejo un montón de cosas más. Pero es que además tienes que tener paciencia. Compilaciones, redespliegues, heap dumps, etc. Simplemente la mayoría nos hemos ido cansando de eso, porque otras opciones nos permiten aligerarlo. Llámese Rails, Groovy, o PHP.

No hay más, así de simple.