Programación web por eventos

Hace unos meses un profesor propuso que entre un grupo de doctorandos escribieramos un libro con el state of the art en cuanto a computación distribuida. Un capítulo por autor con un tema a elegir. Yo escogí, por supuesto, un tema relacionado con aplicaciones web.

Los temas de Ajax creo que ya estan un poco pasados de moda como para considerarlos state of the art así que opté por el que creo que es el siguiente paso en la convergencia de aplicaciones de escritorio y aplicaciones web: la programación por eventos, o como un servidor puede enviar un evento al cliente sin tener que esperar a que el cliente (navegador) inicie la comunicación (como limita el protocolo HTTP).

El resultado es este capítulo que habla sobre lo que llamo genéricamente Web Push pero que habitualmente se está llamando Comet en un intento (con éxito) de acuñar otra palabra afortunada como fue Ajax.

El capítulo que os dejo introduce las limitaciones de las aplicaciones Web y algo de Ajax para ir entrar con más detalle en los retos que supone implementar un modelo por eventos en una plataforma que no lo permite en principio (la web actual). Los problemas que afrontan los servidores y finalmente qué se está haciendo para resolverlo y un vistazo a lo que viene.

Está en inglés, espero que no resulte muy problemático.

Web Push [PDF, 309 KiB]

Instalación de Tomcat 5 bajo Debian

A raiz de un mensaje en la lista de correo de usuario de Debian en catalán he publicado un nuevo artículo que tenía por aquí hecho sobre la instalación de Tomcat 5 en un Debian. Sencillito, pero contiene más o menos lo necesario.

Espero que os sea de utilidad. Los comentarios y sugerencias, donde siempre.

CSS wiki

CSS Wiki: impresionante web que he encontrado mientras buscaba información sobre tamaños relativos de fuentes de letras. Muy buen compendio de información clara y bien distribuida. Tras 5 minutos de lectura ya he encontrado algunos errores, el más grave de ellos era el relativo a los modos de renderización del navegador y el DOCTYPE.

Bug en Prototype ?

Voy a publicar esto aquí antes de que se me olvide. Desde que uso Prototype en mis desarrollos he tenido ciertos problemas con la rutina Ajax.Updater al intentar que me ejecute los scripts incluidos en fragmentos que traigo a la página via Ajax. Se supone que incluyendo la opción evalScripts deberia funcionar, pero no siempre es así. Investigando al final he concluido que la expresión regular que busca las cadenas que contienen los scripts no funciona adecuadamente (el problema está en el caracter \r).

Al final lo he parcheado y parece que funciona.

El cambio es el siguiente:

updateContent: function() {
var receiver = this.responseIsSuccess() ?
this.containers.success : this.containers.failure;

var match = new RegExp(Ajax.Updater.ScriptFragment, 'img');
var s = this.transport.responseText;
s = s.replace(new RegExp('\r','mg'),'');
var response = s.replace(match, '');
var scripts = s.match(match);

Actualización: Tras enviarle un email a Sam Stephenson, creador de prototype, he recibido su respuesta afirmativa en la que me confirma que tenia reportes de errores en Windows pero no había podido averiguarlo. Hoy me voy a dormir habiendo hecho mi contribución diaria al soft libre. ;-)

GMail: más espacio del que podemos usar

Acabo de leer a Alvy de Microsiervos haciendo referencia a un post de Jasp sobre el tamaño de las cuentas de GMail. Ya comenté yo en su día que había más espacio del que utilizaba.

De hecho, es posible que así sea en la mayoría de los casos. De acuerdo que hay inventos por ahí que utilizan el espacio de GMail para otros casos, pero si nos restringimos a un uso convencional (simplemente como cuenta de correo) creo que la mayoría de gente no recibe correo al mismo ritmo que crece su cuenta.

Veamos en mi caso... tengo 1367 correos en la cuenta de GMail. La utilizo prácticamente sólo para suscribirme a listas y allí donde tenga que aparecer el email de manera pública. Me marca ocupados 22 MiB, así que me sale una aproximación bastante burda de 16,48 KiB por mensaje.

Según comentarios del post referido, si tomamos 30 bytes/segundo tenemos unos 2,47 MiB de espacio adicional diariamente, así que eso me da para más de 150 mensajes aproximadamente.

Así que también podemos decir que GMail nos da espacio para guardar 150 nuevos mensajes al día. Y si no contamos el spam, es mucho correo cada día (creo que yo no recibo eso dejando de lado el spam)

Y yo no creo que el crecimiento del tamaño de los mensajes sea exponencial. Desde hace muchos años el tamaño medio del mensaje no habrá crecido mucho. Incluso en mi caso el cálculo ha arrojado un tamaño medio bastante alto porque muchas listas de correo utilizan HTML pese a que es malo para el correo. Pero la mayor parte de los mensajes que llegan a mis buzones personales son mucho menores ya que son texto llano.

JSP 2.1 y JSTL 1.2

Siguiendo con las novedades en las especificaciones J2EE Web Tier, las especificaciones de JSP y JSTL no presentan prácticamente ninguna novedad salvo adecuarse al nuevo documento de especificación del lenguaje EL.

En esta parte es donde si han habido cambios, ya que se han incorporado al EL cambios que ya había adoptado JSF.

Para empezar, ahora las expresiones no son sólo ${} sino también #{} aunque en la especificación se indica que ambas son equivalentes y que la diferencia depende del entorno en el que se utilicen (por ejemplo Faces utiliza #{} para expresiones con evaluación diferida).

Se ha ampliado bastante la sintaxis básica. Anteriormente (con JSP 2.0) el EL sólo permitia producir rvalues. O sea, expresiones que devuelven un valor. Ahora es posible indicar también rvalues y métodos. Un ejemplo tomado de la propia especificación (ejemplo de JSF):

<h:form>
<h:inputtext
id="email"
value="#{checkOutFormBean.email}"
size="25" maxlength="125"
validator="#{checkOutFormBean.validateEmail}"/>
</h:form>

En este ejemplo #{checkOutFormBean.email} es un rvalue ya que no representa un valor sino una propiedad del bean a la que ha de darse valor según el campo de formulario. En el caso de #{checkOutFormBean.validateEmail} hace referencia a un método que se invocará para validar ese campo.

Realmente un cambio centrado en el EL que lo va a convertir en una herramienta aún más util.

Ruby on Rails vs J2EE

Yo acostumbro a desarrollar aplicaciones web bajo J2EE (Java). Pero siempre es bueno tener un ojo puesto en todas las tecnologias alternativas, aunque sea para descartarlas (o tener argumentos en una discusión!)

Una tecnologia que lleva un tiempo atrayendo mi atención es Ruby on Rails (RoR). Es un framework completamente nuevo específico para desarrollo de aplicaciones web. Además, es uno de los primeros que más uso de AJAX está efectuando.

Finalmente alguien se ha decidido a hacer una buena comparativa. Si alguien está interesado, aquí está Ruby on Rails vs J2EE.

Tomcat Deployer

Cuando necesito simplemente un servidor para aplicaciones web (un contenedor de servlets J2EE) suelo utilizar el Apache Tomcat, actualmente la versión 5.0 (aún no he pasado a la 5.5 porque está diseñado para J2SE5 y no veo que aún sea momento de pasar a esa versión de Java).

Pues bien, para mis clases muchas veces me es necesario entregar una "solución" en forma de aplicación web pero sin entregar nada de código. Tal como se hacen los deployments habitualmente de las aplicaciones web es fácil pasar sólo el código de servlets y otras clases (bajo /WEB-INF/classes) pero no es fácil para JSPs... hasta ahora.

Si os fijáis en las descargas del Tomcat (la última estable de la versión 5.0 es la 5.0.28) además del servidor en sí hay tambien una descarga que reza algo así como deployer. Descargando y descomprimiendo ese fichero disponemos del Tomcat Client Deployer que entre otras cosas es capaz de validar y compilar una aplicación web. Si no queréis ni cambiar la configuración, es tan sencillo como crear un directorio ./myapp y ejecutar 'ant' en el directorio (para el target por defecto del build.xml).

El resultado será un directorio ./build/webapp con la aplicación compilada y desplegada (y también en un .war). Aunque aún veamos los JSP, se pueden borrar puesto que ahora estan compilados y además se ha modificado el web.xml para que apunte a los servlets generados.

JavaServer Faces

Uno de mis principales trabajos consiste en implementar aplicaciones web. Para ello, utilizo JSP + Servlets + JSTL utilizando un modelo MVC "a mi estilo". Muchas veces añado otras librerias de tags de la Taglibs de Jakarta.

Andaba buscando una libreria de tags para publicar rápida y fácilmente tablas, cuando he topado con un tag de JavaServer Faces. Esta tecnología nunca había atraído mi atención, porque pensaba que sustituía a los JSP y a mi ya me va muy bien el planteamiento que utilizo para las aplicaciones web. Sin embargo, he echado un breve vistazo a sus características y me ha atraido la idea.

Cuando tenga un rato tengo que echarle un vistazo a fondo y probarlo.

Realizar una petición HTTP desde Javascript

Estoy desarrollando una aplicación web para un cliente. Una de las cosas que me pidió es una "ventana emergente" pero que no fuera un popup. Ya estamos con el lio...

Por suerte, hay un objeto (con nombres diversos en función del navegador) que viene en nuestra ayuda. El objeto, llamémosle XMLHTTP, permite lanzar una petición HTTP y leer el resultado... todo desde javascript.

¿Que nos permite esto? Pues por ejemplo crear una capa dinámicamente y meter el resultado de una página en ella.

Todo esto lo vi yo funcionando realmente de manera util en Google Suggest. En este blog tenéis información sobre Google Suggest.