Programación

Luego de trabajar en muchos proyectos con Drupal 6 y crear temas con el nuevo API, incluyendo el reciente Woodpig en Ventanazul, he aprendido mucho y decidí reunir algunos consejos que estoy seguro te ayudarán, estimado drupalista, al convertir tu próximo diseño en un sitio corriendo con Drupal. ¿Suena bien? Ok, a sumergirnos en el nuevo API de temas de Drupal 6.

Esta es la parte final en la serie sobre Emacs y Vim como editores para programadores. Ya he hablado sobre Emacs en la primera parte y acerca de Vim en la segunda. Veamos ahora cuál de los dos prefiero para modificar mi código, y en realidad todo lo demás.

Esta es la segunda parte de una serie de tres sobre Emacs y Vim como editores para programación. En la primera parte hice una breve revisión de Emacs y ahora hablaré un poco sobre Vim.

Sí, ya sé que hay bastantes comparaciones entre Emacs y Vim por toda la Red pero quería añadir la mia y enfocarme en el uso de ambos editores como herramientas de programación.

Algunas publicaciones mencionan que existe una guerra santa entre los usuarios de Emacs y Vim pero no creo que guerra sea la palabra correcta y me niego a comentar sobre lo de santa. Guerra es algo que hace la gente estúpida y nosotros, los buenos programadores, no somos estúpidos.

Emacs y Vim son editores muy poderosos para usuarios avanzados (y tú eres uno de ellos, ¿correcto?), son herramientas muy útiles que nos permiten escribir y modificar código muy rápido. Tanto Emacs como Vim pueden ser usados como procesadores de texto, yo escribo prácticamente todo en Vim, desde los borradores de mis mensajes de correo y los artículos en mis sitios hasta mi próximo libro. Emacs va un poco más allá y ofrece un entorno en el que se puede hacer mucho más que editar texto.

Escoger herramientas de programación es algo muy subjetivo; cambia de persona a persona. Algunos se acostumbran a ciertas aplicaciones y deciden quedarse con ellas aún si nuevas y mejores opciones aparecen. Yo intento ser más abierto, si existen alternativas que podrían lograr que trabaje mejor y más rápido suelo invertir algo de tiempo aprendiendo, y algo de tiempo podría ser desde unas pocas horas hasta algunas semanas.

He escrito esta serie de tres artículos para ayudarte a tomar la mejor decisión sobre qué editor, Vim o Emacs, debes usar para escribir tu código. Es una decisión muy importante, en especial si pasas más de ocho horas al día sumergido en código. Intentaré concentrarme en productividad para programadores.

En esta primera parte hablaré sobre Emacs, la segunda entrega será sobre Vim y concluiré la serie con algunas ideas sobre qué editor creo que deberías usar para tus labores de programación. Todo esto, por supuesto, basado en mi propia experiencia.

Si ya usas Vim o Emacs, no pretendo que cambies de editor pero darle un vistazo al otro lado y comparar puede ser útil, e incluso podrías encontrar algo de inspiración. Si no trabajas con ninguno de ellos aún y te consideras un hábil programador este puede ser el momento para empezar.

Es sábado y decidí empezar el día continuando mi lectura de Introduction to Algorithms (Cormen, Leiserson, Rivest y Stein), un libro fascinante y de lectura obligada para todo programador, sin importar en qué lenguaje escribas tu código.

Y mientras corría pruebas en Python recordé cuando empecé a programar y en qué lenguaje. Fue exactamente hace 24 años, en 1984, tenía 12 años y mi primera computadora, una PC XT (Intel 8088, 4.77 MHz) tenía menos de seis meses en casa.

El lenguaje era Basic, primero como BASICA y luego como GW-Basic en DOS 3.2.

¿Y tú? ¿A qué edad empezaste a programar y en qué lenguaje?

Mi pequeño proyecto en Django y Facebook necesitaba procesar una cadena de texto en JSON. El objetivo es permitir a los usuarios copiar y pegar varios parámetros de configuración como una sencilla operación y evitar completar múltiples campos en un formulario. Hora de solicitar la ayuda de simplejson.

Empezamos con una prueba en la consola de Python, o mejor aún, iPython. Primero importamos el módulo:

import simplejson

Y ahora a definir una variable para el texto en JSON y pasarla a simplejson:

band = "{'name': 'Mando Diao', 'genre': 'rock and roll', 'bid': 19383}"
json = simplejson.loads(band)

El resultado es una excepción ValueError. Intentaré cambiando el orden de las comillas, simples para encerrar todo el texto y dobles para las claves y valores de JSON:

band = '{"name": "Mando Diao", "genre": "rock and roll", "bid": 19383}'
json = simplejson.loads(band)

Y ahora funciona, no hay error:

print json
{u'genre': u'rock and roll', u'bid': 19383, u'name': u'Mando Diao'}

Me parece un poco extraño pues siempre he usado ambos tipos de comillas en mi código Python sin problemas. ¿Habías notado este detalle con simplejson? No pude encontrar ningún comentario al respecto en la documentación.

Un último dato, el nuevo Python 2.6 incluye un módulo json, parece ser una adaptación de simplejson. Excelente.

Recientemente he estado escribiendo una sencilla aplicación Django para Facebook.

Empecé con algo sencillo usando HTML en local, usando el servidor de desarrollo que Django ofrece, y luego hice algunos cambios en las plantillas para utilizar FBML de acuerdo a una variable que llamé IN_FACEBOOK y que inserté en settings.py.

Luego añadí PyFacebook para conectarme al API de Facebook desde Python y configuré mi aplicación de acuerdo a las instrucciones de Facebook.

Finalmente modifiqué la configuración de port forwarding en mi router para que Facebook pueda conectarse a mi servidor en casa usando el IP público, y dinámico, de mi conexión.

Todo iba bien hasta que empecé a notar que luego de cada cambio en mi código la aplicación en Facebook retornaba un código HTTP 200.

Creí que se trataba de un problema en mi conexión ADSL y decidí mover la aplicación a un servidor real, con un IP público fijo, pero el problema continuaba. Luego de cualquier cambio en mi código Facebook retornaba HTTP 200 en la aplicación. Para corregir el problema necesitaba refrescar el navegador tres o más veces.

Y aún cuando mi aplicación se encuentra en desarrollo empecé a sospechar del servidor que Django ofrece y opté por configurar Django con Apache y mod_python.

!Presto¡ Ese era el origen del problema. Por lo visto el tiempo de respuesta del servidor de desarrollo de Django era muy corto para Facebook.

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.

He tenido suficientes problemas con permisos y bases de datos corruptas en el repositorio Subversion que uso en uno de mis servidores de desarrollo. La mayoría de problemas estaban relacionados con Berkeley database, el método de almacenamiento predeterminado para Subversion, al menos hasta la versión 1.4.4, así que decidí que era tiempo de cambiar a FSFS.

Y aún si el excelente libro de Subversion contiene una sección que explica como configurar usuarios y permisos, además de crear scripts para usar el umask correcto, no me sentía muy seguro manteniendo mi repositorio con Berkeley DB, un método que incluso el equipo de desarrollo de Subversion considera muy sensible a interrupciones.

Algunas de las ventajas de FSFS sobre Berkeley database son:

• Puede ser usado en directorios de solo lectura y no depende de umask
• Es independiente de la plataforma
• El tamaño del repositorio es ligeramente menor
• Puede ser usado con network filesystems
• Es prácticamente insensible a interrupciones

Así que sin pensarlo mucho cree un nuevo repositorio usando FSFS. Solo es necesario añadir el parámetro --fs-type fsfs de esta manera:

$ svnadmin create --fs-type fsfs /path/to/repos

Te recomiendo no perder tiemp con Berkeley database al configurar Subversion, usa FSFS y te ahorrarás muchos problemas.

Muy pronto escribiré más sobre Subversion y cómo lo uso en todos mis proyectos de desarrollo web.

¿Qué herramientas de código abierto existen para modelar bases de datos? Es la pregunta que muchos desarrolladores nos hacemos a menudo.

Existen varias alternativas comerciales, muy sólidas y completas, claro que sí, pero los precios son prohibitivos para la mayoría de desarrolladores solitarios que rodamos por el mundo. Basta un ejemplo: el reconocido CA Erwin Data Modeler cuesta US$ 3995 por licencia, con esa cantidad prefiero completar mi lista de gadgets que quiero para el 2007 y añadir otra laptop con Linux a mi arsenal.

Hace algún tiempo encontré a DBDesigner 4 y lo utilicé en varios proyectos para modelar mis bases de datos MySQL, el único RDBMS que maneja, y me alegré al saber que MySQL había adquirido el producto y lo relanzaría como MySQL Workbench, sin embargo MySQL ha enfocado sus esfuerzos en sus otras herramientas y el avance en MySQL Workbench no ha sido significativo, aunque hace poco leí en los foros de MySQL que pronto estaban retomando con fuerza el desarrollo de Workbench. DBDesigner 4 aún está disponible y es una buena opción si solo necesitas modelos para MySQL, aunque la instalación en Ubuntu es un poco complicada (en Fedora no tuve problemas).

¿Pero qué sucede si, como yo, también usas PostgreSQL? La única alternativa de código abierto que encontré hace algunos meses fue Mogwai ER-Designer, permite trabajar no solo con MySQL y PostgreSQL sino también con Oracle y otros RDBMS comerciales. Mogwai ER-Designer es una aplicación Java por lo que corre en cualquier sistema operativo. Desafortunadamente la interfaz aún necesita un poco más de trabajo y el proceso de creación de modelos, aún cuando teóricamente correcto (incluyendo el uso de dominios), no es muy amigable, ello sin contar que el desarrollo de la aplicación parece haberse detenido.

La opción que ahora estoy usando, y que recomiendo, es Power*Architect, al igual que Mogwai está escrito en Java, por lo que es multiplataforma, y funciona tanto con MySQL, PostgreSQL, Oracle y otros RDBMS.

PowerArchitect tiene una interfaz mejor diseñada, crear modelos es muy sencillo y generar SQL toma unos pocos clics. El equipo de desarrollo decidió abrir el código de PowerArchitect hace muy poco y aunque hay mucho por mejorar (como el uso de tipos nativos para auto_increment en MySQL y serial en PostgreSQL) creo que van por muy buen camino y la versión 1.0 promete.

Así que allí lo tienen, hay una luz en el horizonte de las aplicaciones de código abierto para modelar bases de datos. ¡Oh!, y si conoces más cuéntanos sobre ellas.

Actualización 19 setiembre: Sean me comentó que los tipos nativos auto_increment en MySQL y serial en PostgreSQL ya funcionan en las últimas versiones de Power*Architect.