Cangu+ROO

ROO

===

Hace una semana me llego mi peluche canguro por recomendar ROO.

Vino acompañado de una tarjeta firmada por Rod Johnson, Ben Alex y dos ingenieros más de SpringSource hoy vmware. Reconozco que me cuesta decir vmware aún.

ROO es un proyecto prometedor que si recibe el apoyo de la comunidad se puede convertir en un "rails" para java.

Algunos dirán entonces porque no irse por rails. Yo también les digo "que bueno fuera", pero, hoy por hoy, muchas organizaciones aún no apuestan por nuevos lenguajes, porque eso significaría re-formular sus estándares y si hablamos de una corporación con sede en distintos países, lo más probable es que nos diga NO y te diga "puedes hacerlo o avísame para llamar a otro".

Grails es un proyecto también interesante. En Perú veo que nos faltará unos años y tal vez nunca se posicione sino se "evangeliza" y se demuestra con productos concretos los beneficios de usar Grails. Como representante general de JoeDayz hemos asumido el compromiso de darle esa oportunidad a Grails, trayendo expositores reconocidos y porque no apuntar al mismísimo Graeme Rocher.

En fin ya me desvíe un poco. ¿Entonces porque ROO?, puesto que ROO es full java, como producto final es lo mismo de siempre. Salvo que ahora potenciado por el lenguaje AspectJ (¿Has leído o practicado algo de AspectJ? Te lo recomiendo, verás los grandes beneficios que te trae y como apoyar a la POO cuando ella ya no sabe que hacer). Entonces tus clientes al final recibirán lo que querían, los estándares seguirán manteniéndose, seguirás con tu sistema de integración continua favorito cómo hudson, maven, y más bien te animarás a desarrollar plugins para ROO. Ahí esta la gran debilidad de ROO frente a Grails. La comunidad está sacando más plugins para Grails que Roo , depende de nosotros de usarlo y lo que siempre repetimos para todos los proyectos hacerlo un plugin para que ROO crezca y podamos entregar software con mayor velocidad sin descuidar la calidad y flexibilidad.

Mi Historia con Spring

===============

En Perú estoy con Spring desde el 2003, he leído y releído los libros de Rod Johnson, de SpringSource, he dictado alrededor de 50 talleres en estos años, a diversas compañías privadas y del gobierno. Me complace ver que Spring ya se ha posicionado. Es hoy por hoy el framework defacto para desarrollos en estas organizaciones.

Algunas siguen con EJBs 2.X, servlets, pero, la tendencia es utilizar spring con uso de estándares como EJB 3, JPA, JSF. La verdad JSF aún no me termina de convencer, pero, si hay quienes lo han vuelto su estándar y ahí esta también la tarea de que ROO genere vistas para JSF , Flex (este último si será una realidad como lo anunció vmware).

Existen otras mixturas cómo el uso de Ext JS, GWT, Tapestry, Struts2, pero, siempre integrandolo con Spring. Hay que felicitar a vmware porque sus proyectos son muy bien hechos y nos facilitan la vida, puesto que si tenemos que integrarnos a un LDAP ya tienen spring ldap, si queremos asegurar la aplicación ya tienen spring security o si queremos hacer web services ya tenemos spring web services, etc.

Oracle si con su ADF Faces tuvo su curva de ingreso, pero, ya por boca de los mismos programadores han decidido apostar por la escalabilidad y mantenimiento y migrar a aplicaciones java con uso de frameworks como spring.

Ahora el reto que se viene y ahí una gran oportunidad de negocio es convencer y demostrar con hechos concretos los beneficios de usar contenedores de servlets o servidores de aplicaciones ágiles y robustos. Que no disminuyan en calidad, performance y tengan el soporte necesario. Veo que la mala campaña que se ha hecho a java no son sólo los EJBs sino también los servidores de aplicaciones que se asemejan a "matar una mosca con un misil", excesivamente caros, lentos, y sin un soporte adecuado. Cuantos han pagado por tener a ORACLE, IBM de su lado, pero, al final terminan con grandes problemas y con presupuestos tremendos. Esto me despierta el interés en un libro titulado "Desarrollo sin Servidores de Aplicaciones Tradicionales" :OP

Así que denle un tiempo en ver el tc server. Se ve prometedor y ya lo venimos usando y no tenemos ningún problema, nos ha reducido tiempo de deployment en ambientes de test y producción, así como para desarrollo.

La comunidad de software libre ha tenido ciertos logros en algunas compañías para recomendar tomcat, geronimo, jonas, jboss, pero, son logros aislados. Ante esa coyuntura han realizado el exodo a otros lenguajes y buscar otros frameworks, con lo cual han dado origen a comunidades cómo python, ruby, php, etc. Lamentablemente nadie quiere apostar por lo inseguro y no por que piensen que la tecnología sea mala, sino, porque las mismas consultoras han sumado un cumulo de errores en su soporte y los Gerentes deciden no pisar en suelo mojado y se van con ORACLE e IBM (sus partners respectivamente).

JoeDayz ante esta situación que no nos favorece viene desde hace varios años generando oportunidades, eventos, networking con los programadores java y aunque hemos tenido un relativo éxito, falta mucho por hacer.

No había visto desde hace varios años el interés por certificarse de la comunidad, y aúnque CJAVA me gano la puesta en mano para ser partner, al final lo importante era tener un canal de llegada para vouchers, los cursos al final lo damos nosotros jajajaja. Ahí no tengo más que agradecer a la comunidad que nos da su total respaldo (10 talleres de certificación a la fecha).

Yo empece con Spring, seguiremos con él un buen tiempo y ahora en provincia. Pero para la segundad mitad del año ya estaremos en el mundo cloud y de dispositivos móviles. Habrá muchísimo trabajo.

Así que escribo también al comentario que me hacen: "en Java hay tantas cosas, que uno no sabe por donde ir". Pues si llegaste a esta última linea sabrás porque te digo esto:

Sigue a la comunidad de vmware + springsource y sus proyectos relacionados. No inventes la rueda y aporta con dicha comunidad para que tengamos el java que siempre hemos querido tener.

No se que hará Oracle para frenar el crecimiento de vmware, ojala no se meta con el JDK, con netbeans u otros proyectos open-source. Si lo hiciese estaría perdiendo su gran inversión de millones de dolares, porque ahí si a mirar otros lenguajes, frameworks, servidores, y con ello se va todo el talento de la comunidad open source y volverá a nacer otro Java.

José

José

Jose