¿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:

• d{elete}: borrado (suave), no borra datos de configuración en Ubuntu y no borra dependencias en FreeBSD
• D{elete}: borrado (duro), lo contrario de lo anterior
• f{iles}: muestra los archivos en un paquete
• p{acket}: busca paquete por nombre entre los instalados
• i{nstall}: instala paquete (Ubuntu: ligero, sin recomendaciones, FreeBSD sin variación)
• I{nstall}: instala paquete (Ubuntu: completo, con recomendaciones, FreeBSD sin variación)
• u{pgrade}: Actualizar paquetes instalados
• U{pdate}: Actualizar repositorio de paquetes/ports
• v{iew}: Ver información completa de paquete
• V{iew}: Ver todos los paquetes instalados

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:

• Ultimate Boot CD 4 Windows: Excelente para reparar un sistema Windows XP, múltiples plugins, puede incluir incluso aplicaciones comerciales como el antivirus Kaspersky o el conocido Norton Ghost. Incluye de por sí, de todo, antivirus, antispyware, antirootkits, exploradores de Internet, herramientas de diagnóstico, grabación, etc. Esta es la herramienta que serviría de base. Requiere por razones legales contar con una copia de XP para construir la ISO, para actualizar el Service Pack de la que tengamos en nuestro poder podemos hacerlo a mano mediante el siguiente comando:
  $servicepack.exe /integrate:$unidad/$path_cd_de_xp_copiado_a_disco_duro
  o bien usar el programa nlite muy útil por cierto para preparar una ISO personalizada de XP con drivers, Service Pack, y otros programas ya cargados por defecto.
• UBUSB: Un plugin para UBCD4Windows que sin duda merecería ser alzado a la categoría de maravilla. Crea una mini imagen ISO de 40MB, a partir de la generada por UBCD4Win, apta para ser grabada en un CD tamaño tarjeta (que fácilmente se puede portar en la cartera), que arranca a una velocidad de vértigo (el arranque por USB en algunos equipos es bastante leeeeento pues aunque tengan USB 2.0 lo hacen a velocidad de 1.1) y da una compatibilidad total, un par notas sobre los problemas que me encontré (está en desarrollo) es que el formateo del USB no funcionaba bien, lo hice desde Windows directamente, y que requería haber creado la ISO de UBCD4Win para hacer correctamente el volcado a USB (no valía con crear simplemente la estructura de ficheros).
• ISOs adicionales: Además he podido incluir sin problemas la ISO de Ubuntu y la de UBCD, este último proporciona muchas más herramientas interesantes en forma de disco de arranque DOS. Estas ISOs las puedo arrancar desde el menú de boot del USB (no desde el CD, aún) y también emplear las herramientas incluidas en UBCD4Win para grabarlas directamente usando el equipo a revisar, para esto sólo hace falta añadir este código en el archivo menu.lst en el raíz del dispositivo USB una vez cargado ahí el UBCD4Win, suponiendo que las coloquemos en el directorio \iso del USB, es código usando Grub4dos como gestor de arranque:
  
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)
• También es posible cargar directamente la distribución Ubuntu en el USB mediante otro plugin, en ese caso este sería el código a incluir para iniciarla:

  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.

1. Bastante susceptibles a mostrar avisos.
2. Escuchan lo que dices, pero no lo que tratas de decir.
3. Cuando notas algo erróneo y les preguntas qué anda mal, casi siempre responden: “Nada”.
4. En otras ocasiones, pueden reportar sin previo aviso incontables errores a una velocidad alarmante.
5. A menudo pequeñas declaraciones se acaban convirtiendo en trabajos muy complejos.
6. Charlar (smalltalk) se considera importante.
7. Puedes estar haciendo algo que se da por bueno durante años, y de repente es totalmente incorrecto.
8. Te piensas que se van a encargar de sacar la basura, pero al final la tienes que sacar tú.
9. Olvidarte de una regla te puede meter en un lío bastante gordo.
10. Tener la clase y el método apropiado a menudo es la clave del éxito.

(Traducido/inspirado de un anónimo que circula por ahí en inglés)

Llevaba unos días buscando donde estaba el dichoso .xpi por fin hoy lo he encontrado, abrirlo, instalarlo, reiniciar el explorador y listo.

Estos días he estado probando el sistema Eclipse, y la conclusión final es que es una plataforma interesante, eso sí me ha requerido pasar de 512MB de RAM a 2GB, algo que me parece completamente desmedido para un IDE, pero Java es un devorador de recursos. Bueno el motivo de este artículo es un curioso quick-hack, cómo usar Eclipse PDT (PHP Developer Tools) en sistemas de 64 bits (actualmente estoy usando Ubuntu Hardy Heron Beta). He probado a instalarlo como plugin, pero la instalación siempre me fallaba al no encontrar algunas librerías en formato x64, el caso es que este método es aún más sencillo:

1. Descargar Eclipse edición PDT
   (sólo está para 32 bits)
2. Descargar Eclipse edición Classic (Nos llevará esta vez sí, a la versión para 64 bits. Debe ser la versión 3.3 [Europa], para la versión 1.0.3 de PDT; buscar la versión correspondiente de Eclipse Classic en caso de actualización de PDT)
3. Descomprimir ambas ediciones, y copiar sobreescribiendo los ficheros de la Classic sobre los de la edición PDT.
4. Voilà!

Adicionalmente he instalado XDebug, y funciona bastante bien, breakpoints, vistas de variables, etc, en Hardy por ser beta supongo el paquete venía sin el módulo dentro (había un bug al respecto) por lo que lo he instalado a través de pecl directamente con los siguientes comandos:

• sudo apt-get install php-dev
• sudo pecl install xdebug

Luego en /etc/php5/conf.d/xdebug.ini he puesto esta configuración (supongo que se deberá ajustar el path para otras distribuciones):

# XDEBUG
zend_extension=/usr/lib/php5/20060613/xdebug.so
zend_extension_ts=/usr/lib/php5/20060613/xdebug.so
zend_extension_debug=/usr/lib/php5/20060613/xdebug.so
#xdebug.auto_trace=on
xdebug.remote_enable=1
xdebug.remote_port=9000

Tras comprobar con un fichero de prueba con phpinfo() que se estaba cargando bien el módulo, he seleccionado el perfil de XDebug en Eclipse y, hecho, funcionando.

Aquí una captura:

PD. Aunque ha sido un experimento interesante, en los últimos días he estado muy activo com Vim, y he comprobado que prácticamente todo lo que puedo hacer en este entorno tan exigente de requerimientos, lo puedo hacer igual o mejor en este potentísimo (aunque quizás un poco críptico para novatos) editor, requiriendo tan sólo unos pocos megas de RAM, incluyendo el debugging en PHP, todo esto, ¡sin salir de la terminal!. Pronto una entrada hablando del tema…

… ¡ para un terminal con Vim !

Quien me lo iba a decir, después de tantos años personalizando mi querido Emacs… Llevo unos días estudiando las funcionalidades del editor de moda, Textmate, e integrándolas en mi Emacs, que ya está prácticamente “mimetizado” con muchas nuevas funciones, que iba a explicar por aquí…

El tema es que, a la hora de estudiar el Vi/Vim, me parecía un editor muy eficiente para cambios rápidos en ficheros, pero para emplearlo en sesiones de programación, siempre me había echado para atrás lo de la dualidad de modos y la navegación, que reconozco que esto último no la había terminado de entender hasta hace poco; tras estudiarlo más profundamente en las últimas semanas, y especialmente con un “truco” para este editor que he leído hoy (en realidad es casi una obviedad pero hasta que no te la cuentan no caes en ello como suele pasar),  me he terminado de convencer: al pulsar <Alt> + [tecla] se genera la secuencia <ESC> + [tecla] con lo que no hace falta pulsar <ESC> para pasar de un modo a otro, basta con acompañar con <Alt> el comando que queramos introducir DIRECTAMENTE.. funcionalidad que se pierde, si nos salimos del terminal eso sí…

En fin, nunca te acostarás sin saber una cosa más… fuera sombreros, este editor es una absoluta genialidad.

PD. Esta conclusión sólo es relativa al sistema de navegación y edición en Vim. Tengo que ver ahora si los complementos que existen y la documentación que los acompaña, para lo que yo necesito, están a la altura de Emacs, que en este sentido me parece aún lo mejor que conozco…

Desde hace un tiempo tengo un slug pegado a mi mesa, este mini-servidor con linux (una vez “unslugeado“) me viene estupendamente, por ejemplo (entre otros muchos usos) para dejar descargando durante días grandes backups de mis servidores, un problema que ha veces he tenido que afrontar es el corte de una transferencia sftp, para continuar con la transferencia, ya que sftp no contempla retomar la descarga en un punto extacto, la utilidad rsync viene en nuestra ayuda (que debe estar instalada tanto en el servidor como en el cliente):

# nohup rsync --partial --progress \
  --rsh=ssh usuario@servidor:directorio/fichero_remoto fichero_local & > fichero_info_salida

Notas:

1. Se requiere especificar el fichero local
2. nohup es una utilidad aparte que evita que un comando se corte al abandonar nuestra sesión en el slug.

Si tenemos que introducir contraseña, para dejar el proceso en segundo plano no poner el umpersand (&), tras escribir nuestra clave, pulsar Control+Z y luego introducir la orden:

# bg %[número de trabajo, se ve el número con el comando jobs]

Fuente: ubuntuforums.org

Ayer descubrí, enredando por del.icio.us, un software llamado nXhtml para la edición web en Emacs que parece un regalo caído del cielo. ¿Características? Integración perfecta de colorización, indentación de múltiples lenguajes (php, ruby, asp, etc), análisis en tiempo real de la sintaxis HTML, autocompletado de tags inteligente, contracción y expansión de bloques HTML por nivel, generación automática de tablas de contenido, integración con Tidy para validación 100% W3C compatible de la sintaxis, y muchas más cosas que estoy descubriendo. Por fin un modo en desarrollo para Emacs, que parecían todos un poco olvidados. Más información también en la Wiki de Emacs.

Aquí mi configuración personal en el fichero .emacs:

;; Carga librería, ajustar path según conveniencia
(load "nxhtml/autostart.el")
;; Extensiones para autocarga del modo
(add-to-list 'auto-mode-alist '("\.html$" . nxhtml-rga-mode))
(add-to-list 'auto-mode-alist '("\.htm$" . nxhtml-rga-mode))
;; Sólo fondo especial en submodos (php, javascript, etc)
(setq mumamo-chunk-coloring 'submode-colored)
;; Saltar pantalla de bienvenida
(setq nxhtml-skip-welcome t)
;; Por si queremos desactivar el modo de validación automático
;;(setq rng-nxml-auto-validate-flag nil)
 ;; Modo personalizado de inicio
(defun nxhtml-rga-mode ()
"Modo personal de Rubén"
(interactive)
(nxhtml-mumamo)) ;; Thanks to LeoB for his note with this change from 1.03 to 1.17  

;; Combinación teclado para forzar lanzado del modo
(global-set-key "C-cW" 'nxhtml-rga-mode)

Para los interesados en buscar alternativas, cómo montar un entorno de desarrollo basado en PSGML y otros.

Los short-tags en PHP (“<?” frente a “<?php”) son un invento maléfico, producen una ambigüedad con la cabecera de los ficheros XML (“<?xml”) que le puede volver loco a uno sin comerlo ni beberlo ya que el parser de PHP en ese caso interpreta que lo que viene detrás es código PHP, y se para al detectar supuesto código erróneo.

Aquí va un comando mágico para pasar de una vez las cabeceras de un proyecto al formato extenso, lo que si hacemos en todos los proyectos nos permitirá poder desactivar esta opción en php.ini (Además de ser la opción recomendada para código distribuido, por compatiblidad). Requiere tener instalado Mysql, que viene con una cómoda utilidad para reemplazar cadenas en el interior de un fichero (replace):

$ cd [proyecto]
$ for i in `find . -exec egrep -l "^[<?]+$" {} \;`; do  \
 replace "<?" "<?php" -- $i; done

Ojo sólo es válido para ficheros tipo bloque de código PHP (es decir que comienzan con el “<?”, no para ficheros plantilla que la emplean en múltiples ocasiones dicho tag en mitad de líneas interseccionándolo con HTML, para este último caso sólo haría falta modificar la expresión regular).

Un comportamiento oscuro de un brillante programa. En la versión 0.11.2 de Rhythmbox no hay manera aparente de eliminar un podcast feed, (sólo se puede en principio borrar los episodios ya descargados).

En principio iba a tocar directamente el archivo de configuración xml del programa, pero he encontrado la solución: Marcando el recuadro de Ver > Examinar aparece la lista de fuentes suscritas, allí es posible eliminarlas.

Fuente:  forums.fedoraforum.org

Gnome asocia el último nuevo programa empleado para abrir un tipo de fichero, desde Nautilus, como la opción por defecto; sea este realmente compatible o no, lo que puede acabar generando un inconveniente, ya que en el entorno visual no hay donde deshacer esta asociación.

En caso de no serlo, para corregir el desaguisado se debe ir a “~/.local/share/applications/mimeinfo.cache“,  donde se van tomando nota de todos los programas empleados por cada extensión. Eliminando de ahí la entrada errónea correspondiente, y reiniciando la sesión de Gnome, todo OK de nuevo.

Si deseamos cambiar la preferencia global para alguna aplicación, podemos tomar nota de su descripción por defecto en el sistema en “/usr/share/applications/defaults.list“.

Para finalizar, un “killall nautilus” hará el truco para que se reconozca nuestro cambio en la configuración (si no, reiniciar la sesión)

Más info: http://ubuntuforums.org

Kiss, ademas del consabido contacto labial es el nombre de una filosofía de desarrollo de software, que no sé si porque estoy peinando canas ya dedicado a esto de los ordenadores, cada vez me viene con más frecuencia a la mente. El tema es que en estos tiempos en los que vivimos, necesitamos lo simple. La gente busca y paga religiosamente, cualquier servicio que facilite aquello de la ley del mínimo esfuerzo, en una sociedad cada día más y más compleja. Para esto esta filosofía es muy clara:

KISS = “Keep It Simple Stupid”

O más polite:

KISS = “Keep It Short and Simple”

Dándole vueltas el otro día a la idea, una traducción a la lengua de Cervantes, sería el principio BESOS:

“Básate En lo Simple, O Sufre”

Mucha simplicidad para todos.

Estos alias me son tremendamente útiles para manejar Apt (y el software relacionado), a definir en ~/.bash_aliases:

alias apr="sudo apt-get autoremove"
alias apd="sudo apt-get autoremove"
alias apf="dpkg -L"
alias api="sudo apt-get install"
alias app="dpkg -l | grep"
alias aps="apt-cache search"
alias apu="sudo apt-get upgrade"

Uso:

• apr [paquete]: Remove; borrar un paquete (y relacionados sin más dependencias)
• apd [paquete]: Delete; idem que anterior
• apf [paquete]: Files; listar los archivos contenidos en paquete
• api [paquete]: Install; instalar un paquete (y dependencias)
• app [expresion]: Packet; listar paquetes instalados filtrados por expresión
• aps [expresion]: Search; buscar en los nombres o archivos de los paquetes disponibles en repositorio

Actualización 13/05/2009: He creado un script para hacer esta filosofía aún más sencilla, compatible con Ubuntu y FreeBSD

A falta de una interfaz gráfica para hacerlo, un par de comandos para añadir nuevas fuentes, se pueden copiar en los siguientes directorios:

$ sudo cp [archivo].ttf /usr/share/fonts

o a (mejor opción en mi opinión):

$ cp [archivo].ttf ~/.fonts/

Después se debe ejecutar el siguiente comando para que el sistema las empiece a usar:

$ sudo fc-cache -f -v

Vía: ubuntuforums.org

Una de las tareas que habitualmente hay que hacer para enviar fotos por correo electrónico o para colgarlas en una página web es reescalarlas. Para GNOME habrán muchísimas utilidades al respecto, pero que tomen un directorio o lista de fotos yo no he conseguido encontrar ninguna (creo recordar que con el GIMP se podía, pero buscaba algo más rápido o integrado con nautilus), en cualquier caso para hacer esto ultrarápidamente desde la socorrida línea de comandos solo necesitamos una utilidad instalada:

$ sudo apt-get install imagemagick

Así para reescalar un directorio de imágenes (ojo que las sobreescribe, no genera salida a otros ficheros) podremos usar este comando, que las ajustará lo máximo posible a la resolución indicada, sin perder la proporción:

$ mogrify -resize 320x240 *.jpg


Para ajustarlas exactamente a la proporción indicada:

$ mogrify -resize 320x240! *.jpg

Vía: www.novell.com

Hoy estaba estudiando, para un nuevo proyecto, las alternativas disponibles a la hora de serializar los datos. Es para uso interno de una aplicación, así que la decisión debía estar basada en la velocidad. He presupuesto que al ser serialize la función de toda la vida en PHP, sería lo más rápido, para probarlo he empleado el siguiente test, que me ha sorprendido un poco.

NOTA 1: XMLRPC ya he presupuesto que sería la opción más lenta, pero está incluído para comparar diferencias.

NOTA 2: Ojo que consume bastante memoria

$array = array("esto","es",array("una"=>"simple","prueba"=>"rapida"));
for($i = 0; $i < 1024*16; $i++) {
    $a2[] = $array;
}

$tests = array(
    "serialize" => array("serialize", "unserialize"),
    "jason" => array("json_encode", "json_decode"),
    "xmlrpc" => array("xmlrpc_encode", "xmlrpc_decode")
);

foreach($tests as $test => $functions) {
    $tiempo_inicio = microtime_float();
    $encoded = $functions[0]($a2);
    $tiempo_final = microtime_float();
    $tiempo_enc = $tiempo_final - $tiempo_inicio;

    $tiempo_inicio = microtime_float();
    $decoded = $functions[1]($encoded);
    $tiempo_final = microtime_float();
    $tiempo_dec = $tiempo_final - $tiempo_inicio;

    print("Tiempo de ".$functions[0]."(): ".$tiempo_enc);
    print("<[nueva-linea-que-quita-wordpress]>");
    print("Tiempo de ".$functions[1]."(): ".$tiempo_dec);
    print("<[nueva-linea-que-quita-wordpress]>");
}

function microtime_float()
{
    list($useg, $seg) = explode(" ", microtime());
    return ((float)$useg + (float)$seg);
}

Que ha dado como resultado esto:

Tiempo de serialize(): 0.105422973633
Tiempo de unserialize(): 0.118716001511
Tiempo de json_encode(): 0.0492351055145
Tiempo de json_decode(): 0.15966296196
Tiempo de xmlrpc_encode(): 0.87334895134
Tiempo de xmlrpc_decode(): 2.80069494247

Conclusión: JSON es bastante más rápido que serialize al codificar, y un poco más lento al descodificar (y sin duda infinitamente más rápido al tratarlo en Javascript). Una pista interesante, a evaluar según el uso que se le den a los datos codificados. Y lo de XMLRPC, bueno se veía venir, lógicamente tiene un tiempo de proceso muy superior a las otras dos opciones.

Y van dos. Por segunda vez una tarjeta de fotos SD queda inutilizada tras pasar por el zócalo de mi cámara digital de fotos (una Nikon Coolpix 4100). Ya no sé si es casualidad o no, el caso es que en esta y en la anterior ocasión, si no recuerdo mal, la secuencia fue la misma, la cámara se queda sin pilas en mitad de un disparo de foto, y luego la tarjeta no funciona. Ni formateo, ni historias, la tarjeta pasó a mejor vida.

En la anterior ocasión perdí la mitad de las fotos de unas vacaciones, pero esta vez era de un familiar que me la había prestado y ahí estaban las fotos íntegras de sus últimas vacaciones (el que corría peligro, después de la tarjeta, era yo en este caso). Total que aprovechando que mi ordenador tiene un lector de tarjetas SD, me he puesto manos a la obra y en una horita y pico buscando y probando opciones, con la ayuda del amigo Ubuntu, he podido recuperar la mayoría de las fotos.

La clave son dos programitas que están en los repositorios (# apt-get install [programa]):

• dd_rescue: Extrae la imagen de un sistema de ficheros dañado, no me ha requerido ningún tipo de parámetros esotéricos, simplemente:
  • Dispositivo de entrada (en mi caso, /dev/sda lo he visto por la información que me daba el sistema tras meter la tarjeta con dmesg | tail)
  • Fichero de salida (el que sea)
• recoverjpeg: Este programa después rastrea el fichero imagen obtenido de la tarjeta, buscando las cabeceras de las imágenes jpg que pudieran estar dentro. (Generando una lista de ficheros imageNNNNN.jpg).

Et voilà! Ficheros recuperados y misión cumplida.

ACTUALIZACION: Finalmente, he podido recuperar también la tarjeta SD, usando fdisk para crear de nuevo las particiones, y con mkfs.vfat para formatearla. De nuevo vivita y coleando. Conclusión, si tienes una cámara con tarjeta, mejor tener un zócalo correspondiente en el ordenador para estos casos.