Sí, hoy ya he enlazado una anotación de Microsiervos, pero es que no me he podido resistir… Abraza a un programador es un genial vídeo de DevShop que muestra a la perfección lo que muchos programadores hemos vivido más de una vez:

Ya han pasado 4 de los 5 meses del plan del proyecto y acabo de recibir ayer las especificaciones finales… (y, naturalmente, ¡han cambiado de nuevo!)

[...]

La gente no deja de pedirme que le arregle el correo, así que no tengo tiempo para programar código.

Lo mejor, el final

Al trabajar con sistemas de control de versiones, resulta muy útil tener información acerca de la última revisión del archivo en forma de comentarios, especialmente en clases. Para eso, Subversion integra el sistema de keywords, que permite tener incluir en los archivos información relativa a los cambios realizados en el repositorio.

En el capítulo 3 del libro Contro de versiones con Subversion se detalla:

Subversion has the ability to substitute keywords—pieces of useful, dynamic information about a versioned file—into the contents of the file itself. Keywords generally provide in- formation about the last modification made to the file. Because this information changes each time the file changes, and more importantly, just after the file changes, it is a hassle for any process except the version control system to keep the data completely up-to-date. Left to human authors, the information would inevitably grow stale.

Existen varias palabras clave predefinidas: Date, Revision ( o Rev ), Author, HeadURL e Id. Se deben especificar entre $ y son sensibles a mayúsculas y minúsculas. Por ejemplo, para indicar la revisión se haría $Revision.

Una vez integradas las palabras clave en los comentarios, es necesario establecer la propiedad svn:keywords para el archivo o archivos deseados:

svn propset svn:keywords "Revision" clase.php

Hecho esto, sólo queda enviar los cambios al repositorio, y aunque explorándolo sólo se vea la palabra clave, tanto en la copia de trabajo como en cualquier copia que descarguemos aparecerá el valor: $Revision: 199 $.

Comenté hace unos dias las mejoras de la última versión ( beta ) de Trac, y que ya estaba utilizándola. Todo funciona perfectamente excepto el componente XML-RPC, que permite la integración con Mylyn.

Como todavía no se ha publicado una versión del componente que sea compatible con la última beta del software ( en este ticket se puede ver la evolución ), debemos descargarnos la versión del componente para Trac 0.10 y el parche, y luego ejecutar:

unzip xmlrpcplugin.zip
cd xmlrpcplugin/0.10
patch -p1 < ../../xmlrpc-11.3-genshi.2.diff
sudo python setup.py install

Luego, habrá que activar como de costumbre el componente en la configuración:

[components]
tracrpc.* = enabled

En mi caso, tuve que reiniciar el servidor Apache debido al siguiente error:

ImportError: No module named posixpath

Hecho esto, podemos integrar de nuevo Mylyn con Trac

Hace unos dias comentaba que estaba probando la esperadísima versión 0.11 del estupendo gestor de tickets Trac.

Las mejoras en esta versión son muchas:

• Nuevo sistema de plantillas
• Nuevo y personalizable flujo de trabajo
• Nuevo sistema de permisos
• Integración del plugin WebAdmin
• Visor de repositorios con Ajax

Para mí sigue siendo el mejor gestor de tickets disponible, pero echo en falta ciertas cosas:

• Más facilidad para asignar y reasignar tickets a uno o varios usuarios
• Un buen sistema de control de tiempo de resolución de tickets, ideal para generar diagramas de Gantt
• XML-RPC para integración con proyectos como Eclipse Mylyn
• Internacionalización sencilla, sin tener que parchear código

Algunas de estas funcionalidades pueden añadirse gracias al sistema de plugins ( lista de Edgewall y repositorio en Trac Hacks ), pero nada mejor que tenerlas de serie…

No puedo resistirme a comentar la llamada Paradoja de Python que he visto estos días en varios sitios.

La reflexión dice:

A falta de un nombre mejor lo llamaré la paradoja Python: si una compañía decide escribir su software en un lenguaje poco utilizado comparativamente, serán capaces de contratar a mejores programadores, porque atraerán sólo a aquellos que se molestaron en aprenderlo…

Hasta ahora sólo unas pocas compañías han sido suficientemente inteligentes para darse cuenta de esto. Pero hay una especie de selección natural trabajando: son exactamente las mismas compañías en las que a los programadores les gustaría trabajar. Google, por ejemplo. Cuando ofertan puestos para programar en Java, también piden experiencia con Python.

Paul Graham

Me hace gracia la cantidad de gente que se ofende por esta reflexión. Aquí nadie dice que los programadores de lenguajes tradicionales sean malos. Sí, habrá cracks que programan Python, Java, PHP o Brainfuck, nadie lo discute, pero si hablamos de estadisticas, de la media, la cosa no se aleja tanto de lo comentado por Graham.

Es sencillo, sólo hay que pensar en buenos programadores que conozcamos. ¿Cuántos de ellos se han interesado en aprender lenguajes minoritarios? ¿Cuántos se han interesado en retos y juegos de programación?. Es mas, ¿cuántos buenos programadores hablan de las bondades de C y cuántos malos programadores lo desprecian aunque se conozcan al dedillo todas las clases de .NET?.

Puestos a contratar en aparente igualdad de condiciones para un puesto, quién no contrataría antes a alguien que ha demostrado saber desenvolverse en C ( sí, ¿cuántos dominan C hoy en día? ), Python o algún lenguaje esotérico o a alguien interesado en las matemáticas ( como algún Frikisiervo ).

Además, ¿Ya no se recuerda lo bien que se habló de las técnicas de selección de Google y de los cientos que comentaron que no les importaría trabajar ahí?.

A veces ser programador es frustrante, porque un único caracter fuera de sitio puede provocar una enorme cadena de errores. Y alguien me debió echar mal de ojo porque llevo dos casos en dos días. El que más me costó resolver fué el que una simple / era la culpable de que todo un sistema de publicación no funcionase ( no, no fué Bitacorae ).

¿Qué terapia seguís en estos casos?

NOTA: En PHP 4.3.x $_SERVER["DOCUMENT_ROOT"] devuelve una ruta SIN / al final, mientras que PHP 4.4.x devuelve una ruta CON / al final.

Para m, un IDE para desarrollo web debería tener estas características:

• Libre y multiplataforma
• Gestor de proyectos
• Integración con FTP / CVS / Subversion
• Integración con el entorno gráfico ( Windows, KDE, Gnome… )
• Resaltado de sintaxis para PHP, HTML, CSS, JavaScript, XML…
• Análisis de código ( comprobación de errores )
• Escritura predictiva
• Debugger

¿Demasiado?. Ha dos IDE que cumplen casi todo: el primero es Zend Studio ( de los creadores de PHP ), excelente pero de pago ( 99$ la versión Standard, 299$ la versión Professional ). O outro é Eclipse, «una especie de herramienta universal, un IDE abierto y extensible para cualquier cosa y nada en particular», es decir, es un potentísimo IDE multiplataforma que soporta muchos lenguajes de programación ( Java, C, C++, PHP, Python… ) y es muy extensible por plugins, lo que permite tener de todo integrado en el IDE ( UML, acceso a bases de datos, creación de GUIs, debuggers… ).

Entre los cientos de plugins que existen para todo tipo de cosas ( que se pueden encontrar en páginas especializadas como www.eclipse-plugins.info, www.eclipseplugincentral.com/ o eclipse-plugins.2y.net ), hay dos especialmente interesantes para el desarrollo web. El primero es PHPEclipse, que añade soporte para PHP con escritura predictiva, corrector, resaltado de sintaxis ( tanto PHP como HTML, CSS y JavaScript ) además de muchas características útiles. El segundo es Xored Trustudio, muy similar al anterior ( e incluso añade las mismas características para desarrollo con Python ) pero es software propietario con licencia educativa.

Existen muchos plugins más que pueden ser útiles pero eso ya entra en las necesidades de cada uno…