desarrollo web

Gimp, una muy buena alternativa de software libre para diseñar sitios web sin gastar US$ 699 en Adobe Photoshop.

Invitado especial: el chancho de madera.

La versiones solo audio y vídeo para iPod a continuación.

El primer episodio probando una nueva fórmula con In Silico. Un formato más corto y enfocado en menos temas.

En esta oportunidad hablo con Beatriz, mi hija de siete años, sobre desarrollo web, Python y Django.

Como siempre, bienvenidos todos los comentarios y sugerencias.

La versiones solo audio y vídeo para iPod a continuación.

Llega un momento en que todo desarrollador Django debe pensar en cómo implementará sus proyectos en un servidor de producción. La primera vez que lo hice creí que la mejor opción era utilizar Lighty, Apache, mod_proxy y mod_python; poco después descubrí que estaba equivocado. Usar Apache como servidor web al frente para gestionar todas las peticiones a un proyecto Django y pasar, vía mod_proxy, pedidos de contenido estático a Lighty es una mala idea, con esta configuración Apache trabaja incluso para archivos que no tiene que servir, usando más memoria y CPU que Lighty.

Luego de leer algunos comentarios en el artículo original y más sobre la implementación de Django pude confirmar que lo mejor era tener al servidor web de contenido estático al frente y Apache detrás, procesando las páginas generadas por Django.

Reemplacé Lighty con Nginx, que de acuerdo a muchos parece ser más estable, y opté por mod_wsgi en vez de mod_python para conectar Apache con Django. mod_wsgi usa además menos memoria y está preparado para sitios con mayores exigencias. No hay necesidad de mod_proxy en Apache pues Nginx se encarga ahora del trabajo de proxy.

La siguiente es una breve guía, muy precisa y fácil de seguir, para desarrolladores web que saben cómo administrar sus servidores. No tocaré temas como seguridad, memcached, configuración de Django, bases de datos, Apache, DNS u otros aspectos básicos de GNU/Linux. Por supuesto que todos estos temas son también importantes y debes saber cómo encargarte de ellos.

El plan

Esta guía te permitirá configurar un servidor para Django en Ubuntu e incluye todos los pasos para:

• Configurar un dominio para tu proyecto en Django.
• Crear una estructura de directorios para tus sitios en Django.
• Configurar Apache con mod_wsgi para Django.
• Configurar Nginx.
• Servir archivos estáticos para la sección de administración de Django.
• Mostrarle tu próximo éxito en Django al mundo.

Luego de seguir estos pasos tendrás un sitio corriendo con Nginx al frente y Apache hablando con Django detrás. Nginx se encargará del contenido estático y pasará las peticiones de Django para Apache y mod_wsgi.

He probado los pasos a continuación en tres servidores Ubuntu (dos corriendo 8.10, Intrepid Ibex, y otro con 7.10, Gutsy Gibbon) pero todo debería funcionar muy parecido en otras distribuciones de GNU/Linux.

¿Empezamos?

Conocí hace poco a Alan Bernuy, un desarrollador web que desde Piura, al extremo norte de Perú, publica un sitio sobre todo lo que le apasiona en nuestro campo.

Conversamos un poco y lo que resultó fue una simpática entrevista sobre mis últimos diez años en la Web.

Gracias Alan por tus preguntas, por hacerme sentir diez años más viejo y por las ganas que le pones a tu proyecto, eso vale mucho.

Manolo Guerrero, ese mexicano tan divertido que resulta ser un dios de jQuery y excelente amigo me presentó a Andreas Krohn, un emprendedor y desarrollador sueco que es la mente maligna detrás de WebHostNinja. Con Andreas he desarrollado una muy simpática aplicación para Facebook que corre sobre Google App Engine y Django. La aplicación será oficialmente lanzada en unos días y escribiré más sobre ella pronto.

Andreas ahora está considerando usar Django para su próximo proyecto y me hizo algunas preguntas, preguntas que estoy seguro muchos otros desarrolladores deben haber tenido así que decidí publicar mis respuestas y ayudar a quienes recien empiezan.

Germán dice por favor no más Internet Explorer 6 y estoy totalmente de acuerdo.

37signals hace algunos días dejó de lado al viejísimo navegador de Microsoft y el nuevo Facebook ya hizo lo mismo.

Es tiempo que quienes desarrollamos sitios web le digamos adiós al navegador más problemático que existe y colaboremos activamente a promover el uso de estándares web.

Yo ya escribo código solo para Firefox, que por lo general funciona sin cambios en Opera, Safari y Chrome, e Internet Explorer 7, donde a veces basta con ligeros cambios usando comentarios condicionales.

Y si algún cliente pide que escriba HTML o CSS para Internet Explorer 6 le digo que no. Si insiste podría pagar cuatro veces el precio pero estoy seguro que preferirá promover el uso de navegadores modernos y que respeten los estándares web.

Adios Internet Explorer 6. Fue fácil, ¿no?

Hay mucho que leer y absorber en el nuevo Drupal 6. Lo bueno es que para quien haya pasado buen tiempo programando con la versión 5 los cambios se pueden entender en muy pocos días.

Y hablando de cambios, uno de los que más me gusta es como se manejan ahora las plantillas (templates), cada módulo puede incluir sus propios archivos .tpl.php y basta con copiarlos al directorio de tu tema y modificarlos si necesitas algo diferente.

Ayer fue un día relativamente bueno. Después de casi 6 horas pude encontrar un problema que no permitía a Internet Explorer (¡cuándo no!) utilizar la aplicación que estamos desarrollando con Drupal para Facebook en 49st.

Sin embargo, lo primero que encontré hoy en la mañana fueron problemas en Facebook con el código que hasta hace unas horas funcionaba muy bien. ¿Qué pasaba?

Hace algunas semanas me contactó Luis Alarcón, diseñador web chileno que vive en Lima y a quien he tenido el gusto de encontrar en algunas reuniones de la ANWMP, con algunas preguntas sobre diseño web. Hoy me escribe para contarme que ya publicó la primera entrega de su serie: el perfil del nuevo diseñador web.

Una muy buena idea con la participación de varios de los que nos dedicamos a crear sitios y aplicaciones web desde el mundo hispano.

Felicitaciones Luis y esperamos la segunda entrega.

Algo sumamente extraño estaba ocurriendo con algunas de mis funciones en jQuery, en Internet Explorer 6 y 7 me encontraba con este error: Expected Identifier. Como es usual, todo funcionaba perfecto en Firefox.

Luego de googlear un poco me enteré que esto podía suceder si se usan comas extras en algunas expresiones, muy útil saberlo pero no era mi caso.

Luego de algunas tazas de café encontré la línea causando el problema:

var class = $(this).parent().attr('class');

Sí, class parece ser una palabra reservada en Internet Explorer, gracias nuevamente Microsoft por hacer la vida de los desarrolladores web tan dificil.

Solo tuve que cambiar el nombre de la variable para solucionar el problema, usé algo como esto:

var tabClass = $(this).parent().attr('class');

Un poco después encontré otra referencia al problema de usar class, ¡por un demonio!, ¿y dónde estaba ese artículo cuando estaba buscando la solución? Al parecer tampoco se puede modificar clases usando el método attr() de jQuery en Internet Explorer, bueno, supongo que por eso es que tenemos addClass() y removeClass().