A veces un “if” es más barato

En una interesante discusión en el grupo de Facebook de la Comunidad .NET Tijuana surgió el tema de las microoptimizaciones, en particular el uso de evaluación en corto circuito y el ahorro de ifs “que son muy costosos al CPU”.

Mi último argumento:

A lo que iba es que el short-circuit, si bien te puede ahorrar ifs, también puede darte sorpresas como brincarse validaciones de seguridad. Ha ocurrido en otros lenguajes. Yo prefiero un if explicito, que en realidad no es nada caro al CPU, a menos que no diseñes bien tus condiciones.

Entonces el autor original hace un planteamiento: ¿Cuál de los dos siguientes programas es más rápido?

Sigue leyendo

Monitor

Monitor state diagram

Monitor state diagram

Monitor is a purely-Bash script that lets us leave the PC monitoring the result of an instruction. Unlike watch, Monitor is not about observing the output of the instruction, but to detect the moment when the instruction fails and stops failing and execute instructions whenever this happens.

Monitor was written to keep an eye on randomly failing services. The problem will sometimes last for a short while and it is not easy to take a sample of the system just right when the problem is occurring.

Besides, this kind of situations share some characteristics:

  • It is desired to know when did the failure occur and when did it raise back to know what section of the logs to browse for useful information.
  • It is desired to take action when a new failure occurs. These actions can be alert sending or snapshot taking.
  • It is desidred to be tolerant to temporary situations. For example, a simple lost ping doesn’t imply an actual lose of service.

Although this type of monitoring can be easily solved by using while under Bash, it could easily become complex and it is not fun to debug it each time the need comes up. Besides, it is also possible to make mistakes in the while logic and not notice until the next instance of the failure happens and we didn’t get the expected system snapshot.

With Monitor, the logic is already established and tested. It’s just a matter of indicate the commands that we want to monitor and the actions to execute on state change.

The code is available in Github: https://github.com/alvarezp/monitor

Example

In a hypothetical problem we lose communication with our own host and we don’t know why. We suspect that a running process is inserting rules in iptables that result in communication blockage.

Let’s user monitor.bash to keep an eye on the result of a ping to localhost and to take an iptables configuration snapshot on failure.

# monitor.bash --rest-time 1 --on-down 'iptables-save' 'ping localhost -c 1 -w 1 >/dev/null 2>&1'
       INIT 2015-11-05 15:21:58 PDT lun
         UP 2015-11-05 15:21:58 PDT lun
     ---- the weird process applies iptables -A INPUT -i lo -p icmp -j DROP ----
FALLINGDOWN 2015-11-05 15:22:13 PDT lun
# Generated by iptables-save v1.4.21 on Mon May 11 15:22:17 2015
*filter
:INPUT ACCEPT [74:70608]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [67:5781]
-A INPUT -i lo -p icmp -j DROP
COMMIT
# Completed on Mon May 11 15:22:17 2015
       DOWN 2015-11-05 15:22:17 PDT lun
     ---- the weird process applies iptables -F INPUT ----
RAISINGBACK 2015-11-05 15:22:32 PDT lun
         UP 2015-11-05 15:22:36 PDT lun

It gives the impression that iptables-save is run after getting to FALLINGDOWN, but in fact it executes just before entering DOWN.

Now we have timestamps to look for more information in our logs and some evidence to delve into the problem and its diagnostic.

Monitor

Diagrama de estados de Monitor

Diagrama de estados de Monitor

Monitor es un script escrito en puro Bash que permite dejar a la PC monitoreando el resultado de una instrucción. A diferencia de watch, no se trata de estar vigilando la salida de la instrucción, sino de detectar el momento en que ocurre la falla y ejecutar instrucciones cuando el servicio vigilado se cae o se levanta.

Monitor fue escrito para vigilar servicios con fallas de naturaleza aleatoria. En ocasiones el problema dura poco y no es fácil tomar una muestra del sistema justo cuando el problema ocurre.

Además, este tipo de situaciones tiene algunas características:

  • Se quiere saber cuándo se cayó y cuándo se volvió a levantar el servicio para saber en qué sección de las bitácoras buscar.
  • Se quiere tomar acción cuando se detecta otra caída. Estas acciones pueden ser toma de diagnósticos o envío de alertas.
  • Suele necesitarse ser tolerante a oscilaciones pasajeras; por ejemplo, un ping perdido no implica una caída de un equipo.

Si bien este tipo de vigilancia se resuelve fácilmente con un while de Bash, éste puede volverse rápidamente complejo y no es divertido estar depurándolo cada que uno se ve en la necesidad. Además, es posible cometer errores al programar la lógica del while y no darnos cuenta hasta cuando el problema original ya volvió a ocurrir y no obtuvimos la monitorización esperada.

Con Monitor, la lógica está establecida y comprobada. Sólo basta indicar qué instrucción queremos monitorizar.

El código está disponible en Github: https://github.com/alvarezp/monitor

Ejemplo

En un hipotético problema perdemos comunicación con nuestro propio host y no sabemos por qué. Sospechamos que un proceso corriendo en nuestra máquina está insertando reglas de iptables que resultan en el bloqueo de esta comunicación.

Utilicemos monitor.bash para vigilar el resultado de un ping a localhost y que en caso de caída confirmada se tome una muestra de iptables.

# monitor.bash --rest-time 1 --on-down 'iptables-save' 'ping localhost -c 1 -w 1 >/dev/null 2>&1'
       INIT 2015-11-05 15:21:58 PDT lun
         UP 2015-11-05 15:21:58 PDT lun
     ---- el proceso misterioso aplica iptables -A INPUT -i lo -p icmp -j DROP ----
FALLINGDOWN 2015-11-05 15:22:13 PDT lun
# Generated by iptables-save v1.4.21 on Mon May 11 15:22:17 2015
*filter
:INPUT ACCEPT [74:70608]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [67:5781]
-A INPUT -i lo -p icmp -j DROP
COMMIT
# Completed on Mon May 11 15:22:17 2015
       DOWN 2015-11-05 15:22:17 PDT lun
     ---- el proceso misterioso aplica iptables -F INPUT ----
RAISINGBACK 2015-11-05 15:22:32 PDT lun
         UP 2015-11-05 15:22:36 PDT lun

Da la impresión que iptables-save se ejecuta después de quedar en FALLINGDOWN, pero en realidad se ejecuta justo al entrar en DOWN.

Ya tenemos fechas y horas para buscar en bitácoras y algo de evidencia para profundizar en el diagnóstico.

LibreOffice Styles Tutorial

LibreOffice Styles Tutorial (click to download)

LibreOffice Styles Tutorial

I wrote a small-and-quick tutorial for using LibreOffice Styles. It is intended to quickly let you understand (and hopefully grasp) the concepts behind the use of Styles without having to go through an entire manual.

It briefly covers and exemplifies the notion of Paragraph and Character Styles, Direct Formatting, automatic table of contents generation and chapter rearrangement through the Navigator.

Styles can do much more than explained in the tutorial, but it should get you started saving a significant amount of time.

Download it by clicking on the image or from here: /files/libreoffice-styles.odt

Se crea una zona horaria para Quintana Roo

El 31 de enero de 2015 se publicó en el DOF un decreto que crea una nueva zona horaria en México para Quintana Roo (UTC-0500).

Alguien ya mandó el cambio al Time Zone Database. El 30 de enero de 2015 se liberó la versión 2015a del paquete tzdata de Unix, con la actualización para la zona America/Cancun.

Según el CENAM hay un vacío legal en el decreto: siendo legalmente estrictos Quintana Roo no contaría con horario de verano, pero seguramente esta no es la intención. Es posible que más adelante haya otra actualización a las zonas horarias y por lo tanto a la Time Zone Database.