¿Como convencer que es tiempo usar Scala en lugar de Java?

Argumente en una entrada previa que se vienen nuevos tipos de aplicaciones que van a requerir cambios de arquitectura de software, o sea, cambios en los lenguajes y los middleware como servidores de aplicación y bases de datos.  Tengo la suerte ahora de participar en un proyecto asi: es de tipo CEP (Complex Event Processing) y podre usar Scala DSL de Apache Camel.

Esta bien, pero no es suficiente.  Quiero también usar Scala en proyectos web más tradicionales, porque no es todos los días que tengo la suerte de participar en proyectos realmente innovadores.  Por ejemplo, ahora mismo, estoy terminando un proyecto con J2EE 1.,4, Struts y EJB 2.0 para un cliente bastante conservador.  Pensando en este proyecto y el tipo de profesionales con los cuales tuve que interractuar, tengo que aprender a convencer que es el momento de mirar soluciones no 100% basadas en Java y JEE.  

Buscando lo que dicen los pundits en internet me encontré con este articulo de Bruce Eckel.cuyas conclusiones me hacen sentido: 

• Java llego en una etapa donde agregar nueva sintaxis como "closure", va a costar de vez en más . "...the adoption of new Java versions and features is going to continue to slow"
  
• La JVM y sus toneladas de bibliotecas van a ser heredadas por otros lenguajes. "The JVM will be the most important legacy that Java contributes to the computing world. "
• Scala y Groovy estan al acecho para re-utilizar la JVM y sus bibliotecas. "...Scala and Groovy (which play well with Java right out of the box)..."
  
• Hay Java para rato.   "Java itself will continue to be a core workhorse, just as C++ has been..."

No obstante, no estoy completamente de acuerdo en como Bruce fundamenta estas conclusiones. El hace una serie de criticas sobre Java y el rol que cumple Sun de las cuales algunas no son 100% justificadas o otras no son tan graves.

• el mensaje principal es que no se puede confiar en una organización con fines de lucro.  Es probable que si no había existido la necesidad de contrarrestar el dominio que tenia Microsoft sobre los desarrolladores, Sun no habría regalado su lenguaje e IBM no lo habría adoptado con tanta facilidad.   Entonces, compro este argumento pero solamente en parte, porque:
• existe muchos contra-ejemplo de lenguajes que no fueron apoyados por grandes empresas y que tampoco llegaron a un buen destino.  Perl es el primero que me viene en la mente.
  
• esta en las manos de los desarrolladores hacerse desear por las grandes empresas de TI.  Mientras no exista una sola tecnología dominante y que exista competencia por conquistar nuestro interés, estamos bien.

• no haber incluido closure y programación genérica desde el principio.  A mi, me parece una buena decisión de Sun haber aprovechado el boom de la internet.  Un año más tarde habría pasado la vieja, nadie habría sabido de Java y capaz que estaríamos criticando Visual Basic.

• haber mantenido compatibilidad hacia atrás cuando implementaron la programación genérica.  Me parece super razonable la decisión de Sun. Además, la programación genérica es muy practica para usos simples y la eche de menos en mi proyecto J2EE 1.4.

• No se cumplió a 100% el WORA (la portabilidad del binario Java).  Mi experiencia es que un proyecto razonablemente bien hecho es super portable.  En eso, Java esta muy encima de cualquier otra tecnología, incluyendo estándares como SQL, HTML, CSS y Javascript. 

• Implementación en Java de algunas funciones en punto flotante en lugar de usar el coprocesador.  OK, quizás para algunas rutinas matemáticas afecta un poco pero, la semana pasada vi una demo de un software de predicción estadístico con visualización en 3D. Estoy seguro que este software usa muchos cálculos en punto flotante y estaba hecho en Java/Eclipse RCP.  Al agua el argumento excepto para aplicaciones realmente fuera de lo común.

• Finalmente, Bruce termina argumentando que Python es la raja.  Quizás tenga razón, pero Python es más antiguo que Java y solamente orientado al objeto.  Yo creo que se necesita ideas realmente nuevas como la fusión de la programación funcional y la orientación al objeto para realmente dar un salto interesante.

Entonces, no me queda más que buscar otros argumentos.  Parece que va a ser difícil.

Evolución de los servidores de aplicación

Un tipo de SpringSource tiene un articulo muy interesante sobre la evolución de los servidores de aplicación.  SpringSource tiene un talento para hacerme reaccionar en forma negativa y no tengo una admiración incondicional por Rod Johnson .  Entonces, si estoy recomendando leer este articulo es porque lo encuentro realmente bueno.

Antes de propagandar su propia solución, el autor llega a la siguiente conclusión:

A new breed of application server is emerging. This new application server has a small, in-memory footprint. It starts fast and runs fast. It has a highly modular architecture and it can host a variety of services and domain-specific containers. It can respond to directives from a "grid controller" and it can provision, deploy, start, stop and tear down services on the fly. It runs efficiently in an elastic topology that may span heterogeneous physical hardware and virtualized hardware.  

En español:

• los servidores de aplicación se usan ahora para algo más que aplicaciones web dinámicas.  Por ejemplo, algunos productos ESB se montan sobre un servidor JEE para usar el manejo de transacción, la gestión de conexiones SQL/colas JMS, la administración vía JMX/consola Web, etc.  Estos ESB se programan con lenguajes no Java como BPEL, XPath, XSL o algún lenguaje de enrutamiento y enriquecimiento de mensajes propio.
• Un cluster con un número constante de servidores ya no es suficiente.  Se necesita soluciones "elásticas" donde una aplicación puede desplegarse automáticamente sobre nuevos nodos cuando crece su uso y decrece su SLA.  Al contrario, cuando baja el acceso a la aplicación, el sistema controlador de la grilla desactiva la aplicación para dejar más recursos a las demás.

Todo bien, pero no puedo dejar de criticar un poco el articulo, para no perder mi costumbre cuando se trata de SpringSource.

• habría sido bueno que el escritor diga desde el principio que trabaja para SpringSource.  Al principio, creí que era otro apostole de Rod, porque usaba el argumento liviano versus pesado de una forma super marketera.
• a pesar que estoy 1000% de acuerdo que la suite IBM Webpshere es la campeón de la pesadez. hay que señalar que lo que esta logrando SpringSource ahora, IBM lo tiene desde hace 3 años con productos como Webpshere ESB y Websphere XD.  Algunas veces, el pesado le gana al liviano y me parece suicidio dejar 3 años de ventaja a la fuerza de venta de IBM.

El futuro de las bases de datos SQL

Martin Fowler opina que vamos a ver cambios en el mercado de bases de datos.  Ver también el reporte en Infoq.

Su argumento central es que no necesitamos más a las bases de datos para integrar la información de una empresa.  Eso se debe que existen otras tecnologías (XML, Web Service, REST, JMS) que facilitan la integración entre aplicaciones y reemplazan a SQL.  

Es cierto que era una practica en la época cliente-servidor tratar de consolidar todas las tablas en un solo motor de base de datos, porque facilitaba hacer joins entre las tablas de las distintas aplicaciones.  La otra opción era conectar varios motores entre si, con facilidades de store-procedure remotos y SELECT remotos.  El hecho de tener un lenguaje estándar como SQL hacia fácil estos tipos de solución.  Entonces, para variar Martin tiene un buen punto,

La lógica de negocio se fue de los motores SQL hacia los servidores de aplicaciones y como lo menciona Martin la capa de integración también.  Hay una oportunidad de mirar por el lado para ver si hay algo mejor que SQL en algunos casos: SQL ya no manda el mundo TI como solía hacerlo.

No puedo ser indiferente con SpringSource

SpringSource compro G2One, lo cual es un evento suficientemente significativo para mover la blogsphere JEE y llenar foros de conversación.

Las distintas opiniones que aparecieron en esta entrada en TheServerSide  me permiten hacer como un checklist de los temas que ya toque en mi blog y poder compararlo con lo que opinan los miembros de TSS.  

Primero tengo que mencionar que TSS sigue un lugar para peleas entre representantes/fanáticos de jBoss y SpringSource.  En esta oportunidad, Rod Johnson se quedo callado y es Bill Burke de jBoss que fue al ataque.  Pero Spring tiene suficientes fanáticos para evitar que el guro tenga que intervenir.

Ahora, voy tema por tema.

Lightweight vs Heavyweight  

Bill Burke ataco a Spring por ser heavyweight, pero tuvo la mala idea de justificarlo solamente por el tamaño (80 MB) de los binarios de Spring.  Una de las respuestas razonables fue que la pesadez debe medirse con el impacto sobre el diseño de la aplicación.  

"lightweight has nothing to do with the dependency size, rather at how it impacts your application's design and its constraints."

Yo sigo opinando que la pesadez es un termino ambiguo que puede/debe medirse de varias formas:

• estoy de acuerdo con Bill, el tamaña si importa 
• si el contenedor tiene que cargar 80 MB de clases además de la webapp, la partida se va a ver afectada,
• IBM Rational Developper pesa 3.5 GB.  Netbeans con Glassfish pesa 200 MB, es tremenda diferencia para mi ADSL banda estrecha.

• estoy también de acuerdo con Bill, que Spring ahora es heavyweight porque trata de solucionar todo y es funcionalmente tan amplio como los contenedores JEE que lo precedieron.  Eso impacta por ejemplo, el aprendizaje necesario para conocer cada uno de los "Spring-*" y compararlo con otra solución: yo ya he abandonado esta tarea y me quedo con Google Guice por ser liviano y limitado en su alcance (DI y nada más que DI).

Los frameworks de DI son un accidente transitorio 

Nuevos lenguajes como Scala y Groovy los hacen menos relevantes:

"I've been waiting for people to realize that a good, concise dynamic language that provides clean integration with Java largely obviates the need for DI containers and/or allows for much more powerful approaches to DI containers. "

El uso de anotaciones en JEE 5 alivia el desarrollo y reduce la importancia de framework DI.

"Now what is Spring's contrbution to the platform..um... lets see... 

1. A wrapper which is possibly useless with JEE6"

"I love SpringSource's products, but I find them much less needed today than five years ago. RIP, my love! "

Ataques constantes a SUN 

La noticia no tiene nada que ver con SUN pero igual salio al baile:

"Have you been sleeping? Sun is lost in the weeds looking for an OSS strategy...Who better to run with the torch than Spring?"

De nuevo, aparece el tema OpenSource y encuentro increíble que ataquen a Sun por eso.  Antes de cambiarse a OpenSource, la suite Java de SUN estaba completamente inutilizable y moribunda.  Ahora, quizás SUN no gana directamente con su suite de software pero, por lo menos tiene una completa y competidora con IBM, Microsoft, Oracle, Red-Hat, Google.  Es algo estrategico para enfrentar el mercado de "cloud-computing" que viene.  Por otra parte, Solaris esta bien posicionado para aprovechar la explosión del multi-core, lo que dudo que Linux haga con tanta facilidad.

Existe también la preocupación constante por el estado financiero de SUN, la cual comparto a 100%.  De hecho, si los productos no fuesen OSS, no los recomendaría: hay un riesgo no menor que SUN sea comprado por otra empresa y que cambie radicalmente el futuro de sus software.  El hecho que sean OSS los protege de este punto de vista.

Rol de Rod Johnson y SpringSource en la estandarización de Java

Algunos prefieren que SpringSource sea el líder de la estandarización de Java.  Menos mal que hubieron respuestas bastante claras como por ejemplo:

"The idea of Spring taking stewardship of Java is crazy talk. Looking after Java requires theoreticians (e.g. Gilad), compiler experts, Swing and graphics experts, lots of maintainers and bureaucracy and much, much more. i.e. you need deep pockets and an iron stomach for these things"

"Say what you want about JBoss, but at least we've shared our IP with the Java community by bringing both Hibernate and Seam to a standards body. Then, if our business practices offend you for some reason, you can always move to another implementation. You can't say the same thing about Spring."

"That's a good point. SpringSource doesn't seem to be sharing Spring in JCP in a direct fashion that JBoss has with Hibernate(JPA) and Seam(Web Beans). "

En resumen:

• SpringSource es una mosca en comparación de SUN y se necesita espalda para cumplir este rol.
• El aporte de SpringSource a la estandarización ha sido casi nula hasta ahora.
• jBoss ha aportado mucho más que SpringSource al proceso de estandarización: JPA (Hibernate), WebBeans (Seam).

Finalmente, Bill Burke acusa a Rod Johnson, el cual es miembro reciente del JCP, de bloquear avances significativos de la plataforma.

"...this is exactly how Rod positions himself in the EE JSR and pretty much fights against any forward movement of the platform. "

Si se confirma este tipo de acusación, pasare Rod Johnson de anti-héroe a super villano.

Evolución de los framework MVC

La compra de G2One confirma la tendencia de usar lenguajes más concisos para la capa web en lugar de un framework Java.

Opino lo mismo, pero creo que no debe limitarse a la capa de presentación y Groovy tiene, a mi gusto, sus limites en otras capas.  También, opino que la cercanía a Java como la que tiene Groovy y Scala son factores importantes para la adopción.

En resumen, fui una buena entrada en TSS.  Polémica quizás, pero entretenida.

SOA es el futuro

Esta gráfica lo resume todo.

No obstante, si quieren leer un poco más, pueden ver estos comentarios sobre un reporte de Gartner.

Framework web en el mundo Java

Para los framework ORM, la guerra ya terminó y JPA ganó. Hay que recordar que no hace tanto, habían muchas soluciones para la capa de persistencia entre los cuales estaban los EJB Entity Beans, Hibernate, JDO y JDBC directo. Ahora todos están de acuerdo que JPA cumple 90% de las necesidades.

En el caso de los framework web, la guerra sigue vigente y es entretenido seguir el avance de las batallas y tratar de pronosticar el vencedor. Además, me permitirá explicar porque, a pesar de mi entusiasmo por soluciones estándares, estoy involucrado con Liftweb y Scala.

Voy a hacer primero un recorrido por las soluciones que conozco. Nota: no pretendo conocerlas todas.


Servlet y JSP

Eso es el equivalente de usar JDBC Directo en un ORM. Su gran gracia es su simplicidad, la cual es equivalente a la de usar PHP. Por esta razón, lo elijo si tengo que hacer una aplicación para un contenedor Java antiguo y si el cliente no obliga usar un framework X.

Su principal problema es que no obliga que la aplicación sea de tipo MVC y hay que ser disciplinado para no caer en código inmantenible. Para proyectos grandes, con muchos programadores de distinto nivel de conocimiento, no es una buena solución.


Struts

Struts corrige el problema anterior forzando ordenar el código. Yo encuentro que el costo es demasiado alto, muchos conceptos, muchos XML y archivos de propiedades: un "hello world" no puede ser tan complicado. Por eso considero Struts como uno de los responsables de la sensación de pesadez del mundo Java: en particular cuando la critica viene de un programador PHP.

Struts sigue bastante popular y Struts2 esta en la pelea: espero que no gane.


JSF

Los que critican el proceso de estandarización de Java tienen en JSF una víctima clara a la cual lanzar sus dardos. Las principales criticas que me hacen sentido son:

• sobre ingeniería: JSF tiene muchos puntos de extensión, que agregan mucha complejidad como por ejemplo los renderer.
• orientarse a los fabricantes de IDE y de componentes: "no importa si hay que tocar muchos XML porque el IDE se encargará". Desgraciadamente, eso se cumple a media.
  
• mantener compatibilidad con JSP. Eso creo un caos inicial donde había un EL para JSF muy similar pero distinto al de JSP y pasaba cosas raras cuando se mezclaban tags JSTL con los de JSF.

La gran gracia de JSF es su modelo de componente. Si se busca la eficiencia de desarrollo al estilo de Visual Basic/PowerBuilder de la epoca cliente-servidor hay buenas opciones de bibliotecas soportadas en IDE. Por ejemplo, Woodstock de Sun permite un desarrollo Wysiwig con Netbeans.

Ojo, que una vez que se elije una de estas soluciones, esta trabajando con un JSF "con apellido":

• el runtime de estas bibliotecas no soportan siempre las implementaciones de JSF (principalmente la de Sun y la de Apache). Eso implica que puede haber también problemas con el contenedor, si este viene con una de estas dos implementaciones.
  
• dependen de un solo IDE o de un plug-in para un IDE,
• suelen ser incompatibles con otras bibliotecas para JSF. Este ultimo problema se da mucho con las que soportan AJAX.
• la mayoría usan tags y dejan fuera la posibilidad de usar facelets en lugar de JSP.
  

Entonces, antes de casarse con una biblioteca y su IDE respectivo, hay que hacer una buena evaluación. Como no hay estandarización de esta capa, la gracia de tener un estándar para JSF se diluye: eso implica que puedo mirar por el lado a pesar de mi aprecio a soluciones estandarizadas.

Como hay varios proveedores interesados en mejorar JSF, no creo que este muerto. SI logran más simplificación y compatibilizar sus bibliotecas, seria un salto importante para crear el mercado tipo Visual Basic tan anunciado y esperado.


Wicket

Wicket.es distinto. Al abandonar JSP y sus taglibs, lograron separar por completo los artefactos HTML, CSS del código Java. Por otra parte, dice adiós a archivos de configuración en XML Son razones más que suficientes para atraer la atención.

Además, tiene una biblioteca de componentes importantes con soporte AJAX out-of-the-box y es relativamente fácil crear componentes propios (lo cual es ahora difícil en JSF 1.x). De hecho, JSF 2.0 reconoció estas ventajas y anuncia soporte oficial para facelets (¡al fin!) y métodos para crear componentes propios.

Yo recomiendo usar Wicket para proyectos web en Java.


Seam

No se puede comparar Seam, con los frameworks anteriores. De hecho incorpora JSF y ahora soporta a Wicket como opción.

Lo menciono aquí porque:

• logran la integración de las distintas capas de la aplicación.
  
• están aportando a los estándares de Java con la especificación WebBeans (nota aparte: ¡SpringSource aprenda de jBoss si quieres ser un vendedor ético!)
• marca una tendencia en los frameworks: una solución más integral con AJAX, REST, generación de PDF, page workflow, etc.
  

Si tuviera que usar JSF, porque un cliente me lo pide, trataría de usar o por lo menos ser compatible con Seam. Además, gracias al nuevo soporte de Wicket, vamos a poder incorporarlo en nuestros desarrollos Java.


Soluciones RIA en lugar de framework web

Se puede usar un cliente RIA y conectarse al servidor via REST o Web Service. En este caso, desaparece el framework web casi por completo.

Es una posibilidad pero la encuentro improbable: un framework web con una buena biblioteca de componentes AJAX es más simple.


Soluciones no Java

Con el soporte de muchos lenguajes sobre la JVM y los servidores de aplicación, es perfectamente posible usar otro lenguaje con su respectivo framework, para la capa de presentación llamando la lógica de negocio en Java. Por ejemplo, Netbeans permite desarrollar con Groovy/Grails, Ruby/Ruby On Rails y PHP haciendo el deploy sobre servidores de aplicación JEE. Para no mencionar solamente productos de Sun, se puede hablar de:

• el Project Zero de IBM (a pesar que no me queda claro si puede invocar código Java)
• el soporte PHP de Resin con Quercus. Drupal es 4 veces más rapido sobre Resin que sobre Apache. Sun Glassfish y Oracle Weblogic usan Quercus en modo interpretado para soportar PHP

Creo que esta tendencia va a seguir y es el camino que yo escogí al probar Scala y Liftweb. Y veo el futuro cada vez mejor:

• los programadores top de Liftweb están trabajando para mejorar el soporte JPA,
• los plug-in para Netbeans y Eclipse esta mejorando.
• me da la oportunidad de crear componentes y hacer un tipo de desarrollo que no hacia desde mi época en lenguaje C sobre MS-DOS: me hace sentir bastante más joven.

Conclusión

No creo que la guerra este cerca de terminar. El impacto de AJAX y RIA son factores importantes. Por el momento, voy por el camino Wicket (incorporando pronto Seam) cuando estaré ligado a Java y Scala/Liftweb cuando tendré más libertad.


Update 10 de Noviembre 2008: cambios menores de redacción

Update 12 de Noviembre 2008: otro cambio de redacción y mencionar que SpringSource apuesta fuertemente a Groovy/Grails.

Update 22 de Noviembre 2008: solamente mencionar esta conversación extensa en TSS sobre el mismo tema.  

Más retornos de experiencia con Scala/Liftweb/jQuery

Basado en mis primeras experiencias positivas con Scala, Liftweb y javascript/jQuery, decidí lanzarme en mejorar mi TreeTable, un widget para Lift. Y las cosas se empezaron a complicar....

El cambio

La primera versión de mi widget usa jqTreeTable y es super simple: el código Scala genera una tabla HTML estándar y genera código Javascript que llama a jqTreeTable para que se encargue de todo. Super simple si, pero tiene limitaciones:

• Sin soporte AJAX. No puedo buscar en el servidor el contenido de la rama a expandir.
  
• Performance en el browser: con tablas medianas se empieza a notar el procesamiento inicial de jqTreeTable.
  
• Performance en el servidor; generar una tabla grande con muchas ramas puede implicar muchos SQL a la base de datos (uno por cada nodo que contenga hojas).
  
• jqTreeTable usa un solo id para la tabla. Eso permite un solo tree-table por pagina web.
  
• la altura de las filas debe ser constante e igual a uno de los gif de jqTreeTable. Eso me impide insertar gráficos dentro de la tabla.
• los browsers que no soportan jQuery no pueden desplegar el árbol. Si el HTML/CSS del árbol se genera en el servidor se tiene automáticamente un fallback.
  

Finalmente, todas las limitaciones anteriores son excusas porque la curiosidad mata el gato: a pesar que para mi proyecto me la podría haber arreglado de otra forma, tenia que hacerlo para ver que tan difícil es.


Impacto en Scala / Lifweb

Mis problemas no estuvieron en el lenguaje y el framework. Quizas sea una pena, porque no me permitio hacer progresos notables.

Puedo comentar que ya estoy usando Netbeans 6.5 y el plugin para Scala. Eso simplifica bastante en comparación de usar Netbeans, jEdit y Maven en línea de comandos. También mejora bastante la edición de Javascript.

No obstante, no es perfecto:

• la triangulación con el repositorio local de maven hace que Netbeans desconoce las dependencias entre sus proyectos:
  
• impide navegar entre los fuentes de los proyectos.
  
• no hay refactoring iniciado en un proyecto Java con cambio en el código Scala.
• seria practico poder publicar en el repositorio local de maven proyectos construidos por el build.xml de Netbeans.
• no se como usar el debugger de javascript de Netbeans cuando es un proyecto Maven.
  

Todo eso no es tan grave.

Lo que si es grave, es vivir con envidia. Para los que programan en Java, Netbeans 6.5 hace el deploy automático de la aplicación web cada vez que se cambia un fuente Java, XML, JSP, etc. Es suficiente salvar el archivo, esperar 1 segundo, cambiarse al browser y hacer el refresh de la pagina. ¡Es una maravilla! En comparación, me demoro 10 segundos y aprieto bastante más veces los botones del ratón o las teclas usando maven y esperando el reload del servidor.

En resumen, me gustaria mucho que mejoren el plug-in de maven o poder bypassear este plug-in por completo.


Impacto en Javascript / jQuery / HTML / CSS

Al fin me encontre con los famosos problemas de incompatibilidad. No fue en javascript porque hasta ahora jQuery me los esconde a la perfección. Pero si en HTML y en CSS: no fui culo para solucionar el problema de la altura variable de las filas, donde IE y Firefox definitivamente no funcionan igual.

También tuve problemas serios de rendimiento en mis primeras versiones.

El resultado es que aprendí mucho de jQuery probando distintas alternativas y que mejore significativamente mis conocimientos de CSS, a pesar que eso fue insuficiente.


Impacto en la arquitectura

En mi primera versión había bastante separación entre el códígo en el browser y el servidor. Esta nueva versión tiene mucho más inter-dependencias entre Javascript y Scala.

Una consecuencia de lo anterior, es que no es fácil probar con archivos HTML planos (para no tener que esperar maven y el servidor de aplicación). Otra consecuencia, es que seria muy bueno poder usar el debugger de javascript de Netbeans junto con el debugger de Scala.


Comparación con Java

El proyecto que más tiempo me toma ahora, usa Struts y patrones J2EE 1.3 de hace 4 años atrás con capas, capas y más capas. El auto-deploy de Netbeans 6.5 es una maravilla pero no logra compensar la pesadez de este tipo de desarrollo.

Si se compara con desarrollos usando Wicket, el hecho que Lift no tenga una lista importante de componentes pre-hechos es una limitación. La ventaja es que Scala hace mucho más fácil este tipo de desarrollo.

Moraleja

Algún día tenia que vivir en carne propia la incompatibilidad entre browsers: no justifica no usar Javascript para aplicaciones RIA.

Todavía, no me arrepiento de mi incursión en Scala. Creo que permite resolver problemas que en Java son muy dificiles de atacar. Pero, eso será para otra entrada.

Muchas nubes se acercan

Otra entrada rápida para mencionar que Microsoft lanzo su propia solución de cloud llamada Microsoft Azule.

Se agrega a una lista de oferentes que demuestran lo serio de este mercado:

• Amazon
  
• Google
  
• Salesforces
• IBM

Y seguro que esta incompleta.

Al fin algo sobre Symbian

Este entrevista llega a tiempo, justo para hacer callar mis reclamos contra la prensa gringa que no menciona mucho el SO #1 para Smartphone.

Después de leerla me quede con las siguiente impresiones:

• Symbian y el grupo de fabricante de Smartphone detrás (Nokia, Sony-Ericsson, etc) requieren visibilidad en Estados Unidos. Con la llegada del iPhone y del Android, se les pone muy difícil penetrar un mercado donde no le ha ido bien: Nokia debe su éxito a Europa y Asia. Supongo que por eso transforman Symbian a Open Source para salir de la oscuridad periodística.

• Es bastante trabajo pasar un software "adulto" a Open Source. Solaris de Sun paso por el mismo problema que Symbian cuando tenia incorporado muchos componentes de terceros que no eran OSS y que obligaba a una re-escritura o una negociación con su fabricante. Las primeras versiones OSS de Netscape (Mozilla) fueron un desastre: hubo que esperar una re-implementación completa con Firefox para lograr algo de éxito.

• Entoncés, Android tiene una ventana de tiempo para lograr éxito.
  

• La programación concurrente va a ser un tema también para los smartphone porque están planficando CPU con multi-core para minimizar el uso de la batería:
• les permite bajar la frecuencia de la CPU. Hay que recordar que el consumo de energía aumenta exponencialmente con la frecuencia y es por eso que las CPU para PC topearon a 5Ghz.
• pueden hacer dormir los cores que no son utilizados.

• No se como va a enfrentar el SO del iPhone, el cual no es multi-tarea, el hecho de tener multi-core.

Finalmente, no puedo dejar de mencionar este otro articulo que afirma que WIndows Mobile esta muerto.

Variantes a SQL

Una entrada rápida para mencionar este articulo sobre las nuevas ofertas de bases de datos que no son basadas en SQL y propiedades ACID.

Es un tremendo cambio que sigo mirando de cerca.

Android ya esta en mano de sus compradores

T-Mobile ya esta entregando a sus clientes el HTC Dream. Este smartphone es basado en el sistema operativo Android de Google y licenciado como Open Source.

Hay muchos artículos hoy en la internet para los que quieren saber más. Solamente quiero agregar algunos comentarios desordenados:

• Las revistas gringas no dejan de comparar este aparato con el iPhone. Esta ultima comparación es muy relevante para los programadores.

• Las revistas gringas no comparan Android con Symbian. Curioso, porque Symbian sigue siendo el SO para smartphone más usado del mundo (más del 50% según el tío gartner)

• Varios otros fabricantes de smartphone han anunciados que van a lanzar modelos con Android. Eso es interesante, porque empieza un mercado equivalente a los primeros PC con MS-DOS. Symbian también es portable a multiples aparatos: Nokia, Sony-Ericsson, Samsung, etc y los gringos no hablan de Symbian...curioso ¿Será porqué son demasiado nacionalistas? Quizás no, porque tampoco hablan de MS Windows Mobile.

• Google tiene el tiempo a su favor. Tienen el peso suficiente para aguantar una primera salida no tan perfecta (un poco como Microsoft cuyas versiones 1.0 siempre dan penas).

• El modelo de negocio se ve muy interesante. Google gana con más usuarios conectados a sus servicios en línea empezando por el search. Los fabricantes de hardware se dedican a negociar con los carriers. Los programadores ganan el 70% por sus aplicaciones (el 30% restante va para el carrier).

• Técnicamente, Android esta bien pensado. Quizás es porque fue diseñado con limitaciones de hardware mucho menos restringidas que sus antecesores y puede usar una máquina virtual Java que entrega un nivel de abstracción alto. En comparación, Symbian nació para smartphones mucho menos potentes que los actuales y tiene que usar el lenguaje C con API's de bajo nivel. El iPhone es tan reciente como Android y a pesar de eso no es multi tarea...no se porque los gringos comparan Android con un SO tan malo y tan cerrado.
  

• El lenguaje Scala funciona para Android. ¡Otra ventaja de este lenguaje!

• ¡Por fin, las revistas gringas van a dejar de hablar solamente del iPhone!
  

Mis héroes programadores

Voy a hacer honor al título de mi blog, "opinologo TI", haciendo comentarios no tan técnicos sobre algunos programadores famosos, clasificandolos en "héroes" y "anti-héroes". Héroes son los que, cuando opinan algo sobre cualquier tema, los escucho con mucha atención y en forma positiva. Escucho también a los "anti-héroes" con mucha atención, pero en forma bastante critica y hasta para hacer exactamente lo contrario de lo que dicen.

Héroes

• Gavin King / Hibernate, Seam: Sus proyectos hablan por si mismo. Además, es un gran comunicador y fue capaz de entrar en la "política" JEE para especificar JPA (Entity Beans v 3.0). Mi única critica es haberse ido a trabajar a jBoss en un momento que dicha empresa estaba muy criticada (cuando Marc Fleury enviaba spam en TheServerSide para progragandar jBoss).
  

• Scott Ferguson / Resin, Hessian. Desarrollo solo un servidor de aplicación JEE. Gracias a su calidad técnica, Resin es bastante usado en internet: Salesforces lo usa y Netcraft lo registra en Septiembre como servidor web número 12 con 343,323 sitios. Mi única critica es que Scott sufre el síndrome NIH.
  

• Chillenius / Wicket. Tengo respeto por todo el equipo de Wicket por "pensar distinto" y traer un framework refrescante cuando sobraban otras soluciones aburridas.

• Arthur Van Hoff / Java. Arthur era miembro del equipo Java original y escribió gran parte de las primeras bibliotecas. Su énfasis en la simplicidad era notoria y nunca voy a olvidar su articulo sobre Java publicado en Dr Dobb's: allí descubrí el lenguaje y decidí nunca dejar de programar. Quizás Arthur no tuvo una buena idea al irse de Sun Micro y dejar Java en las manos de James Goesling.

• David Pollak / Liftweb; estoy aprendiendo mucho de Scala gracias al código de Liftweb. Muchas gracias por eso.
  
  

Anti-héroes

• Linus Torvalds / Kernel de Linux. Linus es un programador brillante, fue capaz de incentivar una comunidad enorme y dejar su nombre en un sistema operativo bastante popular. Le tengo una gran admiración, pero como este blog es para generar conversaciones lo tengo como anti-héroe. Mi razón, es porque Linus fue bastante conservador en sus decisiones tecnologicas: en la época, había bastante investigación en sistemas operativos y Linus eligió el camino conocido. un kernel monolítico basado en lenguaje C y usando la API de Unix. Es una de las razones del éxito de Linux pero, creo que Linus podría haberse arriesgado más.

• James Goesling / Java Igual que con Linus tengo a James como anti-héroe para generar polémica: James es considerado el padre de Java y merece entonces toda mi admiración. Lo que le critico, es:
• no pudo influir en las políticas internas de Sun. Tener Java, Netbeans, Glassfish Open Source era la decisión correcta. Hubo que esperar el cambio de CEO de Scott Mac Neally a Jonathan Schwartz para que se haga realidad.
  
• La simplicidad inicial de Java se fue rápidamente a la cresta del cerro. Eso es un tema técnico donde James pudo haber tenido mucho más influencia.
  

• Rod Johnson / Spring, Spring MVC, Spring Security, Spring Dinamic Modules, Spring hasta en la sopa. Tengo que reconocer que el retorno a la simplicidad en Java 5 le debe algo a Rod y que es también exagerado tenerlo como anti-héroe. Pero, hay varias cosas que no me gustan del framework Spring y del estilo de Rod:
• Spring es una continuación espiritual de J2EE que el tanto critica: trata de solucionar TODO, hasta la paz mundial,
• hereda algunas malas practicas de J2EE como el abuso de XML. Hay que recordar que Rod criticó duramente el uso de las anotaciones en Java EE 5 antes de retractarse.
• Spring es solamente un thin-wrapper sobre el trabajo de otros: Spring necesita un ORM como Hibernate, un gestor transaccional JTA como Atomikos o simplemente un servidor de aplicación JEE completo para funcionar. Lo que agrega no es mucho. pero es lo que el programador usa directamente. Entonces, opino que los demás se llevan el trabajo sucio y Rod/Spring las flores y es injusto.
  
• Rod trato de definir Interface21 como un vendedor ético. No se que significa eso y me causa mucha desconfianza: si es tan ético, habria tratado de ayudar la especificación JEE como lo hizo jBoss desde el principio y no ahora que necesita vender su propio servidor de aplicación.
  

• Miguel de Icaza / Gnome, Mono. Es el vilano perfecto porque lo hago responsable del fracaso de Linux en el desktop y de intentar destruir Java. Me explico:
  
• el primer desktop "end-user friendly" para Linux era KDE. Excusandose con temas religiosos (KDE usa Qt el cual no era GPL en la época) y en temas técnicos, proponiendo construir un modelo de componentes que nunca lograron, Miguel lanzo el proyecto Gnome. Eso creo una confusión bastante grande y provocó que ningún desktop superó al otro y una perdida de tiempo importante.
  
• Cuando Miguel lanzó Mono (una implementación Open Source de .Net), Microsoft necesitaba contrarrestar el slogan WORA de Java y Mono ayudo claramente este objetivo.
  
• En resumen, Miguel, ex empleado de Microsoft, le dio bastante ayuda a su ex empresa. Menos mal que en el segundo caso, fracaso por completo
  

Buenas noticias para jQuery

No es a menudo que Microsoft anuncia su apoyo a un proyecto Open Source y eligieron usar y soportar jQuery como framework javascript, El mismo articulo menciona que Nokia también va a usar jQuery e incluso incluirlo en sus teléfonos. Me parece un éxito bien merecido.

Como nota aparte, creo que no es casualidad que MS aumenta su presencia con AJAX. La guerra de los browsers esta de vuelta y presiona a MS no abandonar soluciones estándares para los RIA tratando de seguir una linea "Silverligth only". Que tiempos más interesantes...

Cambio de política en mantenimiento de Spring

Menos mal que no soy un fanático de Spring, porque estaría bastante preocupado por los últimos anuncios: Los que no saben a que me refiero pueden leer:

• TheServerSide
  
• InfoQ
• Javalobby

¡Hasta luego SpringSource como vendedor ético!

WOA vs SOA

Encontré este excelente resumen sobre el tema.

Un pokemón en el mundo Open Source

Sigo evolucionando como programador Open Source.

Ahora soy comiteador del proyecto liftweb, principalmente por el pequeño widget de Flot que hice. Voy a tratar de subir también los otros componentes (tree-table y tree-view) pero no estoy seguro si van en la linea de desarrollo de liftweb (si se, que fueron muy útiles durante el proyecto que los uso).

Tengo que admitir que estoy bien contento que me hayan invitado y recibido en su comunidad. Me creo el hoyo del queque :)

Pasame la sal por favor

Se acerca el día donde no tendremos que decir esta frase: vamos a tener sensores que detectaran la expresión negativa de nuestra cara luego de probar la sopa y computadores que mandarán a un robot para que nos entregue la sal.

No es una visión de ahora y supongo que va a tomar algunas decenas de años para concretarse por completo. No obstante se dan situaciones que van en esta dirección y tenemos que estar atento porque podríamos estar más cerca de lo que creemos.

• en el reciente Intel Developper Forum, los investigadores de esta firma mostraron avances significativos,
• hay muchas cámaras digitales que ya son capaz de enfocar la cara de una persona y detectar una sonrisa.
• la Wii de Nintendo demostró el valor de una interfaz consola de juego - jugador más sofisticada. Se puede esperar más avances en esta industria (¡reacciona Sony!)
  
• las guerras de EU en Irán y Afganistán están generando mucha R&D en robótica e inteligencia artificial que se van a traspasar al ámbito civil.
  

Es un tema que me gusta seguir, principalmente porque hay que preocuparse del futuro de nuestros hijos.

Little sensor is watching you

La guerra de los browser's esta de vuelta

Hasta hace 2 años atrás, no pasaba nada de nada en las tecnologías web:

• luego de ganar la primera batalla contra Netscape, Microsoft congelo su Internet Explorer: la versión 6 salio en 2001 y la versión 7 en 2006.
  
• Microsoft trato de imponer una tecnología propietaria llamada XAML. Mozilla respondió con XUL pero no tenia el peso suficiente.
  
• Los estándares HTML se estancaron con HTML 4 (¡en 1999!) y XHTML 1.1 (¡en 2001!). Javascript se estandarizo en 1997 y la versión de DOM en IE 6 era la del 2000 y más encima con varias incompatibilidades.
  

Luego:

• Google con su Gmail, demostró que no era necesario usar tecnologías propietarias para construir aplicaciones web modernas . Eso mato en el huevo el lenguaje XAML de MS y pone una barrera muy alta a las soluciones RIA no basadas en javascript (MS Silverligth, Adobe AIR y las applet Java).
  
• Firefox empezo a ganar mercado, gracias a que...
  
• MS se durmió por completo y que su IE sufrió problemas muy serios de seguridad.

Ahora volvió el dinamismo a un nivel que recuerda el milenio pasado. En menos de 3 semanas llegaron estas noticias:

• Firefox anuncia un JIT de Javascript equivalente a un compilador C: ¿Google Docs podría ser tan rápido como los Office en C?
  
• MS saco el beta 2 de IE 8 incluyendo un mejor soporte de los estándares.
• se vuelve a comentar el futuro de los estándares XHTML y HTML (2.0 y 5.0 respectivamente)

Entonces hay que seguir usando Firefox, o las otras alternativas como Safari y Opera, para incentivar MS a innovar de nuevo. El browser y las tecnologías web son demasiado importantes para la vida cotidiana para quedar estancados y a merced de una sola empresa.

Update: 1 de Septiembre de 2008

Imposible no mencionar que Google va a lanzar su propio browser. Parece que leen mi blog y decidieron que era EL momento para lanzarlo :)

Monad for dummies

Cuando empecé a leer código Haskell, el lenguaje que implementa STM, me encontré por primera vez con los monads. No entendí para nada de que se trataba pero parecía muy interesante porque le permite al compilador Haskell detectar algunos errores que en otros lenguajes no se puede. Por ejemplo, le permite detectar que las operaciones STM modifican solamente variables del "ámbito" STM.

Luego, me encontré con referencias a monad en Scala. Pensé que era mi oportunidad de entender de que se trataba, porque Scala es mucho más abordable que Haskell, pero de nuevo, confusión total..

Me di cuenta que los programadores se dividen en 2 tipos: los que entienden lo que es un monad y los que no y yo era parte de los fracasados. Duro.

Al fin encontré un tutorial que puedo recomendar para cualquier persona que haya pasado por las mismas angustias computacionales y sabe un poco de Scala. Entendí lo que son los monads y para que sirven, pero no me piden explicarlo, ya me olvide.

RIA: tiempo de apostar

He mencionado las Rich Internet Application a la pasada en algunas entradas anteriores. Hasta hace poco estaba indeciso a cual solución apostar entre Adobe, Microsoft, Sun, Google, etc. Ya me decidí.

Un poco de historia

Cada salto tecnológico es acompañado de avances notorios pero también de retrocesos.

De la época mainframe con terminales tontos a la época cliente servidor, se gano la capacidad de generar aplicaciones más interactivas basadas en ventanas graficas. Pero, el costo de despliegue de las aplicaciones aumento significativamente, porque había que desplazarse para instalar cada nueva versión en cada PC y era frecuente que diferencias pequeñas de configuración de Windows introduzcan incompatibilidades. Ese ultimo fue llamado el DLL Hell.

La época web permitio solucionar los problemas de despliegue: hay mucho menos versiones de browsers que configuraciones de Windows posibles y las aplicaciones se instalan en un servidor donde técnicas como el classloading de Java reducen significativamente el problema del DLL Hell. Lo que se perdió es la capacidad de hacer aplicaciones interactivas complejas como por ejemplo, tener un control fino de los movimientos del ratón.

La meta de las RIA es recuperar la interactivad usando el browser como método de despliegue. Se obtiene entonces los beneficios de todas las plataformas anteriores:

• de la web con HTML puro y del mainframe monolítico: un ambiente centralizado y controlado donde se hace el despliegue de las aplicaciones,
• del cliente-servidor: la capacidad de hacer aplicaciones clientes sofisticadas.
  

El termino es reciente pero hubieron varios intentos con distintos grados de éxito:

• las applets Java: aparte de lanzar el lenguaje a la fama, se usaron en algunos sitios de juegos en-linea como el de Yahoo. Cuando Microsoft abandono Java por .Net, no se actualizo más la versión de la JVM en internet explorer y las applets se estancaron. Además, los grandes sponsores de Java, Sun, IBM, Oracle se preocuparon más del lado servidor donde podían generar ingresos. A pesar de eso, Java y las API's J2SE son una buena plataforma para aplicaciones desktop: Eclipse, Netbeans, Azureus, Limewire demuestran que se pueden hacer aplicaciones de buena calidad grafica.

• ActiveX de Microsoft: no tuvo el efecto esperado pero permitio distribuir algunos plug-ins importantes como...
  

• Flash: tiene un gran éxito para generar contenido más vistoso que lo posible con HTML puro.

Técnicas en competencia

• Javascript, AJAX: Google con su servicio Gmail permitio revivir tecnologías que ya existían dentro de los browsers, pero que no habían sido usadas con toda su potencial. Se abre en varias alternativas:
• javascript puro, usando framework o API's como Dojo, jQuery, Prototype
• componentes en el servidor que generan el código Javascript (potencialmente, usando uno de los framework anterior),
• GWT de Google que permite compilar un programa Java basado en las API's de Google a código Javascript que se ejecuta en el browser
• seguramente, otros que no conozco
  

• las applet Java: están de retorno con nuevas facilidades que las hacen un poco más entretenidas, como por ejemplo:
  
• hacer drag de la applet para dejarla en el escritorio de Windows donde se ejecutará posteriormente como cualquier aplicación.
• el lenguaje JavaFX que es más amigable para diseñadores y tiene acceso a las capacidades de Java2D,
• API's graficas que se han mejorado en todos estos años, incluyendo mejoras de rendimiento con acceso directo al hardware
  

• Adobe AIR: gracias al tremendo éxito de Flash, Adobe tiene una buena recepción con los diseñadores web. Tiene que convencer ahora a los programadores.
  

• Microsoft Silverlight: se puede esperar muchos esfuerzos de parte de Microsoft para recuperar su influencia sobre los programadores de la capa cliente. Alguna vez Visual Basic reinaba el mundo y MS perdió este liderazgo con la web, Java y PHP.

Por gustos personales, siempre voy a preferir una solución basada en estándares. Antes de probar Adobe AIR y MS Silverlight, tendría que descartar completamente a Javascript y las applet java. A primera vista, las dos soluciones estandares tienen defectos:

• Javascript es la más compleja de todas las soluciones, partiendo por todas las alternativas disponibles, las incompatibilidades entre browsers y la falta de IDE que facilitan el desarrollo.
  

• las Applets sufren de su pasado y Sun ha generado mucho anti-cuerpo por haber abandonado un grupo de programadores que se fueron mayoritariamente a Flash.
  

Entonces, mi apuesta es:

• no a Adobe AIR y Microsoft Silverlight. No soy el único en el mundo a quien le gusta los estándares y se inquieta cuando depende de un solo proveedor: por algo Java tuvo mucho éxito
  

• dudo del retorno de las applets. Creo que va a depender de como Sun se maneja en el mundo de los celulares donde tiene que hacer un upgrade de su exitoso J2ME a una plataforma más sofisticada y compatible con el desktop: JavaFX es supuestamente para eso. Pero Sun esta cada vez más solo. Google, por ejemplo, decidio crear una platafarmo propia con Android.

• Apuesto al éxito de Javascript porque es mucho más fácil de usar de lo que creía.
  

Javascript y programación genérica en Scala

Finalmente, sigo con Scala y Liftweb para la implementación de mi proyecto de innovación tecnológica. El proyecto me permitio además incursionar en el desarrollo de componentes para aplicación web. y eso me obligo a usar Javascript y programación genérica. En ambos casos, tuve agradables sorpresas.

Javascript

La web esta llena de cuentos de horrores sobre la incompatibilidad entre los browsers y lo difícil de implementar DHTML. Tantas habían hace 5 años, que yo prohibí el uso de Javascript avanzado para el desarrollo de aplicaciones web. Yo trabajaba en una empresa grande de Chile donde me tocaba dar directrices de desarrollo y apalear a los proveedores que no cumplian: ningún proveedor me cuestiono la directriz de minimizar el uso de Javascript, así que puedo deducir que era una practica acceptada por la industria.

Obviamente, Google cambio el paradigma y demostró que se puede hacer aplicaciones complejas con Javascript en el browser. Igual, las malas sensaciones perduran y me costo hacerme a la idea que, ahora si, Javascript y DOM sirven para algo más que un "alert", exceptuando quizás, en mano de los mejores programadores del mundo. Además el hecho que Javascript sea un lenguaje tipo "dynamic typing" no me atrae porque me gusta que el compilador trabaje por mi y no al revés.

Entonces, mi recomendación de arquitectura seguía casi intacta: no se programa Javascript en el browser, se usa componentes en Java/JSF o Java/Wicket que generan el código cliente automáticamente. Mantengo esta recomendación como primera opción porque tiene un efecto simplificador dentro del equipo de desarrollo: se usa menos tecnologías. Pero, como liftweb no tiene todavía la misma cantidad de widget que wicket, no me quedo otra que crearlos yo mismo (de eso se trata mi pequeño proyecto OSS).

Y tengo que admitir, que los frameworks Javascript ayudan bastante. Liftweb usa jQuery para su soporte AJAX y esta API tiene algunos plug-ins muy buenos como el Flot y otros bastante decentes como jqTreeTable: hacer un wrapper Scala/Liftweb para usar estos plug-ins no es tan complicado. Todavía hay diferencias entre los browsers, pero las versiones modernas de IE y Firefox reclaman cuando encuentran un problema y es relativamente fácil rastrear la fuente. Una sola vez, perdí 2 horas con un detalle de MS Internet Exploerer: no es tanto.

En resumen, si el equipo de desarrollo tiene un programador Javascript avanzado, es una buena opción usar este lenguaje para crear interfaces complejas usando los plug-ins de jQuery, Dojo o Prototype.


Programación genérica

Hemos sido literalmente bombardeado de criticas sobre la implementación de generic en Java. Tantas, que hay una corriente en Java que pide "no más innovación en el lenguaje" y usa generic como el argumento del costo de hacer las cosas mal. El miedo se instalo y no se quiere avanzar.

Por mi parte, yo encuentro que usar generic en Java simplifica mucho los programas y es un avance que valió la pena. Para evitar los supuestos problemas, lo uso en forma simple como por ejemplo, iterar sobre colecciones sin tener que hacer type cast.

Ahora, me tocaba hacer un componente MVC donde a la clase de mi modelo, un árbol con nodos y hojas, le vendría bien usar programación genérica. Pero había leído las criticas de uno de los programadores de Wicket que respeto mucho y era para pensarlo dos veces. Del thread de theserverside que acabo de linkear, me llamo la atención lo siguiente:

• el numero de post que demuestra que la programación genérica en Java es un tema que anima pasiones,
• históricamente se ha echado toda la culpa al "type erasure" y algunos cuestionan esta afirmación. Además, cuestionan si la opción "type erasure" era o no era necesaria para mantener compatibilidad con versiones anteriores de java. O sea son 2 mitos importantes que fueron cuestionados.
  

Si el problema de Java reside en el "type erasure", cualquier lenguaje que compila a bytecode como Scala va a sufrir las consecuencias. Si no, quizás una mejor sintaxis como la de Scala puede permitir que humanos programen en forma genérica. De nuevo, había que poner Scala a prueba.

Y creo que otra vez salio bien parado el lenguaje. No me crean, vean el código. En mi modelo, un nodo es objeto de tipo A y una lista de hojas con nodos de tipo B. Cada hoja es a su vez un nodo de tipo B y con sub-hojas de tipo C. Fijense en el uso del underscore "_" para referirse a un tipo C desconocido:

class TreeModel [A, B] (node : A, leafs : List [TreeModel [B, _]], isCollapsed : Boolean)


No puede ser más simple, Scala es absolutamente genial.


Conclusión

Los cazadores de mitos deberían trabajar en TI. javascript en el browser no es tan difícil y la programación genérica es totalmente utilisable (por lo menos en Scala).

Lightweight vs Heavyweight

Hace poco tiempo atrás, la búsqueda del Santo Grial para las aplicaciones Java en el servidor era usar soluciones "livianas" y se consideraba que los servidores de aplicación JEE eran los campeones de la "pesadez". Era una conversación bastante confusa porque era difícil encontrar una definición clara del tema. Este blog es una retrospectiva sobre el tema.

Ciclo de vida de la búsqueda

Creo que la búsqueda de la liviandad se hizo popular porque usa los mismos términos que en la parte cliente donde el "cliente liviano" (el browser) tiene ventajas sobre las soluciones tipo "cliente pesado" ("fat client" o aplicación ejecutable Windows o Linux). Quedo en el sub-conciente colectivo que liviano es mejor que pesado.

Ahora, "pesado" dejo de ser un concepto tan negativo en la parte cliente. Las RIA consisten en dejar más pesadas las aplicaciones en los browsers, claro que no se dice "pesado", se dice "rico": es la traducción literal de "rich" en inglés que suena mal en español chileno cuando se dice "aplicación rica". Pero, se refiere a lo mismo, son aplicaciones más complejas que usan API's javascript como Dojo's, jQuery o plug-ins como Flex, Silverlight e incluso applet java ("el retorno", "java begins", etc)..

En la parte servidor no se dice "rico" sino "modular". Es aceptable que un contenedor sea "pesado" si levanta solamente los servicios requeridos por las aplicaciones que corren sobre el y, por esta razón, OSGI es tan popular.


¿Cuales eran los criterios para definir un contenedor como pesado?

Eso, nunca me quedo exactamente claro, pero leyendo comentarios de otros y en base a mi propia experiencia puedo deducir que los factores importantes en el mundo JEE eran:

• factores que afectan el tiempo de aprendizaje y tiempo para montar la arquitectura base:
• cantidad de especificaciones distintas: es casi imposible conocer "al dedo" todas las especificaciones de JEE y sus relacionadas: XML, Web Service, HTML, CSS, etc.
  
• cantidad de páginas/complejidad de una especificación. Por ejemplo, cada vez que dejo de usar un tiempo EJB Session Bean voy a leer de nuevo el capitulo de manejo de transacción y de excepciones, porque me cuesta recordar este tema y es muy fácil mandarse un condoro.
• cantidad de framework que extienden y/o reemplazan algunas API's: solamente contando los ORM (como Hibernate) y los MVC Web (como Struts) deben haber más de 100. Eso obliga a probar muchas combinaciones, para detectar incompatibilidades, lo que provoca una situación equivalente al "DLL Hell" de Windows
• cantidad de patrones necesarios para sacar provecho a la arquitectura (por ejemplo, "sesión bean de fachada", "service locator", etc)

• factores que afectan la implementación y mantención:
• Turn-around o tiempo necesario entre hacer un cambio en el código y poder probarlo, lo cual incluye:
  
• tiempo necesario para compilar la aplicación,
  
• tiempo necesario para desplegar los artefactos EJB-JAR, WAR, EAR
• tiempo necesario para arrancar el servidor,
• cantidad de capas de código necesarias para mitigar problemas/lagunas en la especificación como por ejemplo: el uso de DTO entre la capa EJB y la capa de presentación porque no se especifico que pasaba con los EJB Entity Beans despues de terminar la transacción.
  
• dependencia del ciclo de desarrollo hacia un IDE como por ejemplo, cuando algunas opciones criticas se pueden setear solamente a través del IDE del fabricante del servidor de aplicación,
  
• dependencias hacia clases o interfaces de la API, por ejemplo, obligando a extender una clase padre. De allí, nació la mítica búsqueda del POJO
  
• cantidad de clases y archivos de configuración a generar. Por ejemplo, un EJB requiere editar 3 archivos java y una entrada en XML
  
• Muchas API's relativamente de "bajo nivel" como Servlet JDBC, JMS, JTA, que obligan a generar mucho código. Curiosamente son dentro de las más exitosas.
  

• factores que afectan el ambiente de ejecución
  
• cantidad de recursos, memoria, CPU, espacio en disco usado por el servidor de aplicación,
• rendimiento, escalabilidad de los servidores: las primeras versiones no eran para nada optimizadas.

¿JEE es el gran culpable?

Los especificadores de JEE hicieron muchos errores. El método que se uso fue: especificar primero y luego ver como el mercado reacciona. Como consecuencia, se incluyo ideas, conceptos y soluciones no probadas o probadas dentro de otro contexto (por ejemplo con los monitores transaccionales en lenguaje C que precedieron).

Pero el método tuvo varios logros excepcionales:

• se formo una comunidad gigantesca alrededor de Java y JEE,
• la portabilidad de las aplicaciones no tiene equivalente en la historia de la TI. Comparamos un poco:
• SQL básico (select, insert, update, delete, más definición de tipos de datos) se resume a 50 páginas de especificación. A pesar de eso, no hay portabilidad absoluta entre los motores. Y eso sin contar la incompatibilidad completa entre las implementaciones de los store-procedure,
• Javascript, DOM, HTML es relativamente sencillo: todavía hay diferencias notables entre los browsers.
• Ruby tiene varias maquinas virtuales e implementaciones de sus bibliotecas que tienen problemas serios de compatibilidad entre si.
• las especificaciones cubren todo lo requerido por aplicaciones empresariales (el mundo Java hizo en menos de 5 años lo que tardo 30 años para lenguajes C y COBOL)
  

Entonces, estoy de acuerdo que las especificaciones JEE tienen algo de culpa, pero lograron crear un mercado que vino al rescate: Hibernate/Spring no existieran si no fuese por estos estándares. Consientes de las deficiencias, los especificadores se dedican a simplificar (desde JEE 5) y ahora, a modularizar (JEE 6).


Pero las especificaciones no son las únicas responsables. Para mi, la sensación de "pesadez" esta más asociada a las implementaciones de éstas y voy a volver a mencionar Resin porque es el mejor ejemplo que se puede implementar JEE sin crear un monstruo. Resin implementa EJB versión 2.x y a pesar de eso:

• usa menos de 30 MB en mono-usuario,
• arranca en segundos (similar o inferior a Tomcat)
  
• recarga los cambios en los fuentes sin tener que rebootearse. Detecta cambios en los fuentes Java, los recompila y genera si necesario los artefactos intermedios (como stub, skeleton, tablas de la BD).
• No requiere de un IDE e incluso de una herramienta tipo make (como ant o maven). Con jEdit (o cualquier editor que pinta la sintaxis del código) sobra y basta.
• tiene archivos de configuración XML editables por humanos.
  

Estas capacidades permite editar un fuente Java en un editor de archivo, guardar el fuente y recargar la página web: exactamente igual a lo que se hace en PHP y Ruby. Para lograr todo eso, tuvo que extender las normas JEE para el tema de despliegue de aplicaciones (no obliga a usar EJB-JAR por ejemplo). Eso no es una violación a la norma, porque permite desplegar con todo lo de la ley si se desea mantener compatibilidad.

Al otro lado del espectro esta el campeón de la pesadez, el IBM WAS y WSAD (ahora Rational Application Developper). Seguro, WAS tiene muchas cualidades como robustez, seguridad, facilidad de monitoreo, rendimiento, escalabilidad y el soporte de la empresa más importante de la historia de la TI ("nadie pierde su trabajo por elegir IBM"), pero de liviano no tiene nada. Yo creo firmemente que cuando muchos programadores piensan en lo pesado que es JEE están pensando en WAS y WSAD.


Conclusión

La pesadez en las especificaciones JEE y los servidores de aplicación que las implementan existieron. Las nuevas versiones reducen el problema gracias a la modularización (JEE6 y Glassfish v3). Las implementaciones de JEE tuvieron un rol importante en crear esta sensación.

El termino es demasiado ambiguo y es bueno que se deje de usar. Para mucha gente, pesado implica lento y dificil de escalar: ningun servidor de aplicación moderno es lento o impide la escalabilidad.


Update 13 de Agosto de 2008

Netbeans 6.5 beta y Glassfish v3 acaban de lanzar la facilidad "Compile & Deploy on Save": luego de guardar un fuente en el IDE, el ambiente (servidor de aplicacion+IDE) recompila y deploya el proyecto automaticamente Resin tiene una competencia muy seria.

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.