¿Es una ingeniería? ¿dejó de serlo o siempre fue una labor artesanal? ¿O es una labor artística, poética?
Yo creo que en ese sentido los democoders y programadores de videojuegos (cuando no lo hacen víctimas de la “explotación” de un proyecto comercial) llevan (¿llevamos?) una ventaja al resto de la especie humana en esto de comprender la verdadera naturaleza de la programación.
La programación siempre ha sido, es y será una sola cosa:
Enseñar a una máquina a soñar con una oveja eléctrica.
Hace tiempo me rondaba la idea de compilar en un script una interfaz sencilla y unificada a los distintos comandos que empleo cada día para administrar los sistemas de paquetes, hoy me he animado y he escrito uno que crea un modo bastante sencillo de administrarlos en Ubuntu y FreeBSD… es una primera idea, he buscado a ver si había algo así ya hecho, no he visto nada (me extraña) pero bueno por si acaso aquí está, la herramienta se llama pkt y acepta los siguientes comandos:
Además valida que las herramientas necesarias estén instaladas, ejecuta adecuadamente sudo donde corresponde, y en cada acción muestra el comando ejecutado con lo que supongo que también tiene un cierto efecto “pedagógico”. Con una pequeña adaptación también valdría para OpenBSD, y supongo que para sistemas tipo Fedora…
Usa arrays de datos por lo que requiere una versión más o menos moderna de Bash, en mi Ubuntu estoy usando la 3.2.48.
Actualización 29/05/2009: Enlace de descarga (v0.7) desde su repositorio en Google Code
Creo que rara será la persona que lleve un tiempo usando el correo electrónico de manera profesional y no se sienta algo incómodo cuando algún bienintencionado familiar/amiguete le envíe a su correo de trabajo esa bonita presentación/animación de 25 megabytes para ver paisajes, las piruetas de un lindo gatito, etc… mediante este código en el directorio personal (home) en .procmailrc podemos reenviarlos sin guardarlos en el buzón de trabajo a otra dirección de correo más conveniente (más indicaciones mediante man procmailrc), las dos primeras líneas comentadas son útiles, opcionalmente, para el depurado del functionamiento del fichero de reglas:
# VERBOSE=YES
# LOGFILE='procmail.log'
:0w
* ^Content-Type: multipart
{
:0B
* ^Content-(Type|Disposition):(.|$[ ])*(\.|-)(pps|ppt|mpg|wmv|m4v|avi|flv)
! {direccion@email.alternativo}
}
Hace unos días compré en una tienda un nuevo y flamante pendrive de 16GB, desde que lo tuve en la mano estuve dándole vueltas a cómo convertirlo en algo más que un dispositivo para almacenar toneladas de información. El objetivo, era llevar siempre encima todas las herramientas necesarias para reparar un PC (incluyendo portar encima Linux por si propietario del equipo se prestaba a que se lo arreglara definitivamente 
). Estoy bastante contento con el resultado. Las herramientas que lo han hecho posible:
$servicepack.exe /integrate:$unidad/$path_cd_de_xp_copiado_a_disco_duro
title Ultimate Boot CD (ISO)
find --set-root /iso/ubcd411.iso
map /iso/ubcd411.iso (hd32)
map --hook
root (hd32)
chainloader (hd32)
title Ubuntu Linux Desktop CD (ISO)
find --set-root /iso/ubuntu-8.10-desktop-i386.iso
map /iso/ubuntu-8.10-desktop-i386.iso (hd32)
map --hook
root (hd32)
chainloader (hd32)title Ubuntu Linux (plugin)
root (hd0,0)
kernel /casper/vmlinuz root=/dev/rd/0 pmedia=usbflash boot=casper
PROMPT 0
append file=/cdrom/preseed/ubuntu.seed
initrd /casper/initrd.gz
He probado a intentar incluir otra herramienta interesante System Rescue CD no he conseguido que arrancara con el método anterior (directamente de la ISO), pero hay un plugin para UBCD4Win que mezcla el contenido de la distribución con el contenido del RescueCD. La que estaba incluída en UBCD4Win estaba anticuada con respecto a la última versión.
De vez en cuando, tanto tiempo revisando webs sociales, blogs y demás merece la pena, hoy en DZone he encontrado un artículo con unas citas que son verdaderas joyas, condensando muchas ideas, conocimiento y experiencias interesantes en cada una de ellas, son la definición de gurús de la programación de lo que para ellos es código limpio, o de calidad. Provienen del libro (in english of course) “What is Clean Code?” de Robert C. Martin, y es una lectura a la que me intentaré apuntarme on-line en cuanto tenga tiempo. El primer capítulo está disponible para ir abriendo boca, y aquí es donde están todas estas citas, cada una de ellas merece bastante reflexión (en el libro hay además explicaciones de las mismas por parte del autor, también bastante interesantes):
Bjarne Stroustrup, inventor del lenguaje C++
Me gusta que mi código sea elegante y eficiente. La lógica debe ser directa para que le sea difícil encontrar escondite a los bugs, las dependencias mínimas para facilitar el mantenimiento, el manejo de errores completo, acorde a una estrategia articulada, y el rendimiento lo más óptimo posible para no tentar a la gente a hacer el código enrevesado con optimizaciones sin principios. El código limpio, hace una cosa bien.
Grady Booch, autor de Object Oriented Analysis and Design with Applications
El código limpio es sencillo y directo. El código limpio se lee como prosa bien redactada. El código limpio nunca oscurece las intenciones del diseñador, más bien está lleno de nítidas abstraciones y líneas de control directas.
“Big” Dave Thomas, fundador de OTI, padrino de la iniciativa Eclipse
El código limpio puede ser leído, y mejorado por un desarrollador que no es su autor original. Usa tests de unidad y aceptación. Tiene nombres con significado. Provee una manera, y no varias, de hacer una cosa. Tiene las mínimas dependencias posibles, las cuales están explícitamente definidas y ofrece una API clara y mínima. El código debe ser literario (N.d.T.: ampliamente documentado) porque dependiendo del lenguaje, no toda la información necesaria puede ser expresada claramente en el propio código.
Michael Feathers, autor de Working Effectively with Legacy Code
Podría enumerar todas las características que observo en el código limpio, pero hay una sobresaliente, por encima de las demás. El código limpio siempre tiene el aspecto de haber sido escrito por alguien cuidadoso. No hay nada que obviamente se pudiera hacer mejor. Todas esas cosas ya fueron pensadas por el autor del código, y si tratas de imaginar mejoras, acabas de nuevo donde estabas, sintiéndote lleno de aprecio por el código que alguien te proporcionó – código proporcionado por alguien que se preocupaba profundamente por la artesanía de su oficio.
Ron Jeffries, autor de Extreme Programming Installed and Extreme Programming Adventures in C#
En los últimos años empiezo y casi termino, con las reglas de código simple de Beck. En orden de prioridad, el código simple:
- Ejecuta y supera todos los tests
- No contiene duplicidad
- Expresa todas las ideas de diseño que están en el sistema
- Minimiza el número de entidades tales como clases, métodos, funciones, etc.
De todas estas, principalmente me centro en la duplicidad. Cuando lo mismo se hace vez tras vez, es un signo de que hay una idea en nuestra mente que no está bien representada en el código. Trato de averiguar qué es. Entonces trato de expresar esa idea con más claridad.
Expresividad para mí incluye nombres con un significado claro, y puede ser que tenga que cambiar los nombres de las cosas varias veces antes de darlos por válidos. Con herramientas modernas de codificación como Eclipse, renombrar es bastante económico, por lo que para mí no es un problema. La expresividad de todas formas, va más alla de los nombres. También observo si un objeto o método está haciendo más de una cosa. Si es un objeto, necesita ser dividido en dos o más objetos. Si es un método, siempre uso en él la refactorización de la Extracción del Método, resultando en un método que dice con más claridad lo que hace, algunos submétodos diciendo cómo lo hace.
Duplicidad y expresividad me toman largos periodos para conseguir lo que considero código limpio, y mejorar código sucio con simplemente estos dos conceptos en mente puede hacer una enorme diferencia. Hay no obstante otra cosa que de la que también estoy al tanto, que es más complicada de explicar.
Después de años en este trabajo, me da la sensación de que todos los programas están hechos de elementos similares. Un ejemplo es “encontrar cosas en una colección”. Ya sea que tengamos una base de datos de registros de empleados, o un mapa hash de claves y valores, o una matriz de elementos de alguna clase, a menudo nos encontramos buscando un item particular de esa colección. Cuando me encuentro en esa situación, a menudo adapto una implementación particular en un método o clase más abstracto. Esto me da una serie de interesantes ventajas.
Puedo implementar la funcionalidad ahora con algo simple, por ejemplo un mapa hash, pero desde ahora todas las referencias a esa búsqueda están cubiertas en mi pequeña abstración. Puedo cambiar esa implementación en el momento que quiera. Puedo avanzar rápidamente, mientras conservo mi capacidad para cambiarla posteriormente.
Adicionalemente la abstración a la colección a menudo centra mi atención a lo que “realmente” está ocurriendo, y me ayuda a evitar implementar un comportamiento arbitrario cuando lo que realmente necesito son simplemente unos pocos modos de encontrar lo que quiero en la colección.
Reducir duplicidad, gran expresividad, y establecer con prontitud abstracciones simples. Esto es lo que hace el código limpio para mí.
Ward Cunningham, inventor del Wiki, inventor del Fit, coinventor del eXtreme Programming. Fuerza motivadora tras los Design Patterns. Líder en el desarrollo de ideas para Smalltalk y programación orientada a objetos.
Sabes que estás trabajando con código limpio cuando cada rutina que lees parece exactamente lo que esperabas. Puedes llamarlo codigo bello cuando además hace parecer que el lenguaje está diseñado para resolver ese problema.
