Climens Codelog

El otro día leí un estupendo artículo sobre la difícil mantenibilidad de los WebForms de ASP.NET. Realmente expone las frustraciones a las que nos enfrontamos muchos programadores que trabajamos con esta tecnología de Microsoft, especialmente los que venimos del mundo puramente web y raramente hemos trabajado en VB6 o WinForms.
Entre los motivos que se exponen son los siguientes:

• Algunas cosas sencillas, patrones típicos de HTML/Javascript cuestan mucho o son casi imposibles
• No hay ningún control sobre el HTML generado, dificultando especialmente la conciliación con el diseño original
• Los controles reciben IDs tediosos de manejar desde Javascript, que además cambian si se cambia el control de contenedor
• Los controles a veces no funcionan como deberían y hay que ir investigando porqué se comportan como lo hacen

Yo al final opto muchas veces por usar repeaters, simples y sencillos. Dibujan el HTML tal cual está previsto y así sale todo como está previsto, pero claro, luego vienen los problemas cuando hay que anidar unos dentro de otros: ni se me ocurre abrir el diseñador.

En esta línea, hoy han publicado una continuación hablando del modelo web, lo que conocemos de toda la vida:

• HTTP
• Cookies
• (X)HTML
• CSS
• JavaScript

Una vez entendido es bastante sencillo. Tiene sus inconvenientes pero todo se deriva de la naturaleza del HTTP, donde cada llamada es completamente independiente de la anterior. Eso obligó a crear las cookies y desde el renacimiento del Javascript gracias a la explosión de AJAX conforman un conjunto bastante completo conocido por una infinidad de desarrolladores web alrededor del mundo.

Por lo tanto, para reducir las diferencias entre la programación Windows y la web, los programadores de Microsoft se inventaron:

• Los postbacks
• El ViewState
• El ciclo de vida

Y así nacieron los WebForms. Decidieron reinventar la rueda para captar a los clásicos programadores de VB6 que empezaban en la web cuando apareció el .NET Framework y el Visual Studio .NET por allá por 2003. Pero a los que veníamos de ASP no nos ofrecieron en realidad una continuidad con el medio que conocemos y que por más que pase el tiempo no acabamos de comprender el nuevo modelo pensando que "antes era más sencillo". No es lo que yo llamo progreso.

Un ejemplo reciente: me preguntaron porque si movían opciones de un ListBox a otro por Javascript y luego hacían un Request para recoger el valor de la lista en la acción, devolvía null. Pues simplemente porque ese tipo de controles meten su valor en el ViewState para "completar" la información que HTML por sí mismo no da. Así que la solución es copiar el valor en un campo oculto y luego recogerlo, teniendo que hacer manualmente lo que ASP.NET hace automáticamente solamente porque usando los eventos de .NET, cada movimiento entre listas obliga a recargar la página (no con AJAX, pero el problema es parecido). Y con razón me dicen que antes era más sencillo. No les puedo decir que no.

Así que tengo esperanza en los frameworks MVC. He probado MonoRail y los resultados han sido muy positivos: todo bien separado, diseño tal cual había sido concebido por los creativos, testeo de cada una de las partes, etc. Ahora va haciendo camino ASP.NET MVC (y en Codeplex con código fuente y ejemplos), que no es ni mejor ni peor pero probablemente sea más fácil convencer a las altas esferas si lleva el ADN de Microsoft y no el de Open Source (es lo que tiene el vendor lock-in). En cualquier caso, sea con uno o con otro, creo que es el camino a seguir para librarse definitivamente de los WebForms y volver a jugar en terreno conocido.

Via | Working with the web model [lostechies.com]

No suelo escribir sobre actualidad pero la ocasión lo merece, porque el anuncio me ha gustado y encuentro que es una gran iniciativa por parte de Google: Google Doctype.

La idea del gigante, llevada a cabo por Mark Pilgrim, autor de un par de libros (Dive into Python y Greasemonkey Hacks) es sencillamente un wiki sobre desarrollo web (HTML, CSS, Javascript, ...) bajo una licencia Creative Commons Attribution y permitiendo a todo el mundo con una cuenta de Google modificar, mejorar y ampliar los contenidos. Incluso se pueden descargar todos los contenidos a través de Subversion.

Desde luego es una iniciativa poderosa, en la que además se presentan código interno de Google en la documentación liberado open source y pretenden convertirse en un referente para todos los desarrolladores web. Viendo el video de Mark (un poco largo y con mucho ruido de fondo), el propósito es permitir a la gente crear webs universales, aptas para cualquier dispositivo, navegador y sistema operativo, algo que cada día es más demandado. ¿Sabías que el iPhone no tiene reproductor Flash? Pues eso deja fuera de juego a todas las webs que usan Flash. El futuro depara una cantidad ingente de clientes web heterogéneos y Google apuesta por el HTML, las CSS y el Javascript como una respuesta a esta situación.

En resumen, que hay un nuevo referente en cuanto a documentación para el desarrollo web, que viene a completar los que hay ahora, como el sitio oficial del W3C o una de mis favoritas: Quirksmode.

Via | Google Doctype: Documenting the Open Web (ajaxian.com)

Llevo tiempo queriendo escribir sobre este tema pero quería acabar de escribir un pequeño script en Python para si un servidor dado tiene o no activada la compresión.

La importancia de este mecanismo es que sirve para reducir significativamente el ancho de banda utilizado con un coste de CPU bastante bajo. Además, gzip es un mecanismo ampliamente soportado por todos los navegadores (publicado en la RFC 1951) desde hace años y por supuesto por los servidores web. Se basa en el algorimo deflate y permite compresión de un archivo cada vez (es decir, no es como el zip o el rar que pueden almacenar varios achivos y carpetas) y en entornos unix es ampliamiente usado en los archivos .tar.gz (tar almacena la estructura sin comprmir y gzip comprime el resultado).

Evidentemente, no hace milagros pero es muy efectivo para la compresión de HTML (.htm, .html), Javascript (.js), CSS (.css) y por supuesto archivos dinámicos resultado de todo tipo de entornos (.aspx, .asp, .php, .py...). Comprimir las imágenes por ejemplo no sirve para nada salvo para perder el tiempo y desperdiciar CPU (a lo mejor .bmp si que los comprime... pero espero que nadie esté sirviendo estos archivos en su servidor).

En Apache suele estar activada por defecto en la mayoría de instalaciones (a través de mod_gzip), aunque puede que haya que activarla o configurarla manualmente si no se ajusta al las necesidades.

En IIS, el proceso es un tanto más laborioso, aunque con la versión 6 (y la 7, naturalmente) viene de serie todo lo necesario para activar esta compresión (aun así hay módulo ISAPI de terceros). Una buena explicación en español y otra en inglés no vendrán nada mal. Lo único delicado es no poner nada mal en la metabase porque en ese caso no hará ni caso.

Luego, hay unos cuantos sitios para comprobar si todo ha funcionado bien, pero uno de los que más me ha gustado es test mod_gzip/gzip de WhatsMyIP.org. O también se puede adaptar mi pobre script:

import urllib2;
import httplib;
import StringIO;
import gzip;
import zlib;

URL = "http://codelog.climens.net";

httplib.HTTPConnection.debuglevel = 1

req = urllib2.Request(URL);
req.add_header('Accept-encoding', 'gzip');

opn = urllib2.build_opener();
f = opn.open(req);

encoding = f.headers.get('Content-encoding');

gzipped = 0;

if encoding=='gzip':
    cdata = f.read();
    cdatasize = float(len(cdata));

    cstream = StringIO.StringIO(cdata);

    data = gzip.GzipFile(fileobj=cstream).read();
    datasize = float(len(data));

    gzipped = 1;
else:
    data = f.read();
    datasize = float(len(data));

    gzipped = 0;

if gzipped==1:
    print 'Gzip compression: Enabled';
    print 'Compressed size: %d bytes' % cdatasize;
    print 'Full size: %d bytes' % datasize;

    print 'Ratio: %0.2f:1 (%0.1f%%)' % (float(datasize/cdatasize), float(100 - cdatasize*100/datasize));

else:
    print 'Gzip compression: Disabled';
    print 'Content size: %d bytes' % datasize;

Feliz compresión.