Evolucione en el mundo Open Source

Antes era un usuario agradecido que trataba de convencer a otros de los beneficios. Mis únicos aportes eran reportar bugs en algunos proyectos como Resin/Magnolia y participar en algunos foros.

Ahora, tengo mi proyectito, un widget /lifweb/ para usar Flot:

• http://code.google.com/p/flot-widget-liftweb/
• http://code.google.com/p/flot-widget-liftweb-example/
  

Un poco de defensa de SOA y XML

Otras malas noticias para SOA. Ahora declaran que su uso aumenta el costo de depurar sistemas. Eso es debido al aumento en la complejidad y por el hecho que el re-uso de los servicios no se esta dando como previsto (lo que habría permitido reducir los costos).

Voy a defender SOA en esta oportunidad. Creo que el problema proviene del hecho que cualquier sistema nuevo debe interoperar con sistemas pre-existentes. La interoperabilidad es un tema complejo y antes de SOA/Web Service/REST las soluciones eran caras, propietarias y requerían de ingenieros altamente especializados: quizás por eso, no se integraba tanto los sistemas como ahora. Entonces, creo que el costo de depuración aumento porque, ahora, hay capas de código a depurar que antes simplemente no existían.


XML bajo ataque. Google introduce Protocol Buffer el cual define un nuevo IDL y un protocolo binario para intercambio de datos en reemplazo de XML. Personalmente, no creo que Google tenga mucho éxito con esta iniciativa y tampoco se si es mejor que XML para los programadores. Este articulo tiene varios links relevantes y estoy 100% de acuerdo con la entrada de Ted Neward.

SOA no deja de intrigarme

Esta semana hubo dos noticias casi contradictorias:

• solamente 20% de los proyectos SOA tienen éxito
  
• El mercado SOA va a doblar en los próximo 4 años

Lo que más atrae la atención son las razones que hacen exitosos un proyecto SOA. Aquí esta el copy/paste del primer articulo:

• Business and IT reorganization, usually with a new CIO coming on board
• Sponsorship at the C-level or by the Board of Directors
• Agile/iterative development methodologies put into place
• Projects tied to and measured by business goals, not IT drivers
• Well-defined funding and maintenance models that balance the needs of service providers and consumers
• A simplified architecture, making it easier to access and manage quality data
• A culture of trust between business and IT

Parece que son proyectos tsunami que involucran toda la empresa y crean cambios radicales. Quizás por eso hay poco éxito: porque se requiere un liderazgo técnico y comunicacional poco frecuente. Por ejemplo, el hecho que un nuevo CIO tiene más posibilidad, me suena que es gracias al tiempo de credibilidad que una persona tiene poco tiempo después de asumir un cargo; luego te pasan la cuenta por todos los errores cometidos.

El punto 3, el de uso de metodologias agiles, es compatible con la forma que abordaría este tipo de proyecto: "pensar en grande, empezar chico".

Finalmente, no se si tendré el carácter necesario, para decir "primero, Ud tiene que renunciar" a un gerente de informática.

Tranquilo, no he abandonado Java...todavía

En una respuesta a mi ultima entrada, Jorge me pregunto porque no aprendí Ruby o Python en lugar de Scala. Es una buena pregunta y voy a tratar de responderla.

Primero voy a pedir permiso para contar mi ultimo gran aprendizaje tecnológico, o sea, cuando aprendí Java. Eso fue en mis tiempos "heroicos" cuando use Java en su versión 0.93a para hacer un sitió web. En la misma época:

• no existía Microsoft Internet Explorer,
• Netscape no soportaba las applet todavía: solamente Hotjava de Sun lo hacia.
• No existían las API's Java empresariales (Servlet, EJB, JNDI, JDBC, etc).
  
• No existía JVM para Windows y mucho menos para Linux, AIX, etc.
  

Entonces, era una aplicación CGI que llamaba a la JVM desde una shell en Sun Solaris. La aplicación Java realizaba cálculos que migre desde una biblioteca C++.

Estoy contando mi historia de viejo combatiente de la programación porque creo que refleja los ingredientes que se requieren para que un lenguaje sea exitoso:

• un grupo de programadores entusiastas dispuestos a arriesgarse,
  
• una tecnología que mejora significativamente lo que había antes. Es ultra sabido que Java mejora el uso de la memoria de C/C++ y simplifica la sintaxis de C++.

Pero, faltan otros ingredientes. Mi cliente era bastante conservador para sus decisiones tecnológicas, su infra-estructura era de tipo COBOL-CICS mainframe con algunas aplicaciones no criticas en MS-DOS y nada de cliente-servidor ¿Que hizo que este cliente me aguantará una innovación tan drástica? Super simple, la web: tenían que tener el sitio ¡ahora ya! y todo era nuevo para ellos de todas formas. La web fue la "killer application" que hizo posible el gran éxito de Java..

El último ingrediente, es la comunidad de empresas que Sun logro juntar: hasta Microsoft participo en el éxito inicial.

Basado en argumentos equivalentes, este blogger cree que Java va a morir de viejo antes de ser destronado por otro(s) lenguaje(s). Creo que tiene en gran parte razón y es por eso que no renuncio a Java.

¿Entonces, porqué hago el esfuerzo con Scala? Porque, a diferencia del blogger, creo que estamos a punto de ver otra "killer application" para la cual Java tiene defectos como lenguaje. En una entrada anterior, aposte que las bases de datos van a sufrir los efectos de un escalamiento en el volumen de transacciones y este mismo impacto va a llegar a los servidores de aplicación y sus lenguajes. Por otra parte, ya no se puede aumentar la frecuencia del reloj de la CPU, pero la ley de Moore sigue vigente y ahora aumenta el número de core: vamos a necesitar multi-threading en los desktop también. Por estas razones, se va a requerir lenguajes que facilitan la programación concurrente. Y eso es un punto debil para Java:

• el lenguaje usa "monitores" basados en lock. Es un modelo que tiene limitaciones conocidas
  
• Las framework y API's vienen al rescate del lenguaje y alivian el problema en el servidor: por ejemplo EJB provee escalabilidad "a bajo costo" (el programador no tiene que preocuparse de sincronizar el acceso a metodos). Todo eso funciona, mientras no se requiera paralelizar el procesamiento interno de cada requerimiento HTTP.

El lenguaje Erlang. ataca el problema de raíz: se basa en objetos que se comunican vía mensajes y sus threads no pueden compartir estado (un objeto mutable). STM es otra técnica muy de moda también. Cuando fui a mirar ejemplos para entender los conceptos, ¡no entendí nada de nada! Erlang y Haskell (donde encontré ejemplos de STM) son lenguajes funcionales que nunca había visto antes: completamente marciano para mi. Entonces, tenia que aprender a usar programación funcional y lo mejor que encontré fue Scala. Eso porque no tenia que renunciar:

• a la orientación al objeto,
  
• a la programación genérica,
  
• al estilo imperativo (aunque entendi que tenia que dejarlo poco a poco para obtener los beneficios del lenguaje),
  
• ¡al static typing! Eso es la razón principal de eligir Scala sobre Ruby, Python o cualquier lenguaje dinámico.
• a las biblotecas Java que ya conozco (como JPA),
• a la JVM y los servidores de aplicación que mis clientes saben administrar
  

Finalmente, Scala provee mecanismos equivalentes a Erlang a través de su biblioteca de Actores y Terracota esta dando el soporte de cluster.

En resumen:

• no veo ventaja significativa usar otro lenguaje para aplicaciones web. Java, JEE, sus IDE's y sus servidores de aplicación estan ok. Excepto si los clientes piden otra solución (como .Net, PHP, Ruby, Python), me quedo con Java.
• la interoperabilidad de Scala con Java permite fasear el aprendizaje,
• La programación concurrente es el talón de aquiles actual de Java (como el manejo de la memoria lo era para C y C++),
• la tormenta de transacciones es la "killer application" para algunos lenguajes y Scala también esta posicionado sobre este terreno.
  

Primer proyecto Scala y ¡sin Dependency Injection!

Use el ORM estándar de Java (JPA), el framework web LiftWeb de Scala, pero de DI... nada de nada.

Es un poco normal, porque es solamente la maqueta del proyecto y no amerita usar todavia el "señor de los framework", el que los ata a todos. No obstante, no me hizo falta ni un segundo, incluso para crear un Entity Manager por HTTP Request, donde en Java, me acostumbre usar Guice y Warp-Persist. Para cubrir esta necesidad, LiftWeb vino al rescate, junto con una buena documentación (ver el capitulo Per Session Entity Manager).

Ahora que entre en la segunda fase del proyecto, con la maqueta aprobada, voy a tener que manejar más transacciones y es una oportunidad para usar algo como la anotación @Transaction de Warp-Persist sobre Guice. Así que busque un framework de DI para Scala o como integrar con uno de Java. Y, o sorpresa, encontre que no son tan necesarios porque el lenguaje provee mecanismos que los hacen menos relevantes.

Primero lei esta entrada del artista del DSL y luego las referencias: una conversación en un foro y este documento del creador de Scala. Finalmente, leí de nuevo el comentario del "Loco Bob" (no es un chilenismo, es la traducción literal de "Crazy Bob", el autor de Guice): en la página home de su framework:

You might think of Guice as filling in missing features for core Java. Ideally, the language itself would provide most of the same features, but until such a language comes along, we have Guice.

¿Será tan bueno Scala, que puedo decir adiós a los framework de DI? Ojala que si.

¿Me perdí 20 años de la historia de la computación?

En esta noticia, se reporta que un empleado de Microsoft que fue a trabajar a Google durante un tiempo, declara que Google no tiene el espíritu necesario para crear aplicaciones "empresariales". Su argumento es que la cultura Google favorece la "buena onda", lo "novedoso" sobre la calidad y la estabilidad como la esta haciendo...Microsoft.

Tengo alzheimer porque no recuerdo cuando Microsoft hizo también este switch de "buena onda" a "seriedad/calidad".

Cuando Bill Gates hacia presentaciones al principio de MS, los reporteros calculaban cuantas veces decía la palabra "cool". Luego, siempre MS ha favorecido facilidad de uso sobre seguridad: eso explica porque DOS y todos los Windows desktop hasta Windows Me no tenían ningún tipo de protecciones contra viruses, troyanos y demases. Porque era demasiado difícil crear driver's para Windows NT (porque, al fin había algún tipo de protección), MS levanto las restricciones en Windows 2000, 2003, eso hizo que el sistema operativo sea más frágil frente a errores de terceros. Ahora, MS SQL Server permite invocar cualquier rutina del sistema operativo: eso es super cool para los desarrolladores pero permite tomar control completo del servidor vía SQL Injection.

Hasta lo que recuerdo, MS siempre ha favorecido facilidad de uso sobre estabilidad.

¿Ahora, eso esta mal? El exito de Windows demuestra claramente que el mercado no ha castigado a MS por eso.

¡Le va a ir bien a Google entonces!

Primer proyecto con Scala

Ya estoy usando Scala para un proyecto real. Se me dio la ocasión tan esperada de probarlo, gracias a varios factores:

• la aplicación tenia que generar mucho XML, o más concretamente, mucho KML (el lenguaje para describir capas georeferenciadas de G.Earth). Como yo sospechaba que Scala se destaca en eso, era el momento de probarlo,
  
• tenia que hacer una maqueta rápida para fijar las expectativas del proyecto. Había que comprobar que tan ágil es el lenguaje y el framework Liftweb
• el proyecto esta clasificado como "innovación tecnológica" por el cliente. Si bien la innovación esta relacionada con el uso de GIS, es también la ocasión de innovar en otros temas.
• desde el año pasado estoy leyendo tutoriales, blogs y artículos sobre este lenguaje y lo encuentro realmente interesante. Me picaban las manos por usarlo.

Sabia que iba a tener que acostumbrarme a varios temas:

• la sintaxis. Scala es un lenguaje que mezcla programación orientada al objeto y programación funcional. No soy computín de formación y nunca me enseñaron lenguajes como LISP.
• el uso de nuevas API's, Scala tiene la reputación de tener un sistema de tipo de datos (type system) mejor hecho que Java, había que probarlo.
  
• un nuevo entorno de programación: editor, compilador, utilidad make, debugger, profiler. Scala no esta todavía completamente integrado con los IDE's de Java (Eclipse, Netbeans)
  
• aprender a usar frameworks hechos para Scala:
  
• web (el equivalente de Struts, JSF, Wicket en Java),
  
• ORM (el equivalente de JPA, Toplink, Hibernate en Java).
• integración con Java: si el cliente me rechaza el uso de Scala para la implementación final, tengo que poder revertir a Java rápidamente. Idealmente, la lógica más coimpleja tenia que estar codificada en java.

Tema sintaxis

Fue más fácil de lo que había previsto. Sin lugar a duda, ayuda bastante que Scala sea de tipo "Strong Typing" y que el compilador captura muchos errores. También, ayuda bastante la capacidad de "syntax highlighting" del editor: sin eso, sería penoso reconocer el XML dentro del código Scala.

Tuve algunas sorpresas con el "type inference" cuando se usa junto con "implicit parameters": yo esperaba transformaciones de tipo que nunca ocurrían, el compilador no arrojaba errores y la aplicación fallaba durante la ejecución. La solución entonces fue explicitar el tipo de datos que yo esperaba.

Todavía me quedaron algunos metodos usando el estilo imperativo (algunos loops "for"), pero no encontré tan difícil usar closure, listas, (con flatMap(), foldLeft), case class y pattern matching

Ahora, empezó a leer código de terceros y no lo encuentro marciano. Eso es un buen signo.


Uso de nuevas API's

Eso no es difícil pero es demoroso. El hecho de no tener un IDE con "code completion" no ayuda porque hay que bucear en los scaladocs. Tampoco me ayudo el hecho que muchos ejemplos (en particular los de Liftweb) son fragmentos del archivo fuente y no muestran los import necesarios. Menos mal que existe "San Google" para encontrar el código fuente donde estaban los métodos que ya veía en los ejemplos.


Nuevo entorno de programación

Volví a usar jEdit usando este plug-in. Lo encontré más completo que la solución para Eclipse y Netbeans. Ya dije que eche de menos el "code completion" y gracias al hecho que conozco bien jEdit, pude arreglármela con la ausencia de "refactoring". No he tenido que depurar o hacer profiling.

Para LiftWeb tuve que usar Maven. Ya lo había usado antes con Magnolia y Alfresco (dos CMS's hechos en Java). ¡No deja de asombrarme que cada vez que se ejecuta por primera vez, parece que descarga la internet entera! Tuve algunos problemas para referenciar bibliotecas de Oracle (el driver JDBC y TopLink), al final, las instale a mano en el repositorio local de maven.



Reemplazar frameworks de Java

La decisión es rápida porque no hay muchos. El único framework web es LiftWeb.

También es un ORM pero:

• no me gusto. No se explicar porque.
  
• quería mantener la lógica de negocio en Java, entonces era más fácil mantener también el modelo de dominio en Java.
• es muy fácil usar JPA dentro de un IDE Java.
  
• hay buena documentación para integrar JPA con LiftWeb
  

La implementación de RESt en LiftWeb es espectacular y eso me ayudo bastante para retornar KML vía HTTP para el cliente G.Earth.

LiftWeb es como el framework Wicket de Java, no hay posibilidad de lógica Scala dentro del código XHtml. Pero, es fácil que código XHtml se inscruste dentro del código Scala. Por ejemplo, para desplegar un maestro/detalle de 3 niveles (maestro -> detalle1 -> detalle2) recibiendo el id del maestro como parámetro de la pagina, tuve que dejar el XHtml del detalle1 y detalle2 dentro del código Scala. No es tan grave, gracias al hecho que Scala soporta tan bien XML, pero no es elegante (no hay separación total entre el diseño web y la programación).

Finalmente, el uso de LiftWeb me hizo descubrir unas bibliotecas Javascript muy buenas: jQuery y Flot. Se nota que es una comunidad muy entusiasta y muy al tanto de las últimas novedades.


Integración con Java

Ya mencione que uso JPA para mis clases de dominio. Uso Netbeans para crearlas e interactuar con la BD. Como costumbre dejo que TopLink, la implementación JPA de Oracle presente en Netbeans, cree las tablas/indices y poblo las tablas usando test unitarios. Cada vez, veo menos SQL.

La documentación para integrar JPA con Scala es muy util. Menciona las conversiones entre colecciones de Java hacia listas de Scala. Lo que no menciona es la necesidad de convertir objetos nulos (por ejemplo una búsqueda por id que no retorna nada) a objetos tipo Option[Entidad] en Scala. Para facilitar todo eso, deje en un solo objeto Scala (Model.scala) la responsabilidad de conectarse con JPA y retornar listas y objetos más fáciles de usar en Scala: es una capa DAO muy común en Java.

Todo funciona bien, pero echo de menos:

• un refactoring iniciado en Java que gatilla cambios en Scala (obvio, tenia el código Java en Netbeans y Scala en jEdit),
• un procedimiento de recompilación más limpio: mi procedimiento usa el soporte ant de Netbeans, luego sube el jar a repositorio local de Maven y finalmente ejecuta Maven para compilar Scala. Supongo que puedo mejorar eso, pero no es una prioridad.
  

Otras consideraciones

Porque Scala es un lenguaje compilado, existe todavía un tiempo entre editar el fuente y ver el resultado en el browser. En un lenguaje más dinamico (tipo Ruby, PHP, Python), el turn-around es más corto: se guarda el fuente y se refresca la página. Es evidentemente una ventaja de estos lenguajes, pero:

• quizás algún día Resin soportará Scala y nos dará el Zero Turn Around que siempre nos ha dado con Java, JSP y recientemente con PHP,
• otros servidores de aplicación JEE, consientes de esta ventaja de estos lenguajes, también mejoran el tiempo necesario para refrescar las aplicaciones y para rebootearse por completo. Por ejemplo, el proyecto Glassfish esta muy preocupado de este tema
  
• JavaRebel regala su producto para desarrolladores Scala,
• mientras tanto, prefiero mil veces esperar que el compilador trabaje por mi antes de buscar errores muy extraños al momento de ejecutar. Estimo que perdí en total 2 horas esperando ant, javac, maven, scalac y el rebooteo de Tomcat. Creo que habría perdido días resolviendo algunos errores oscuros de tipeo.
  

Se puede usar un editor de archivo (como notepad o vi) para desarrollar en Scala y Liftweb. Eso es una buena medición de lo simple que es. En comparación un proyecto EJB 2.1 requiere generar código intermedio y mantener archivos de configuración XML demoniacos: sin un IDE es realmente una pesadilla.


Conclusión

Scala y LiftWeb simplican el desarollo web y en particular el tema de XML (fácil, era tan horrible...). Es muy temprano para saber si mi inversión en aprenderlos valió la pena: va a depender cuantos clientes estan dispuestos en innovar. La interoperabilidad con Java (y también con :Net) es fundamental para romper la barrera de adopción.

Le vendría bien un soporte de excelencia en los mejores IDE del mercado. El plug-in para Netbeans estaría fuera de beta en Agosto, no hay mucho que esperar.

Easy XML

No soy un amante de XML y de sus abusos.

Pero, comprobe que cuando el uso de XML es incontornable, Scala realmente alivia el trabajo. Eso fue durante un proyecto donde tenia que generar KML para integrar la aplicación con G.Earth. Puedo solamente imaginar la lata que habría sido hacer lo mismo en Java, incluso con la ultima versión de JAXB, la cual es basada en anotaciones y bastante mejor que todas las alternativas anteriores..

Hay que reconocer también que XML tiene una ventaja: hay buenas practicas documentadas de como trabajar con el. Estoy 100% de acuerdo con los anti-patrones XML mencionados en este articulo. En particular, el ultimo anti-patrón es muy común en los archivos de configuración JEE, Spring y otros (ver el párrafo "Key Value Lookup").