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.
En Dreams and Nightmares algunas ideas sobre un taller donde se analizaba la tensión permanente entre hacer cosas que tengan valor y la necesidad de invertir en crear una buena infraestructura que les de soporte. El debate entre la técnica y la economía.
Se propone incluir en la planificación escenarios terroríficos (la pesadilla) que pueden suceder si algo va mal y no se ha invertido suficiente en que la base sea sólida: se estima el coste, el esfuerzo necesario en caso de que algo vaya mal…
El problema de algunos requisitos no funcionales de este tipo es que no encajan siempre bien con las historias de usuario y por lo tanto son complicados de integrar en el proceso. Pero estos requisitos han de tenerse en cuenta y no perderse de vista en las sucesivas iteraciones.
Interesante.
Como ya llevamos años con el tema es agradable ver como, de vez en cuando, más gente lo dice. En este caso lo vi en Los desarrolladores de software necesitan saber hacer software seguro.
Yo estoy bastante convencido de eso, pero como dice el autor no todo el mundo lo tiene claro y en los equipos ágiles es fundamental:
La conclusión a la que se llegó es que los desarrolladores de software necesitan formación en seguridad para que puedan diseñar y desarrollar software seguro, al menos, en cuanto a unos requisitos mínimos se refiere. Y es que estamos hablando de calidad del software.
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.
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.
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:
Siempre podemos establecer expectativas más bajas para alcanzar los hitos.
— fernand0 (@fernand0) March 28, 2013
El objetivo ahora tiene varias líneas de avance:
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.
Un sistema informático moderno es una pesadilla desde el punto de vista de dónde están realmente nuestros datos (cachés, swaps, páginas, memorias, discos …). Por eso conviene recordarlo: de cara a que nuestros datos sensibles estén el menor tiempo posible por ahí en claro; y también por tratar de evitar mediante las facilidades que tengamos disponibles que esos datos terminen escritos donde no conventa. De eso hablaban en
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.
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.
John Melton comenzó a principios de este año su serie sobre seguridad para Java. Aunque los ejemplos son con este lenguaje, lo cierto es que casi siempre la prsentación es suficientemente general como para aprender/recordar algunas cosas aunque Java no sea nuestro lenguaje favorito. Comenzó con Year Of Security for Java – Introduction y lleva hasta ahora más de cuarenta entradas, todas muy interesantes.
Por poner una pega, no hay un índice. La búsqueda por Java Security en el blog debería ayudar.
Considero su lectura muy recomendable para cualquier persona interesada en estos temas, como recordatorio, temas en los que no habíamos pensado tanto …
Actualización: la serie ha terminado y pueden verse todos los enlaces en
Year Of Security for Java – Conclusion and Links y también descargar un pdf con todo, tal y como se anuncia en Year of Security for Java – PDF
Mbpfernand0's Blog 