Tengo la mudanza del piso de Valencia casi finalizada, me queda hacer un viaje para entregar las llaves y recoger cuatro trastos (que hay que ver cómo se acumulan cosas en 2 años).

El tema del piso en Exeter arrancó rápido, pero ahora ha tenido una pequeña pausa... y esperamos que los papeles queden cerrados ya esta semana, porque el día 15 vuelo para allá y espero poder recoger las llaves.

Esto va por todos los que me hacían ya desaparecido: que aún no. Esta semana tengo que arreglar algunas cosas por Elche (comprar una maleta, cosas de bancos, etc), antes de dar la mudanza a Exeter por finalizada.

Como los días son largos, aprovecharé para tomar algún café o alguna cerveza con amiguetes de la zona, que voy a estar una temporada fuera (en realidad vendré por aquí más o menos como cuando estaba en Valencia, pero igual es eso de que estaré más lejos :P).

Sinceramente no recuerdo haber hecho click en algún enlace o banner de publicidad y que eso se haya traducido en algo útil, para mi o para el anunciante, pero sí me parece razonable "soportar" una cierta cantidad de publicidad no intrusiva a cambio de disfrutar de contenidos gratuitos.

Desde que pasamos a esa web 2.0, los sufribles pop-ups fueron desapareciendo. Se ha dado paso a la publicidad llamada contextual, que nos muestra anuncios en base al contenido de lo que estamos viendo.

No solo eso, sino que la publicidad es muchas veces en modo texto, que es poco intrusivo y fácilmente descartable sin mucho esfuerzo; así que inventos como Adblock Plus, que eliminan la publicidad de las páginas que visitamos, tampoco me parece necesario.

Además a mi personalmente me aporta poco, tras tantos años, mis ojos descartan la publicidad con tanta rapidez que para mi es efectivamente invisible.

Pues al final he tenido que cambiar de opinión, y la culpa la tiene el pésimo soporte de Adobe Flash en Linux.

Ya no es por las veces que se rompe el plugin (generando cores, que es divertido contar al final del día), sino porque estos contenidos (no sé si porque están mal desarrollados), muchas veces necesitan el 100% de nuestra CPU a cambio de nada (¡puede ser un anuncio en algún punto de la página que ni hemos visto!).

Estoy con la última versión publicada por Adobe (la 10.0.42.34-release), y ni con esas. Llegamos al extremo de que ver un vídeo con un reproductor Flash es algo justo con mi portátil de un solo núcleo a 1.7MHz, si además hay un par de anuncios en la página... ¡imposible!

Esto lo he venido notando de un tiempo a esta parte, no sé si es porque hay un cambio de tendencia en la publicidad y se abusa del Flash, o que el reproductor de Adobe a empeorado varios enteros, pero me he tenido que instalar el Adblock Plus para recuperar (en parte) mi portátil y poder navegar como lo venía haciendo hace unos meses.

A ver si HTML5 y su soporte de reproducción de vídeo sin añadidos nos da un poco de tregua. Es absurdo que una máquina capaz de reproducir vídeos con calidad de imagen y audio quede obsoleta cuando se reproduce un cutre-anuncio de unos segundos.

Faltan unas horas para que comience la segunda Barcamp Valencia, que se presenta interesante con 156 inscritos, y más gente que probablemente se acercará.

Si hacemos caso a los resultados de la anterior edición, mañana tendremos mucha gente ;).

El año pasado me quedé con las ganas de organizar una signing party, aunque tampoco sé si hubiera tenido mucho éxito, porque creo que la privacidad y el cifrado es una idea difícil de vender estos días (igual me equivoco).

Un poco para quitarme la espinita, he preparado una charla introductoria a GPG, basada en parte en la clase que daba en la asignatura de libre configuración que impartía en la EPSE.

Espero que la presentación guste

Me voy a centrar en los conceptos y la utilidad en el campo de la privacidad de las comunicaciones vía correo electrónico. Nada de consola, que creo que es algo de lo que se abusa cuando se explica GPG.

A ver si sale bien, mi charla y el evento en general. Ya contaré cómo queda todo ;).

Actualización: ya se ha terminado la segunda Barcamp Valencia, ¡y ha sido un éxito! Por ahora mi charla está en Slideshare: Privacidad y la red, introducción a PGP/GPG.

Ya lo comentaba hace poco Jorge por aquí, que hay algunos servicios de alojamiento de proyectos que aplican restricciones a algunos países, y ahora se comenta en Barrapunto.

Concretamente son proveedores de servicio que se encuentran en EE.UU. y aplican las leyes (?) de embargo que ese país tiene contra Cuba, Irán, Siria, Corea del Norte y Sudán (no sé si alguno más).

Recordemos que una licencia es una norma particular, un contrato, que está sujeta a la regla de que no puede contradecir a una norma de rango superior (es como cuando se dice que una nueva ley puede ser anticonstitucional, porque contradice algún punto de la constitución... que es nuestra norma de más alto rango).

Si consultamos esta comparativa de servicios de alojamiento de software open source, veremos (en la columna de Countries blocked from *) que hay al menos dos proveedores que bloquean acceso por este motivo: Sourceforge y Google Code.

No voy a entrar en discusiones improductivas acerca de política ni embargos, pero en mi opinión, si decido que el Software Libre es la forma que quiero para distribuir mis programas, no voy a permitir restricciones artificiales a la parte en la que garantizo que puede ser usado por cualquiera para cualquier propósito.

Es evidente que se pueden buscar soluciones (se monta un espejo de un repositorio bien fácil), pero habiendo otros servicios sin estos problemas (que yo desconocía), creo que hay que tenerlo en cuenta a la hora de elegir dónde alojar nuestros proyectos.

Actualización: evidentemente hay más sitios. Por lo que parece Fedora Hosted también está bloqueando países.

Según el jargon file sobre la ley Zawinski, se enuncia como (traducción libre):

Todo programa intenta expandirse hasta que es capaz de leer el correo. Los programas que no pueden expandirse tanto son reemplazados por aquellos que sí pueden.

Además va en contra de la idea detrás de UNIX, que se componía de pequeños programas que hacían una cosa y, además, la hacían bien.

Es cierto, el desarrollo de todo programa sufre presiones para hacer cosas que realmente no le corresponden.

Llevo tiempo dándole vueltas a qué le falta a Nautilus Flickr Uploader, y la verdad es que se me ocurre poca cosa sin caer en la ley Zawinski. Ajustar algunas partes para que vayan más suaves, y quizás (por petición popular) añadir la posibilidad de hacer throttling (para no quedarte sin conexión cuando se usa todo el ancho de banda para subir fotos).

Pero en realidad no tengo intención de que mi programa permita leer el correo, porque ya hace lo que quería que hiciera ;).

Seguro que más de uno conoce un caso claro que encaja con la idea de Jamie Zawinski.

En realidad tampoco hace tanto que decidí probar GIT con GitHub, pero me doy cuenta de que en lo poco que he programado en casa en estos últimos 6 meses, ya estoy habituado a este SCM.

Simplemente hago lo mismo con GIT que con SVN, salvo algún detalle que cambia (a mejor), y si nos ponemos estrictos... hago lo mismo que ya hacía con CVS, y que aprendí trabajando con RCS :P.

Al final el diablo está en los detalles, pero a grandes rasgos siempre hago lo mismo cuando soy el administrador del repositorio:

1. Desarrollo, evidentemente :).
2. Suelo hacer un git status y luego git diff cuando acabo de implementar una nueva funcionalidad.
3. Realizo un git commit fichero [fichero], para meter en el mismo commit todos los ficheros involucrados en el cambio (eso de los commits atómicos, que no tenía CVS).
4. Pongo un mensaje descriptivo del cambio, normalmente precedido de NEW si es una nueva característica, o FIX si es una corrección.

Hasta aquí no hay cambios respecto a cómo lo haría con SVN, pero más adelante llegan los matices.

Como GIT es distribuido y el trabajo lo hacemos en el repositorio local, necesitamos mandar los cambios locales al repositorio remoto (en este caso en GitHub, que cada vez me gusta más como servicio).

Esto se consigue con: git push.

Otra cosa que es distinta respecto a SVN son los tags, que utilizo para marcar versiones o hitos en el proceso de desarollo.

Por ejemplo: git tag 0.1, para marcar el último commit como versión 0.1. Y luego no hay que olvidarse de hacer un git push --tags.

Para los repositorios que gestiono yo no hay mucho más (porque no me mandan parches, claro :|), como por ejemplo hacer merge de las traducciones que me llegan vía Transifex a la rama donde gestiono las traducciones (que es un poco lioso, eso sí).

Cuando trabajo con un proyecto que usa GIT, como es el caso Mojolicious, solo hay que recordar hacer un git pull (equivalente a un svn update). No he mandado nunca un parche ni hago commits locales, así que tampoco he tenido que mirar mucho más al respecto :D.

En fin, a grandes rasgos sospecho que el SCM no importa mucho, después de haber trabajado con varios, siempre que tengas en la cabeza el funcionamiento general del invento. Lo importante, y lo que al final determina qué usas, creo que es si eliges un servicio de hosting para apoyar tu trabajo, como por ejemplo GitHub (con GIT) o Google Code (con SVN o Mercurial).

En la empresa seguimos con el equipo Trac + SVN, y tampoco nos funciona mal por nuestro modelo de trabajo y porque hacemos uso intensivo de los tickets. No sé si tengo razón en que los servicios de hosting de proyectos son tan importantes, ¿con cuál prefieres trabajar tu?

Esta bitácora tiene, sin contar esta anotación, 1280 entradas, escritas desde Octubre del 2003. Es normal que algunas hayan cogido algo de polvo, y que ya no sea muy interesante leerlas ;), pero otras siguen teniendo validez (muchas de ellas siguen indexadas en los buscadores, y recibiendo visitas a diario, incluso páginas que ya no existen).

Pero es que además soy un blogger de esos que enlazan a otras páginas. Concretamente lo he hecho 4544 veces, y muchos de esos enlaces ya no apuntan a nada. Concretamente 611 :o (como curiosidad se puede ver en la gráfica qué tipos de errores he encontrado).

Llevaba un tiempo pensando en esto, porque cuando ojeaba la máquina del tiempo, no tardaba en encontrarme algún enlace que ya no era válido, y finalmente le he echado dos ratos y he programado una pequeña herramienta: linkcheck.pl.

El funcionamiento es sencillo:

• Se conecta a la base de datos de nuestro blog (lo he hecho bastante abierto, usando DBI casi tenemos independencia total del sistema de gestión -aunque solo lo he probado con MySQL-).
• Busca en la tabla que le indicamos la clave primaria y el campo que guarda el cuerpo de las anotaciones.
• Analiza esos textos buscando enlaces, visitándolos (con HEAD en un primer intento sin descargar la web, y GET cuando no hay más remedio), y generando un informe con instrucciones SQL que, si lo ejecutamos en nuestra base de datos, actualizará las entradas eliminando los enlaces que ya no funcionan.

He querido hacer la herramienta de forma que sea últil a otros, pero como buscar enlaces no es tarea fácil, no me hago responsable de los destrozos que puede hacer (je, por eso genero la salida SQL, para que se pueda revisar :D).

La idea(tm) es que buscamos con la siguiente expresión regular:

(<a.*?href="((https?:\|ftp:\|/)(.+?))".*?>(.*?)</a>)

De forma que para cada enlace tengamos:

• El enlace completo: <a href="http://link.dom/index.html">texto del enlace</a>.
• La URL: http://link.dom/index.html.
• El texto: texto del enlace.

Así, si al verificar la URL el script obtenemos un error (4xx o 5xx), podemos reemplazar el enlace completo por el texto del enlace, con lo que la anotación queda igual, pero nos hemos desecho del enlace muerto.

Evidentemente esto no es perfecto, porque no podemos saber si la web que responde es aquella que enlazamos, pero en general el resultado me parece bastante aceptable.

Muy de vez en cuando podré ejecutar la herramienta para revisar los enlaces y quitar aquellos que ya no tienen sentido. Aunque claro, esta bitácora tampoco durará para siempre, y entonces dejará enlaces inservibles en otros blogs. Porque ya sabéis eso de que nada dura para siempre, ni mucho menos en Internet ;).

Actualización: tampoco hay que fiarse mucho de esa expresión regular, ya la he cambiado un par de veces en el script. Qué verdad esa que cuando tienes un problema y decides resolverlo con una expresión regular, tienes dos problemas.

Igual estamos un poco callados, pero seguimos avanzando a buen ritmo y ya hemos publicado el programa provisional.

Tenemos 13 charlas (puede que entre una más, que tenemos pendiente confirmar), y si miramos el programa de la edición anterior, la cosa parece complicada de superar. Yo creo que hay posibilidades ;), con títulos muy interesantes para asistentes técnicos y no tan técnicos.

La segunda edición de la Barcamp Valencia se llevará a cabo el próximo sábado 30 de enero de 10:00h a 18:00h, en la Escuela Superior de Enseñanzas Técnicas de la Universidad CEU.

Abriremos la inscripción probablemente mañana, y la asistencia es libre y gratuita (¡y no es necesario ser ponente para asistir!).

Actualización: ya está abierta la inscripción. Solo hay que enviar un correo electrónico ;).

El principal problema de tener dos bitácoras definitivamente es la pereza que da decir determinadas cosas dos veces. Creo que es algo que he comentado alguna vez, y la verdad es que cada vez lo tengo más claro :D.

En cualquier caso esto es algo que sí debo comentar por aquí, aunque ya lo haya dejado caer en el otro blog, y es que acabaré el mes de enero trabajando en Valencia, y a mediados de febrero ya estaré en Exeter.

Es relativamente sencillo simplificar la historia en dos puntos:

• Hace tiempo que me quiero ir una temporada a trabajar al extranjero, y se me acaba el tiempo. Creo que me hago mayor, así que es ahora o nunca :P.
• Alex está en Inglaterra, y tiene trabajo allí hasta finales del 2011.

Como diría aquel, blanco y en botella... sí, leche :P.

Además tengo la suerte de que la empresa quiere que siga con ellos trabajando en remoto y desarrollando algunas ideas en el país de Keats, así que profesionalmente la cosa está también interesante. Nunca podré agradecer bastante las oportunidades que me han dado, y que siempre he intentado aprovechar al máximo.

Al final se queda la cosa en 2 años y 1 mes en Valencia (siempre contando, ¡será posible!), que parece mucho... pero para mi está ahí al lado cuando llegué a esta ciudad.

Hay muchas cosas para recordar, y aquí hay poco espacio. Algunas cosas están registradas en la máquina del tiempo (además de las fotos, claro), y las otras ya las revisaremos con una cerveza delante cuando toque ;).

Recuerdo que hace años apuntaba a hard admin: sysadmin toolkit, donde se reseñaban los comandos que, según su autor, deben estar en la caja de herramientas de cualquier administrador de sistemas (tipo UNIX, se entiende).

Esta semana he explicado un par de veces lo mismo, y me doy cuenta que no todo el mundo tiene ese set de herramientas indispensables, que nos facilitan enormemente el trabajo.

Cada maestrillo tiene su librillo, pero aquí están las herramientas que uso casi a diario en el trabajo.

SSH

Es evidente, un 90% del trabajo pasa en máquinas remotas. Pero hay que saber explotar las posibilidades de la herramienta, lo que incluye:

• Ejecución de comandos remotos sin hacer login, como: ssh usuario@host comando.
• Usar compresión cuando tenemos poco ancho de banda, con la opción -C.
• Túneles SSH, para cuando tenemos que acceder a una máquina o servicio rebotando en otra en la que tenemos acceso (ej. ssh -L puerto_local:ip_remota:puerto_remoto -N usuario@host).

  Muchas veces tenemos el acceso administrativo limitado desde una IP, así que hacer túneles es imprescindible. Además, si el protocolo a meter en el túnel es complejo, podemos usar el servidor SOCKS con la opción -D.

GNU Screen

Es útil multiplexar la terminal, para poder tener varias sesiones a la vez con una conexión. No obstante eso no es lo más importante, porque a fin de cuentas podemos abrir más sesiones.

Lo que si es realmente importante es la persistencia que se da a la sesión: podemos dejar una aplicación corriendo (¡aunque sea interactiva!), cerrar la sesión, y recuperar la ejecución de la aplicación más tarde con otra sesión.

A veces realizamos operaciones críticas que no pueden (o deben) ser interrumpidas, así que la persistencia es una red de seguridad más que conveniente.

Watch

Muchas veces tenemos que monitorizar la salida de un comando, y estar ejecutando el mismo constantemente es un incómodo y poco eficiente. Para eso tenemos watch, que lo hará por nosotros en un intervalo de tiempo concreto. Por ejemplo: watch df -h (monitorizará el espacio libre en disco, actualizando cada 2 segundos, que es el valor por defecto).

grep, find

Estas dos herramientas son muy versátiles y complejas, y nos permitirán buscar ficheros, dentro de ficheros, realiza operaciones sobre ficheros, etc.

La pega es que usarlas bien requiere de algo de práctica, sobretodo find, y es indispensable consultar las páginas de manual. A la larga compensa :).

pwgen

Cuando tienes que dar de alta cuentas de lo que sea con cierta frecuencia, te das cuenta de que inventar una contraseña que además sea segura, es complicado. Mucho :D.

Para eso está pwgen, que además de generar contraseñas dentro de un nivel de calidad (ojo, no son completamente aleatorias), tienen musicalidad y son fáciles de aprender (esto es relativo, pero cierto :D).

Otras herramientas

Uso más herramientas, pero en menor medida (como pgrep y pkill). Todas están empaquetadas para cualquier distribución (sino instaladas por defecto).

Es cierto que hay más, y cada cual encontrará igual de imprescindibles otras herramientas. Estas son las mías, y en mi dinámica de trabajo actual, me ahorran mucho trabajo.