¿Es fácil de manterner el código de Firefox?

Ya hace mucho tiempo de aquellos tiempos en los que se hablaba de lo simple que era Firefox (Mozilla en aquel momento) frente a la complejidad del navegador de Microsoft (recuerden Software Complexity: Open Source vs Microsoft.

Por eso es interesante echarle un vistazo a How maintainable is the Firefox codebase? donde se mostraban varias medidas habituales. Se ve que no está mal del todo, aunque algunos módulos se estarían volviendo más y más complejos.

Sobre paralelismo y concurrencia

Mucha gente no diferencia entre concurrencia y paralelismo, aunque ténicamente tienen sus diferencias, que podrían empezar a divisarse en:

Concurrent = Two queues and one coffee machine.

Parallel = Two queues and two coffee machines.

Aunque, según el autor la cosa va más allá. Dice, hacia el final:

We’ve discussed differences between parallel, computational systems and
concurrent, event handling systems. Areas of differences include:

* Determinism: desirable vs impossible
* Sign of parallel safety: same results vs correct results
* Parallelism bugs: easy to pinpoint vs impossible to define
* Queues: implementation detail vs part of the interface
* Preemption: nearly useless vs nearly essential

Me gustó leerlo.

URLs y Ajax

Cuando lo lei (y lo guardé para comentarlo aquí, hace ya algún tiempo) me gustó leer Must-Know URL Hash Techniques for AJAX Applications. Algunos de los ejemplos han quedado obsoletos, pero el concepto sigue siendo interesante.

También nos sirve para darnos cuenta de por qué, a veces, parece que al ordenador le cuesta ‘mover’ las páginas de GMail, Twitter, Facebook, … En realidad son aplicaciones en javascript que corren en nuestro computador y que solicitan determinados servicios al sitio web en cuestión.

Decididamente, vale la pena su lectura.

Una introducción al cálculo del coste de algoritmos

Una de las diferencias entre alguien que resuelve problemas y un buen desarrollador está en si es capaz de analizar cómo de buena es la solución que propone o no. A veces nos mareamos (y mareamos a otros) haciendo micro-optimizaciones sin habernos parado a pensar dónde ni cómo es la forma más adecuada de hacerlo.

En A Gentle Introduction to Algorithm Complexity Analysis podemos leer las ideas básicas sobre el tema, que nos abrirían la puerta a empezar a pensar en un algoritmo como un todo y no como un conjunto de instrucciones más o menos afortunadas.

¿Qué puede gustarnos del lenguaje c?

En un día como hoy el título viene que ni pintado: What’s to love
about C?
.

Por lo demás, un recordatorio de algunas de las cosas que nos proporciona
este lenguaje, que a veces descartamos demasiado rápido:

- Access to the hardware
– Guaranteed simple flow
– Clear and unambiguous
– A macro preprocessor
– Conditional compilation
– Libraries and API
– Small to tiny binaries
– Speed

Personalmente tengo una relación de amor-odio con la programación y me da pereza escribir (o retocar) programas en c, pero tampoco es algo que dejaría de lado sin más.

Desarrollo ágil y algunos problemas que aparecen a veces

En casi todos los números de la revista CrosTalk (revista de ingeniería del software militar) hay algún artículo interesante: son temas actuales, tratados normalmente con una visión de alto nivel y desde el punto de vista de uno de los mayores (seguramente) desarrolladores y compradores de software.

El número de mayo/junio de este año está dedicado a temas de desarrollo con metodologías ágiles (Large scale agile) y me quedo con [PDF] Uncomfortable With Agile donde se critica la adopción de las metodologías ágiles en direcciones equivocadas (según el autor, uno de los autores del Agile Manifesto): seguimiento poco crítico, reglas repetidas sin pensar en el objetivo final, confundir el modelo con la realidad y otras de este estilo.

Raspberry Pi: ¿qué temperatura hace en mi casa?

Estaba dudando si este sería el lugar adecuado para poner estas cosas o si debería crear otra bitácora. Visto mi ritmo de trabajo (lento), creo que será más razonable ponerlo aquí e ir contando las cosas que haga, si es que tengo tiempo de hacerlas (y luego de explicarlas).

Vamos a hablar de un mini-proyecto que consiste en tener una Raspberry Pi conectada a la WiFi de casa y cómo controlarla desde el exterior (el trabajo, con un móvil, …) y aprovechar sus prestaciones.

Para ello, he estado preparando un pequeño montaje que tiene un sensor de temperatura, y además es capaz de hacer un par de cosas (pequeñas) más.

Para la parte del sensor seguí el tutorial que publicó Pablo Murillo en Tutorial Arduino # 0005 – Sensor de temperatura NTC:

En este proyecto vamos a aprender a implementar un sensor de temperatura a nuestros proyectos Arduino, en este proyecto simularemos cinco estados de aviso de exceso de temperatura, sobre los cuales los cuales podríamos conectar cualquier elemento que quisiéramos que actuara llegado dicho nivel, podríamos conectar circuitos de ventilación de manera que si no consiguieran mitigar el exceso de calor llegara un punto que desconectara el sistema que estemos monitorizando, en resumen, en cualquier lugar donde un control de exceso de temperatura sea necesario.

Como no tenemos un Arduino, sino que tenemos una Raspberry Pi, necesitamos algo que sirva para hablar con los sensores analógicos. En mi caso (por cercanía física y también por simpatía con el proyecto) lo que he utilizado es el Raspberry Pi to Arduino shields connection bridge de la gente de Cooking Hacks.
Con la biblioteca que proporcionan ellos, podemos utilizar las ideas (y los programas, casi tal cual) de los proyectos de Arduino en nuestra ‘raspi’ con bastante facilidad. Sirven los mismos esquemas de conexiones y todos los documentos disponibles para esta plataforma.

Una imagen del montaje:

.

Y un vídeo de la ‘cosa’ en acción.

Se pueden ver algunos elementos más (hay un sensor de luz que se ve a la derecha del de temperatura), pero básicamente allí está el proyecto propuesto por Pablo Murillo.

Aunque el tema de los LEDs es bastante llamativo (a mi me lo parece, siendo una persona más de programas que de cacharros) lo que más me atrae del cacharrito es que se trata de un ordenador completo.
Uno no se siente a gusto si no mete internet por enmedio y algo de interacción con el aparato.

Buscando un poco por ahí encontré el proyecto SleekXMPP que nos permitiría interactuar con nuestro ordenadorcito a través del protocolo XMPP. Este protocolo nos permite comunicarnos en tiempo real y ha sido utlizado, entre otras cosas, por algunos sistemas de mensajería instantánea (por ejemplo el GTalk de Google -aunque últimamente parece que podrían estar pensando en cambiar-, Jabber, …).

En los ejemplos del proyecto hay un ‘bot’ que repite las instrucciones que le envíamos y programé una modificación para poder preguntarle a la raspi sobre la temperatura de la habitación en la que se encontraba.

Podemos ver la interacción en este vídeo:

Pero el bot de ejemplo no está pensado para este tipo de comportamiento y necesitábamos alguna arquitectura que hiciera sencillo extender el proyecto, añadirle instrucciones e interactuar remotamente (¿la meta podría ser poder añadirle instrucciones por GTalk?) así que me puse a buscar.

El amigo Javier Candeira me sugirió probar phenny, que es un bot extensible, diseñado para recibir instrucciones remotamente y con solo una diferencia con mi proyecto inicial: está pensado para ser controlado desde una canal de IRC.

El proyecto se convierte (por ahora) en un bot de IRC que es capaz de proporcionarme información del entorno de la raspi que tengo en una estantería de mi casa.

Como primer paso, modifiqué el programa que había generado a partir del tutorial de Arduteka.
En lugar de encender más o menos luces, lo que quería era saber la temperatura así que lo que hace el programita es (además de encender las luces si se dan las condiciones adecuadas), escribir en la salida estándar el mensaje:

Temperatura:

seguido de la temperatura que se haya medido.
Para eso se toman medidas 5 veces con una separación de 0.5 segundos y después se calcula la media.

El código puede verse (y descargarse) en temperatura.cpp y se compila y ejecuta de la misma forma que en el tutorial antes referido.

Para invocar remotamente este programa entra en juego phenny.
Lo primero que hay que hacer es ejecutarlo, se generará un fichero de configuración (en ~/.phenny/default.py) que hay que editar para ponerle nuestro servidor de IRC favorito, canal y algunas cosillas más y ya lo tenemos listo para funcionar.
Por defecto viene ya con un buen montón de instrucciones que podemos probar.

Pero el proyecto sigue. Queremos añadir nuestras propias instrucciones y las elegidas han sido de momento tres:

  • .temp: devuelve la temperatura que mide en ese momento el sensor instalado.
  • .ip: devuelve la ip (interna) de la raspi, que se conecta a internet a través de un router WiFi hogareño normal y corriente.
  • .ls: devuelve un listado de ficheros del directorio actual donde se haya ejecutado phenny.

El código de esta parte puede verse (y descargarse) de: testing.py y copio aquí un trozo de código de la primera de esas tres acciones para que cada uno se haga idea de lo fácil (o difícil) que es prepararlo.

def temp(phenny, input):
   arg='sudo /home/pi/usr/src/pruebas/temperatura'
   p=subprocess.Popen(arg,shell=True,stdout=subprocess.PIPE)
   data = p.communicate()
   split_data = data[0].split()
   tempC = split_data[0]
   my_ip = 'La temperatura es %s' % tempC

   phenny.say(input.nick + '!' + ' ' + my_ip)
temp.priority = 'high'
temp.commands = ['temp']

También puede verse en Código para llamar al programa que nos dice la temperatura.

Como puede verse, invocamos al programa (lo he puesto con el path completo) lanzando un proceso con Popen.
Le pedimos el resultado, lo procesamos y creamos una cadena de caracteres my_ip que luego le pasamos al bot para que la escriba en el canal de IRC.

Nótese que phenny permite asignarle un nombre (o varios) a la instrucción (temp.commands = ['temp']) y también asignarle una prioridad, que hemos puesto en los tres casos como alta (‘high’).

Una vez hecho esto podemos volver a lanzar phenny (en realidad el bot puede cargar nuevas instrucciones de manera dinámica pero eso no importa ahora) y responderá a las instrucciones que ya ‘conocía’ y a estas tres que acabamos de añadir.

Podemos verlo en acción en:

Como decía arriba, el uso del canal de IRC ha sido un hito intermedio:

El objetivo ahora tiene varias líneas de avance:

  • Modificar phenny para que también acepte instrucciones desde un cliente
    de mensajería instantánea.
  • Añadir instrucciones a phenny (¿añadirle una webcam y poder ver una foto de la habitación desde nuestro teléfono móvil?, ¿descargar un documento cuya dirección le pasemos? ¿avisarnos si la temperatura alcanza determinados umbrales? …).
  • Añadir/utilizar capacidades de administración para que algunas instrucciones sólo puedan ejecutarse por personas autorizadas

Trataremos de seguir informando.
Si alguien ve mejoras a lo que ya hay publicado (las bondades del código existente son debidas a sus respectivos autores; los defectos me corresponden a mi) o necesita alguna aclaración no tiene más que decirlo.
También si alguien conoce otros proyectos que se puedan utilizar de forma similar o de los que obtener inspiración.

Añadir una instrucción a Python

Conocer como funciona un compilador es una buena idea para cualquiera que tenga que ver con la informática.
Este artículo no va de eso, pero da algunas pistas de las interioridades de un lenguaje que es bien interesante, Python: Python internals: adding a new statement to Python.

This article doesn’t attempt to suggest the addition of an until statement to Python. Although I think such a statement would make some code clearer, and this article displays how easy it is to add, I completely respect Python’s philosophy of minimalism. All I’m trying to do here, really, is gain some insight into the inner workings of Python.

Copiar y pegar código no siempre es malo

Un artículo sobre copia/pega de código que tenía por ahí guardado: [PDF] “Cloning considered harmful” considered harmful: patterns of cloning in software.

Típicamente, cuando se copia y pega el código en un sistema se considera una mala práctica. Sin embargo, los autores consideran que hay que analizarlo mejor y ver cuando puede tener sentido y cuando no.

This paper describes several patterns of cloning that we have observed in our case studies and discusses the advantages and disadvantages associated with using them. We also examine through a case study the frequencies of these clones in two medium-sized open source software systems, the Apache web server and the Gnumeric spreadsheet application. In this study, we found that as many as 71% of the clones could be considered to have a positive impact on the maintainability of the software system.

Por ejemplo, podría aportar estabilidad en zonas ya probadas y que
funcinonan, mientras se experimenta en otras partes más novedosas:

There is no doubt that code cloning is sometimes an indication of sloppy design and in such cases should be considered to be a kind of development “bad smell” (Fowler et al. 1999). However, we have found that there are many instances where this is simply not the case. For example, cloning may be used to introduce experimental optimizations to core subsystems without negatively affecting the stability of the main code. Thus, a variety of concerns such as stability, code ownership, and design clarity need to be considered before any refactoring is attempted; a manager should try to understand the reason behind the duplication before deciding what action (if any) to take.
This paper introduces eleven cloning patterns that we have uncovered during
case studies on large software systems,…

Interesante.

El código peor… el que hacen los gobiernos

En Study
Confirms The Government Produces The Buggiest Software
hablan del tema
del desarrollo de aplicaciones analizando un conjunto de aplicaciones:

In a talk at the Black Hat Europe security conference in Amsterdam later this week, security researcher and chief technology officer of bug-hunting firm Veracode Chris Wysopal plans to give a talk breaking down the company’s analysis of 9,910 software applications over the second half of 2010 and 2011, automatically scanning them for errors that a hacker can be use to compromise a website or a user’s PC. And one result of that analysis is that government software developers are allowing significantly more hackable security flaws to find their way into their code than their private industry counterparts.

E inmediatamente:

According to Veracode’s analysis across industry and government, fully
eight out of ten apps failed to fully live up to the company’s security
criteria. But breaking down the results between U.S. government and private
sector software, the government programs, 80% of which were built for
federal agencies rather than state or local, came out worse. Measuring its
collection of apps against the standards of the Open Web Application
Security Project or OWASP, Veracode found that only 16% of government web
applications were secure, compared with 24% of finance industry software
and 28% of commercial software. And using criteria of the security-focused
education group SANS to gauge offline applications, the study found that
18% of government apps passed, compared with 28% of finance industry apps
and 34% of commercial software.

Como casi siempre, el diablo está en los incentivos (quién hace qué, por qué y cuáles son sus motivaciones):

Those incentives have led to government bugs persisting even as the rest of the industry starts to clean up its act, says Veracode’s Wysopal. While SQL injection and cross-site scripting vulnerabilities have have dropped off in private industry over the last two years, they’ve remained statistically flat for governments.

A mi me recuerda los estudios aquellos sober las políticas de claves en los sitios web que comentamos en Contraseñas, usabilidad y uso: los sitios web gubernamentales eran los que tenían políticas más restrictivas, sin mucha evidencia de que eso mejorara la seguridad.