• Pequeño, preciso y util, una charla de 2016 sobre algunas utilidades.
• Pequeñito, preciso y útil, Vol 2, la charla corta que di en la OSC en mayo del 2017.

La primera que enlazo la di a alumnos de 2º de Bachillerato que estaban a punto de terminar y les tocaba enfrentarse a su futuro inmediato, y por ello me pidieron que diera una charla sobre lo que es trabajar en el sector de las Tecnologías de la Información.

La segunda charla era una introducción a Ansible en la que describía un poco sus virtudes, defectos y sus principales características.

El cuarto y último tomo (correspondiente a Kick-Ass 3) comienza con Hit-Girl encarcelada y con los demás «superhéroes» acatandoo la orden que prohíbe a los enmascarados. Hit-Girl consigue convencer a Dave para que le ayude a salir de la casa, y le cede todos sus recursos así como planos de las prisiones para que puedan conseguirlo. Sin embargo Justice Forever no consigue liberarla y a partir de ese momento todo se derrumba. Aparece un nuevo señor del crimen, los héroes se acostumbran a una vida pasiva.

Como se puede imaginar comienzan a pasar una serie de eventos que provocan unas reacciones y creo que en este tomo todo tiene más sentido que en Kick-Ass 2, donde me pareció que se trataba de violencia gratuita porque sí, sin dar mucha importancia a las tramas o los personajes. En Kick-Ass 3 sin embargo todos los personajes van llegando al final de la serie, todas las tramas van cerrándose y la historia acaba claramente con un final que te deja una sonrisa. Aunque quizás habría estado bien un final algo más trágico.

¿Me ha gustado? Sí. Y eso que tengo el tomo desde hace un par de meses y me ha dado pereza leerlo, pero una vez que lo he hecho me ha parecido bueno. Mejor que Kick-Ass 2 sin duda pero no mejor que la historia original. Así que comparte el segundo puesto con el interludio de Hit-Girl.

Mi siguiente cómic posiblemente sea Batman, El regreso del caballero oscuro. Ya os contaré.

Una de las peculiaridades del resolver de Unix es que cuando un proceso se inicia lee la configuración de /etc/resolv.conf (es una simplifación) y no vuelve a leerlo. Eso se hace con la función res_init() que inicializa las variables al leer /etc/resolv.conf y no se actualiza al cambiar el contenido. Esto signfica que si cambiamos los nameservers los procesos seguirán usando los antiguos y no aplicarán los nuevos cambios. Esto significa que al cambiar los nameservers si queremos que todo el sistema utilice la nueva configuración lo más práctico será reiniciar el sistema al completo ¡al más puro estilo Windows 98!

Evidentemente no es necesario reiniciar todo el sistema, lo anterior sólo era una generalización ¡sólo necesitamos reiniciar todos los servicios y aplicaciones que tengamos corriendo! ;-) La verdad es que para sufrir esa clase de downtime lo mejor en esos casos al final es reiniciar todo el sistema, y ya puedes aprovechar para otro tipo de actualizaciones o configuraciones.

Sé que cuesta creer un comportamiento tan primitivo, pero creedme que podéis encontrar varias referencias (desde la descripción de res_init) a varios artículos de gente que lo ha vivido como en el caso de http://myhowto.org/java/42-understanding-host-name-resolution-and-dns-behavior-in-java/

However, there is one more aspect of the name resolution – updating the system configuration. Interesting thing about the resolver library in UNIX is that it reads its configuration once upon the first resolution attempt and then never re-reads it. As result, if you change the IP address(es) of the DNS server(s), or the suffix, or any other parameters in /etc/resolv.conf file (the same applies to all resolver configuration files but now we will concentrate on the DNS configuration) the application will not notice the difference. The same applies to all other programs in the system.

There is no standard way to refresh the resolver configuration in Java. However, there is at least two ways to do it from C:
· Call res_init() function of the resolver library
· (more elegant way): reset the RES_INIT flag of the global _res.options variable

This means that those JBoss and Tomcat apps will be using the old DNS servers until you restart them. And that’s trouble.

No me lo creo, eso tiene que ser algo primitivo

Aún así puedes estar pensando que es imposible que Linux sea así, que no tienes que reiniciar todo el sistema para aplicar un cambio de red ¡si nisiquiera Windows se comporta así hoy en día. Pero la triste realidad es que es así, es como está documentado y es como funciona. Si quieres comprobar cómo se comporta tu máquina cuando cambias los nameservers, puedes hacerlo con el siguiente script en Python:


from time import sleep
import socket
while True:
  print(socket.gethostbyname_ex("www.google.com"))
  sleep(3)


Ejécutalo en background o en otra terminal y mientras puedes usar tcpdump para ver el tráfico de red. El script intentará resolver cada 3 segundos, así que si corres como root tcpdump podrás ver las peticiones al nameserver que tengas configurado en /etc/resolv.conf

# tcpdump -i any -n -p port 53

Si en ese momento, mientras tienes corriendo tcpdump y el script Python puedes editar tu fichero resolv.conf y poner un único nameserver distinto al que tienes configurado actualmente (pon 8.8.8.8 o 127.0.0.1 o cualquier IP de tu subred). Verás como las peticiones a de red siguen yendo a la antigua dirección IP.

¡Pero en mi máquina no pasa eso!

Ese comportamiento además de estar documentado se ha pedido su cambio en muchas ocasiones (por ejemplo en http://www.mailinglistarchive.com/fedora-devel-list@redhat.com/msg39340.html pero hasta ahora los desarrolladores de glibc no quieren aplicar ninguno de los parches disponibles que permiten actualizar la configuración, y parece que tanto Fedora como RedHat (y CentOS) quieren mantener la compatibilidad con ese comportamiento

Sin embargo en otras distribuciones, como las descendientes de Debian, primero utilizaron un parche de glibc que hace que la configuración de red de los procesos se actualice al cambiar la configuración de /etc/resolv.conf. Posteriormente Debian paso a utilizar eglibc que incluye esos parches como puede leerse en http://www.eglibc.org/archives/patches/msg00772.html y http://www.eglibc.org/archives/patches/msg00901.html.

Otras aplicaciones

Aparte de que algunas distribuciones corrijan el problema bien parcheando glibc o bien usando eglibc hay aplicaciones como Firefox o Chrome que intentan resolver ese problema observando /etc/resolv.conf y actualizando ellos mismos la configuración (por ejemplo en http://codereview.chromium.org/118061/). Incluso en Python han discutido si
http://www.linux-archive.org/fedora-development/231425-python-etc-resolv-conf-changes.html cambiar ese comportamiento, pero lo han dejado estar ya que es un comportamiento de libc.

So if execution time isn’t important, why Ruby then? Why not use Java, C or Erlang? I think there are two main reasons. The first is Ruby’s ability to easily access and transform data and Ruby’s ability to integrate with almost anything.

En el trabajo llevo varias semanas trabajando en una herramienta que ayuda al departamento comercial, se trata de una serie de proramas situados entre facturación y ventas que les ayuda a analizar costes y realizar una oferta comercial lo más ajustada. Para ello los distintos programas trabajan con varias decenas de listas de coste, cada uno con miles de precios, para intentar unificarlas y generar una lista de venta que tiene unas centenas de precios.

Siento ser tan vago en detalles, pero diré que se manipulan listas de códigos telefónicos, destinos y precios/costes. Para ello se necesitan transformar muchas filas almacenadas en bases de datos mediante árboles y algunos otros algoritmos más o menos complejos. Todo ello empecé a programarlo en Ruby, que es un lenguaje que permite un prototipado muy rápido, llevandome una grata sorpresa ya que los cálculos se hacían en segundos.

Al ver que los tiempoes eran muy manejables, cree una aplicación Rails, metí las librerías en lib/ y doté de un frontend vía web a la aplicación. Por ahora ha seguido creciendo, y en total el proceso que realizan mensualmente lleva unos 10 minutos. En un principio había pensado reescribir la aplicación, o las librerías, en C# para ganar velocidad, pero ¿realmente merece la pena el esfuerzo? Como mucho, podría ganar 10 minutos cada mes, suponiendo que el proceso pasara a ser instantáneo al reescribirse en un lenguaje compilado.

Más de una vez todos nosotros nos habremos encontrado con la situación de que se necesite alguna herramienta interna, y puesto que los requisitos de ese tipo de aplicaciones suele ser muy diferente, en la mayoría de ocasiones nos vale tener una aplicación con calidad de prototipo que podamos desarrollar rápidamente utilizando un lenguaje/plataforma que quizás no sea la ideal, pero es lo suficientemente rápido y nos permite agilizar la creación de nuestro pequeño monstruo.

Supongo que da para otro post hablar de esos pequeños monstruitos que van creciendo y acaban convirtiendose en algo que no es lo que estaba pensado ¡cuánto echaremos de menos no haberlo planteado y desarrollado de otra forma en esos momentos!

Este post es el último que publicaremos en esta plataforma, y estará online hasta el 30 de enero de 2009, fecha en la que apagaremos la luz, y Vive la ciudad | Madrid dejará de estar accesible.

Lo primero que pensé al ver esa nota fue que se producirá otro caso de enlace roto. Y se que es muy frecuente que haya sitios que cambien las direcciones o incluso que desaparezcan, a veces es inevitable, pero en otras muchas otras ocasiones creo que habría que intentar evitarlos. Creo que es lógico pensar que a medida que los contenidos generados dependan más de cómo puedan ser rentabilizados, más ocurrirá que habrá direcciones que dejan de funcionar y la Interweb se irá transformando en algo más temporal y efímero.

Si ya hace 10 años en un artículo de Nielsen sobre enlaces rotos se indicaba el grave problema que suponía ¿qué podemos esperar hoy en día? Cada vez que veo un elblockbusteractual-themovie.com pienso cuánto tiempo existirá esa dirección ¿merecerá la pena enlazarlo sabiendo que dentro de uno, dos, quizás tres años ese enlace dejará de funcionar?.

Proyectos como The Internet Archive y su Wayback Machine pueden ayudar a que algunos enlaces puedan rescatarse para poder comprender el contexto, pero no siempre es así y no estoy seguro de que sea la solución. Creo que sería mejor intentar mantener alojado el contenido, en la mayoría de casos no serían necesarios muchos recursos si se planea un poco, y hay muchas posibilidades para solucionar los problemas que se producen si se reestructura la web (¡mod_rewrite al rescate!), así que me parece bastante pecaminoso dejar que esas ocurran.

Una parte de la web 2.0 parece que eran las URL amigables, ¿quizás haya que esperar a la web 3.0 para que además sean permanente? ¿o sólo sirven para técnicas SEO y aumentar la rentabilidad? Espero que algún día podamos enlazar una dirección con la tranquilidad de que pasados los años seguirá allí, por ahora me temo que no es así.

Entiendo que no son serias al 100% pero creo que le dan más importancia de la que se debe a algo como una crisis financiera: efectivamente para todos esos que se quedan en paro sin recursos la cosa es una putada, pero lo sería aunque resultara que estuvieramos en el mejor momento de la historia económica. Además, un momento como este nos hará ser más ingeniosos y no creo que sea bueno dejar de disfrutar y pasar un mal año por algo que no nos toca de pleno. Si las cosas se han complicado, pues habrá que hacer más cena con los amigos y jugar a juegos en vez de tanto restaurante y cine. A lo mejor hay que usar menos coche y comprar otras cosas, pero estoy seguro de que todos podemos intentar disfrutar de todo esto.

Y a los que realmente estén pasandolo mal ¡mucho ánimo! Y que tengan un feliz 2009.

• Lo primero que decidí, ya hace unos meses, es que el 2009 sería el año de La Torre Oscura. Mi objetivo será (re)leer la saga de Stephen King así como otros libros que rodean el universo de la búsqueda de Roland. En total supone una veintena aproximada de libros.
• Me gustaría aprender Haskell, ya que en programming.reddit.com es muy mencionado y creo que nunca viene mal tener algo de soltura en programación funcional (cosa que perdí desde mis años de facultad).
• En el aspecto ecónomico, en esta última mitad del 2008 he conseguido estabilizar la situación y la idea es conseguir algo de ahorro, aunque el siguiente propósito igual complica ese asunto.
• Automovilizarme. El año pasado me saqué el carné de conducir y ahora mismo no tenemos vehículo, estamos planteando qué hacer en ese aspecto y ya veremos cómo va todo.
• En el aspecto laboral supongo que a pesar de tener en mente unas apuestas personales lo mejor será declarar en público un virgencita, virgencita, que me quede como estoy :-).
• Seguir intentando y conseguirlo.
• Tendría que decir algo de mi sobrepeso y de el ejercicio, pero no quiero ponermelo como propósito porque no se si seré capaz y tendría que ser algo que se transformara en hábito.

Supongo que quizás tendría que hacer otro post con algunas predicciones sobre el mundo tecnológico, sistemas, Internet y wireless, pero eso hay que reflexionarlo más, que no se me da tan bien.