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