Puede sonar obvio, pero es una mala costumbre utilizar frameworks para todo. Cierto, es bueno -muy bueno- apoyarse sobre herramientas que facilitan el trabajo. Pero utilizar frameworks pesados como Rails, CakePHP o Django para absolutamente todo es una mala practica.

A veces tenemos proyectos que sabemos solo son cosas pequeñas que no crecerán. Para este tipo de cosas no es necesario que gastemos más recursos de los que son necesarios y carguemos montones de utilerías que nunca necesitaremos.

Tampoco se trata de que hagas todo “a pie”, no se trata de reinventar la rueda. Pero puedes utilizar librerías específicas en lugar de todo un framework que te intenta solucionar todos los problemas. Te invito a leer un breve texto en SiteCanary sobre el tema.

Las librerías te ayudan a ahorrarte código, los frameworks te imponen una filosofía al hacer lo mismo.

“La mayoría del software hoy en día es muy parecido a una pirámide egipcia con millones de ladrillos apilados unos sobre otros, sin integridad estructural, pero hechos vía fuerza bruta y millones de esclavos.”

~ Alan Kay

Los creadores de Lighthouse si que lo entienden. Win!

Les recomiendo mucho este par de artículos de Steve Yegge, Being the Averagest y Practicing Programming. El señor ha trabajado en Amazon y Google, tiene una especie de mal que le hace escribir textos enormes pero muy interesantes.

Estos artículos hablan de como de viciada esta nuestra profesión y de la mediocridad con la que seguimos muchos después de salir de la universidad. El que sabe Java, solo le interesa aprender más Java. El que sabe Linux, no quiere usar nada más que Linux.

¿Cuantas veces no te has topado con algún programador que simplemente no tiene la mínima intención de seguir estudiando algo que este fuera de su trabajo? La mayoría llegamos a tener momentos en los que simplemente nos conformamos con solo concentrarnos en lo que nos piden en el trabajo e ignorar todo lo demás con el pretexto de que eso no está en nuestra área.

Uno de los problemas esta en que no sabemos como practicar correctamente. Es cierto que “la práctica hace al maestro”, pero no solo tenemos que estar codificando todo el tiempo, eso solo hará que repitamos nuestros errores una y otra vez. Tiene mucha razón en que tenemos que tomar nuestra profesión como la ciencia que es. Leer de teoría de computo, leer sobre historia y aprender del trabajo de los demás.

“Práctica #4: Lee el código de alguien mas por 20 minutos. Para esta práctica alterna entre leer buen código y mal código; ambos son instructivos. Si no estas seguro de la diferencia, pregunta a un programador que respetes que te muestre ejemplos de cada uno. Muestra el código que lees a alguien más y ve lo que piensan de él.”

Steve critica mucho a la falta de competencia en nuestra profesión, y creo firmemente que esta es la razón por la que muchos nos detenemos de hacer un esfuerzo mayor. Simplemente no hay una forma de medirnos unos respecto a otros. Por lo menos no directamente. Y ustedes saben que los nerds necesitamos ver estadísticas para estar motivados.

“Pero ¿cómo es que los programadores compiten? Simplemente no lo hacen. No en la manera que los jugadores de ajedrez o los golfistas por lo menos. ¿La razón? No puedes comparar programadores cuantitativamente, asi que no puedes calcular una calificación o un ranking. [..] Los programadores profesionales simplemente no compiten los unos contra los otros.”

Lecturas muy largas, pero recomendadas.

A pesar de que la computación es una ciencia exacta, el juzgar a un programador no es nada sencillo sino pasas mucho tiempo con él (un tema muy importante si se trata de contratar a alguien). Más importante aún, es lo difícil que es evaluarte a ti mismo objetivamente.

Por eso me encantó esta “tabla de competencias” (vía Wisdom and Wonder) que realizó Sijin Joseph. Es una buena guía para decidir el siguiente tema a estudiar. Casi casi para imprimirla y colgarla de tu pared.

Enlace: Programmer Competency Matrix

El principal lugar en el que busco temas para Textmate ya no es el wiki oficial de Macromates, donde los usuarios mandan sus estilos, sino Textmate Themes.

Este sitio se dedica única y exclusivamente a eso. Y facilitan mucho la tarea de escoger las herramientas de valoración, comentarios de otros usuarios y las capturas de pantalla. Indispensable para todos los que usan este excelente editor para Mac.

Yo he estado tratando de cambiarme a utilizar temas sobre fondos claros, por aquello de que supuestamente mejoran la productividad. Pero aún no puedo dejar Monokai, es demasiado cómodo para mis ojos.

En Tux Radar tienen un excelente tutorial especialmente pensado para aquellos que se esten iniciando en Python o tengan curiosidad de como hacer rápidos prototipos de juegos.

El objetivo del juego es evitar que los círculos que estarán rebotando por la pantalla toquen el puntero. Esto en 55 líneas de código bien explicadas.

Lo único que necesitas es la famosa librería para juegos Pygame y estas listo.

Enlace: Build a mouse game with Python

“Los programadores están en una carrera contra el universo para crear más grandes y mejores programas a prueba de idiotas, cuando el universo esta tratando de crear más grandes y mejores idiotas. Hasta ahora el universo va ganando.”

~ Rich Cook

El SDK (Software Development Kit) de Android 1.5, el sistema operativo para móviles, esta listo.

Entre otras cosas este lanzamiento tiene compatibilidad con las versiones anteriores -incluyes los antiguos SDKs por defecto-, trae un mejor emulador de dispositivos móviles y soporta el uso de plugins que facilitan el uso de librerias externas al SDK.

Puedes leer el release note completo desde la página de desarrolladores.

“Si solo sabes un lenguaje, no importa lo bien que lo sepas, no eres un gran programador“

~ Glenatron en Stackoverflow

Esta cita es muy polémica. Yo en lo personal no creo que sea un argumento definitivo para considerar a alguien un gran programador (¿Qué es un gran programador?).

Pero si creo en el mensaje que da sobre la gran importancia que de conocer más de un lenguaje. No solo laboral sino didáctica.