Liberado Ruby on Rails 2.0

David Heinemeier Hannson ha anunciado la versión 2.0 de Ruby on Rails, el framework de desarrollo web más popular para el lenguaje Ruby. Las nuevas características que incorpora caen dentro de la "evolución", más que dentro de la "revolución"; esto es, no he visto nada que al menos a mí me parezca revolucionario (si bien, también debo reconocer que nunca he trabajado con Ruby on Rails y a lo mejor se me escapa algo).

Si alguno se pregunta qué tiene que ver esto con Java, la respuesta es simple: ahora la plataforma Java soporta el lenguaje de programación Ruby a través de JRuby.

¿Hay alguien por aquí que tenga experiencia con Ruby on Rails y pueda comentarnos qué le parecen las novedades de la versión 2.0 ?

IntelliJ IDEA 7.0.2 con soporte para JRuby y Groovy

JetBrains ha anunciado la versión 7.0.2 de IntelliJ IDEA; aunque el número pudiera llevar a pensar que se trata de una versión que sólo resuelve bugs, hay dos novedades importantes: soporte para los lenguajes JRuby y Groovy. En el segundo caso soporte se obtiene a través de un plugin que ha desarrollado la propia compañía, JetGroovy.

Otro entorno de desarrollo Java más que no quiere ser "sólo un entorno de desarrollo para el lenguaje Java".

[back to basics] El JavaBean desconocido

He encontrado este comentario de Richard Bair y lo primero que he recordado es la cantidad de veces -unas cuantas- que algún conocido me ha preguntado eso de "Pero un JavaBean exactamente qué es?".
 Y he visto bastantes casos que se quedaban en el tema de los accesores. Sí, muchos ni siquiera sabían lo del constructor y menos el tema del estado, así que el tema de los eventos de cambio de propiedades olvídate.

Esta es una buena explicación de lo que implica el "patrón" JavaBean, pero para más profundidad, conviene seguir el tutorial oficial de JavaBeans.

No a las closures para Java (al menos por lo de ahora) Joshua Bloch

Joshua Bloch es en la actualidad el "Chief Java Architect" de Google; durante su paso por Sun Microsystems fue responsable de diseñar, entre otros, el framework de colections y buena parte del paquete java.util. Recientemente ha hecho una presentación Javapolis a la que ha titulado "la controversia de los closures" en la que, resumiendo en una frase, defiende que todavía es muy pronto para plantearse añadir closures a Java ya que hay que estudiar en detalle todas las implicaciones y los pros y los contras.

En la presentación defiende que la propuesta BGGA para crear closures complicaría excesivamente el lenguaje de programación Java y crearía otra fuente de potenciales códigos incomprensibles como es el caso de los wildcards en generics si se abusa de ellos. También defiende que al añadir una característica nueva a un lenguaje de programación la complejidad que va a añadir a ese lenguaje incrementa exponencialmente respecto al número de otras características con las que la nueva característica interacciona. Y las closures interactuarían con prácticamente todo.

Por otro lado, si queremos usar "function types" en Java, es decir, poder tratar un método una función como si fuese una variable más, o poder "pasar un cacho de código" a una librería sin necesidad de implementar una interfaz podemos hacerlo dentro de la plataforma Java empleando el lenguaje Scala.

Bloch defiende que en vez de usar BGGA sería más prudente apostar por la unión de las propuestas CICE+ARM, mucho más conservadoras y con menos poder expresivo pero que añadirían menos complejidad ha lenguaje. La desventaja de estas dos es que en la actualidad sólo son bocetos, mientras que ya existe una implementación casi completa de BGGA realizada por Neal Gafter, principal responsable de Javac cuando trabajaba para Sun e (irónicamente) compañero inseparable de charlas de Bloch hasta que comenzó la polémica de las closures.

Bloch también afirma que se haga lo que se haga debemos esperar varios años todavía y experimentar con los prototipos. Todavía es muy pronto para proponer un JSR.

¿Cuál es vuestra opinión al respecto?

Estadísticas de utilización de librerías AJAX

En Ajaxian publican una interesante estadística sobre la utilización de diversas librerías/frameworks para desarrollo AJAX. Las estadísticas se realizan a partir de consultas realizadas a usuarios de la propia web, independientemente de la validez o fiabilidad que cada uno pueda otorgar a este tipo de encuestas, puede ser interesante para al menos hacernos una idea de por donde van los tiros en esto del desarrollo AJAX.

los resultados:

1. Prototype 34.1%
2. jQuery 29.3%
3. Ext JS 22.5%
4. Script.aculo.us 22.3%
5. Mootools 14.3%
6. YUI 13%
7. raw AJAX 13%
8. Dojo 11.9%
9. BackBase 8.3%

Se puede acceder en este link a los resultados completos de la encuesta.

Algo a destacar, es exceptuando a backbase, la ausencia de librerías/frameworks comerciales, parece que el open-source domina claramente en el mundo del desarrollo AJAX. Otra cosa que destacaría es que los dos primeros de la lista no son frameworks completos repletos de widgets varios sino librerías con utilidades para facilitar el manejo del DOM, eventos, evitar incompatibilidades entre navegadores, encapsulaciones del objeto XMLHttpRequest, diversas ampliaciones a JavaScript y sus tipos básicos etc. Parece que de momento el uso de AJAX se esta enfocando más en enriquecer webs existentes que en realizar Rich Internet Aplications.

¿Que os parece la encuesta?, ¿vosotros que usáis en vuestros desarrollos AJAX?