Probar, probar, probar

6 de noviembre, 2008 - por | | Desarrollo, Frontend

En el desarrollo web una de las áreas posiblemente más descuidada es la de probarlo todo con diferentes navegadores. Descuidar cualquier cosa que tenga que ver con el elemento más crucial de todos (el navegador) es un problema bastante gordo. Aunque no hay una solución perfecta, sí existen formas de corregir parcialmente el problema.

Lo primero, antes de nada, es familiarizarse mucho con los navegadores; convivir con ellos; hacerse cargo de su diversidad; entender los distintos motores de renderización (“layout engines”) y cómo se apoyan los navegadores en ellos; comprender la forma en que se produce esa renderización… Todo esto siempre es mejor hacerlo, aunque sea un poquito, que no hacerlo. El resultado, además de los conocimientos concretos, es una actitud desde la que es más fácil resolver problemas y crear cosas, y desde la cual la diversidad dejará de ser percibida como un obstáculo para ser explotada como un beneficio.

Podemos empezar por echarle un ojo al listado que de navegadores que ofrece Wikipedia.

Una vez que ya estamos con esa “mochila”, podemos afinar un poco, distinguiendo las cosas que pueden variar de unos a otros navegadores: marcado, hojas de estilos, nivel del DOM, soporte de imágenes, etc.

Con todo eso, es razonable crear una plataforma mínima de pruebas. La complejidad y coste de la plataforma de pruebas estará en función de nuestras necesidades. En la red hay algunas cosas interesantes.

Por ejemplo, si queremos hacer alguna prueba puntual, y no necesitamos resultados inmediatos, browsershots.org está bastante bien. Es abierto, gratuito y fácil de utilizar, e íntegramente web. Utiliza una nube de ordenadores voluntarios a los que envía las peticiones, y que escupen capturas de pantalla que luego puedes visitar directamente en la web. No es muy rápido, y la captura es plana. En esta misma línea, hay soluciones comerciales como browsercam.com, y litmusapp.com, que funcionan bastante bien, y son más rápidas que la primera. El principal problema que le encuentro a todas ellas es que necesitan trabajar con urls públicas, lo que en entornos de desarrollo no es habitual.

Si, por el contrario, necesitamos realizar periódicamente pruebas y no sólo disponer de una captura de pantalla, sino poder analizar/modificar directamente el código, lo mejor es montarse un entorno de pruebas instalando diferentes sistemas operativos (so), diferentes navegadores y distintas versiones de cada uno de éstos. Esta gama puede variar; si se trata de algo que ya está en marcha y tiene unas estadísticas de uso muy concretas (por ejemplo, Windows XP con IE6 y Windows Vista con IE7), podemos concentrarnos en ese grueso; si se trata de algo nuevo (un portal, una aplicación, etc.), entonces dependería de la orientación que se le quisisera dar (¿pcs? ¿dispositivos móviles?…). En cualquier caso, es bueno habituarse a mirar las estadísticas de uso globales (por ejemplo, el XiTi Monitor), y de ahí extraer una idea sobre lo que se necesita.

La forma de montar un banco de pruebas de este tipo pasará casi siempre por tirar de máquinas virtuales, para correr los diferentes sistemas operativos, e intentar instalar el número máximo de versiones de un mismo navegador en una misma máquina virtual, de forma que minimicemos las complicaciones y la pesadez de tener levantadas varias.

Un tercer elemento importante es el de los dispositivos. Es bueno, para simplificar, considerar los monitores como un dispositivo más, como podría serlo un móvil, una pda o un tablet. Lo más importante es tener en cuenta la resolución de pantalla y la profundidad de color (bits por píxel). En ésto tambien es bueno habituarse a consultar las estadísticas sobre uso de dispositivos, que suelen incluir su resolución de pantalla y su profundidad de color. Como en el caso de los navegadores, hay diversidad; y como entonces, no debemos interpretarla como un obstáculo sino como un beneficio, adaptándonos a ella. Quizás la prueba más importante sea la de comprobar que la paleta cromática que estamos utilizando se ajusta igual de bien a profundidades de 24, 16 y 8. Y es ahí donde el uso los llamados “colores seguros para la web” así como de los “browser-safe colors” (Lynda Weinman) adquiere toda su importancia.

Como hay un montón de chicha en todos estos temas, voy a intentar ir escribiendo entradas para ir complementando esta información.

Gestión de memoria en el kernel de linux

29 de octubre, 2008 - por | | Kernel, Linux

Cuando se trabaja habitualmente con linux la gestión de memoria es un tema recurrente. En entornos de desarrollo del kernel o de software, es una cuestión bien conocida y con la que hay que pelearse a diario. Sin embargo, en entornos web, tanto en desarrollo como en administración de sistemas, es una suerte de caja negra. Tanto porque la complejidad del tema implica una curva de aprendizaje relativamente alta, como porque los lenguajes con los que se trabaja gestionan automáticamente la memoria y, por lo tanto, no exigen un conocimiento práctico de ésta, a diferencia de aquellos otros -por ejemplo, C- que no incorporan dicha gestión automática.

En la red hay algunos artículos que están bastante bien para introducirse en el tema y ordenar un poco las ideas. Además, también hay varios capítulos de libros que merece la pena reseñar.

El capítulo Memory Management del libro de David A. Rusling, colgado en linuxhq.com, es una buena introducción a pesar de que tiene ya unos años y de que, por lo tanto, se basa en una versión del kernel muy distinta a las actuales. Está muy bien organizado y describe los conceptos fundamentales.

En DeveloperWorks de IBM Vikram Shukla publicó en 2006 Explore the Linux memory model. A first step to understanding the Linux design. Es un texto bastante claro que se ocupa del modelo de gestión de memoria en su conjunto: gestión de la memoria virtual, gestión de la memoria física y gestión de la memoria del kernel.

A finales de 2007 LWN comenzó a publicar una serie de 9 artículos de Ulrich Drepper bajo el provocativo título What every programmer should know about memory. La serie se recogió también en un documento en pdf, que se puede encontrar tanto en LWN como en la página personal de Drepper en Red Hat. Los artículos abarcan un abánico muy amplio de temas, y son especialmente interesantes para el desarrollador los dedicados a optimización de caché y multihilo.

El libro de Claudia Salzberg, Gordon Fischer y Steven Smolski, The Linux Kernel Primer, es una obra muy buena. Lástima que sólo esté en papel. Puedes echarle una ojeada en Amazon.com. El capítulo 4 se ocupa íntegramente de la gestión de memoria, comenzando con las “pages” y las “memory zones”. A continuación, la explicación del ciclo de vida del “slab allocator” es realmente buena. Leer el capítulo anterior, sobre el modelo de ejecución de procesos, ayuda a tener una visión de conjunto.

La conocida obra de Greg Kroah-Hartman Linux Kernel in a Nutshell contiene algunas referencias útiles para configurar y optimizar el kernel en relación con la memoria. Se le saca provecho una vez que se han consultado los textos anteriores.

Finalmente, y ya más orientada al hacking, el wiki LinuxMM quiere ser el punto de encuentro para la documentación del funcionamiento de la gestión de memoria, así como para la coordinación de nuevos proyectos de desarrollo relacionados con ésta.

¿Conoces algún otro recurso que te haya resultado útil? Coméntalo e iré actualizando la lista. :-)

Actualización 22 de Diciembre de 2008

El libro de Mel Gorman, Understanding the Linux Virtual Memory Manager, ofrece un acercamiento detallado sobre la gestión de la memoria en Linux, y se encuentra disponible de forma gratuita en formato pdf.