Martes, 6 de Mayo de 2008 por climens

¡Activa ya la compresión gzip en tu servidor!

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.

Compartir | meneame | fresqui | del.icio.us | digg | technorati
Tags: , , , , , | Sin comentarios

Sábado, 5 de Abril de 2008 por climens

Jornadas de Testeo de Software 2008 (día 3)

Con esta última sesión concluyen las JTS2008, con un balance creo que positivo. Como en todo, hay cosas que mejorar pero hemos seguido viendo cosas interesantes.

De esta jornada destacaría la ponencia de Lee Copeland sobre los cómo saber cuándo terminar de testear. Conseguir testear todo es imposible por lo que hay que sopesar si vale la pena seguir o es mejor dar el producto como suficientemente probado y listo. Cierto es que a veces los deadlines o decisiones de los estamentos superiores son quien deciden cuándo debe publicarse algo, pero aun así, las distintas métricas nos sirven para conocer el estado real del producto.

La ponencia de Peta Heck sobre "Crear y validar requerimientos de usuario", aunque no centrada en el testeo nos recuerda que un buen testeo no se puede realizar si no hay una buena captura de requerimientos, sin ambigüedades ni lagunas, que permita conocer exactamente como debe funcionar un producto y por lo tanto permite realizar un testeo adecuado.

El resto de presentaciones han aportado más pinceladas y ideas sobre cómo implantar el testeo a todos los niveles, haciendo siempre hincapié en unos buenos requerimientos y en la necesidad de la implicación de todos los elementos que participan en el ciclo de desarrollo, no solamente de los equipos de test.

Por la tarde, un par de ejemplos de casos reales de implantación y uso de equipos de testado en Zurich y Metro de Madrid así como otros sobre el uso de algunas herramientas para gestionar el ciclo de desarrollo y testeo: desde la captura de requisitos hasta el testeo de aceptación. Ha quedado patente la importancia de la trazabilidad para conocer qué se implementa, cómo, cuando y quién; para ello, Telelogic presenta DOORS, un software comercial muy completo y también se habla de TestLink (también tienen un blog), un ejemplo de software libre apto para este tipo de tareas. Por supuesto, menos completo que el comercial pero aun así muy válido para PYMEs que no pueden costearse grandes soluciones.

He echado en falta el testeo de seguridad informática, especialmente en entorno web, ya que por ejemplo es el que en realidad ha preocupado más en mi entorno de trabajo dadas las posibles implicaciones que pueden tener los agujeros de seguridad, quizás no tan visibles como un fallo detectado por usuarios finales pero cuyas consecuencias pueden ser desastrosas y comprometer nuestros sistemas. A ver si un día me animo y hago una presentación sobre el tema. ;-)

También me gustaría haber visto algún caso de éxito más cercano de empresas locales (o a nivel estatal) de mediano tamaño que hayan visto mejorados sus productos gracias a la introducción de técnicas más o menos formales de especificación y testeo.

En cuanto a lo que me ha sobrado... en general no me gustan las grandes consultoras ni los mercaderes y por norma las soluciones que proponen desde luego no son escalables ni asumibles por la gran cantidad de PYMEs españolas que necesitan un punto de partida para mejorar sus procesos de calidad del software, además de que suelen hablar de conceptos vagos sin aportar realmente valor a la audiencia. Pero supongo que tiene que haber de todo.

Nos vemos el año que viene.

Link | JTS2008: segunda jornada, 4 abril, mañana

Compartir | meneame | fresqui | del.icio.us | digg | technorati
Tags: , , | 2 comentarios

Jueves, 3 de Abril de 2008 por climens

Jornadas de Testeo de Software 2008 (día 2)

Hoy han empezado de verdad las Jornadas y en general diría que la calidad de las presentaciones no ha estado mal pero he de reconocer que en algunas no me he enterado ni de lo que pretendían explicar.

La que más me ha gustado, quizás por mi prefil de desarrollador al que Google le parece aun cool, la explicación del "Testeo de software en Google" conducida por Julian Harty de Google UK. Siempre es interesante conocer como trabaja esta gente porque es sorprendente lo distintos que pueden parecer en sus formas y métodos. Pero al final, usan las herramientas que usa todo el mundo: Selenium, WebDriver, scripts en Python y seguro que muchas pequeñas herramientas hechas por ellos para simplificar tareas. Finalmente ha dejado un enlace interesante al Google Testing Blog (interesante la idea de Testing on the Toilet :))

Las dos ponencias de Lee Copeland han estado también interesantes, más que nada porque es una persona con experiencia sobre los escenarios y es ameno de escuchar. La de "Todo lo que hay que saber sobre testeo de software se aprende en el jardín de infancia" ha tenido momentos bastante divertidos, aunque quizás el contenido era un poco más superfluo.

La tarde la verdad es que me ha aburrido un poco. Algunos ponentes han reciclado y recortado presentaciones multiusos que no dicen mucho. Me quedaría con la de Tanja Vos, "Testeo en mi empresa, ¿cómo empiezo?", donde ha presentado un retrato impecable de muchas de las PYMES del sector donde hay auténticos empastres: sin orden, sin documentos, sin tests... Propone un trato: que todo el mundo haga testeo unitario y poner una persona exclusivamente dedicada a probar cosas durante seis meses. En ese tiempo se darán todos cuenta de todo el trabajo que hay por delante y la necesidad de realizarlo para mejorar la calidad del software. Una apuesta arriesgada pero interesante.

También se ha hablado del SSTQB (Comité español de Testing) que certifica Testers a nivel mundial a través del ISQTB (International Testing Board) y el INTECO ha presentado sus estudios sobre el estado del testeo en el tejido empresarial español (algunos aun no están publicados).

Para más información, nada como el blog oficial del SQUAC o seguirles por su Twitter.

Link | JTS2008: primera jornada, 3 de abril, mañana
Link | JTS2008: primera jornada, 3 de abril, tarde

Compartir | meneame | fresqui | del.icio.us | digg | technorati
Tags: , , | Sin comentarios