La tendencia ya la conocemos: gente súper-chachi que hace cosas súper-molonas y que se deja la vida en ello. Parece que es un modelo popular y que nos hace imaginar momentos gloriosos porque, ¡oh sorpresa!, casi siempre terminan bien.

Sin embargo, cuando hablamos de programas (y de sistemas informáticos en general) lo que esperamos para que todo vaya bien es un comportamiento aburrido: siempre igual, predecible, que no falle y que no haya que dejarse la vida para conseguir nuestros objetivos. Eso sí, esperamos que sean muy emocionantes y nos llenen la vida de ilusiones (vale, muchas veces tampoco, que al final todo es trabajo, resolver problemas y marcharnos a casa tranquilos).

Por eso me gustó leer I’m a boring programmer (and proud of it) donde habla justamente de estas cosas.

El autor prefiere el silencio y el orden:

Instead, like a librarian I enjoy quiet and order. When code is well organized, things are easy to find and less likely to break, avoiding a bunch of noise and heartache.

Le gusta analizar problemas, probar distintas perspectivas y compartir sus descubrimientos con otros:

Like a scientist I enjoy analyzing problems, trying different angles to solve them, and then sharing my findings. I want to understand how things work, and I want others to benefit from that understanding

También tiene su parte artística, utilizando la cratividad y aceptando la imperfección.

Like an artist I need to occasionally think outside the box, tap my creativity, and be able to see in abstracts. I want to embrace imperfection.

Finalmente, como un carpintero, le gusta construir cosas:

And like a carpenter, I really enjoy building things. Sometimes that means following a specific plan, and other times you just work with what you’ve got.

Todas estas características son interesantes y valiosas pero nos alejan del modelo ‘ninja’ o ‘estrella del rock’ que parece tan popular y llamativo.

Bien por él.

Si escuchamos/leemos las tendencias modernas el C estaría olvidado en algún rincón y ya nunca nadie le prestaría atención más. Sin embargo, sigue teniendo su hueco en el corazoncito de mucha gente e incluso en los topes: Interactive: The Top Programming Languages 2017 así que, poca broma.

En todo caso, a mi me pudo la parte más sentimental (algunas líneas de C tiramos en su momento y, pocas veces, alguna vez nos toca mantenerlas, actualizarlas y volver a mirarlas). Por eso recomiendo echarle un ojo a Some Books on C, algunos actuales (y disponibles para descargar) y otros que son clásicos.

Como casi siempre, traemos un informe con un poco de retraso. Lamentablemente (porque siguen apareciendo casos) eso no hace que pierdan actualidad. Por ejemplo, podíamos leer estos días la llamada a 465000 pacientes con marcapasos para una actualización del software de sus dispositivos 465,000 Patients Need Software Updates for Their Hackable Pacemakers, FDA Says. No es la primera vez que hablamos de marcapasos, ni de actualizaciones obligatorias de software, aunque creo que no iban juntos en las otras ocasiones.

El informe fue el resultado de un encuentro patrocinado por IEEE Cybersecurity Initiative and the National Science Foundation y Carl Landwehr de la George Washington University y Tom Haigh of Adventium Labs (ret.) fueron los organizadores.

Posteriormente elaboraron el informe [PDF] Building Code for Medical Device Software Security que es bastante básico pero puede servir como llamada de atención para mucha gente, iniciación para algunas personas interesadas y, definitivamente, como recordatorio para las personas con más experiencia.

El ‘cross site scripting’ es un fallo frecuente en desarrollo web que consiste en permitir a los usuarios inyectar código ejecutable (típicamente javascript pero también otros) en páginas que pueden ver y utilizar otros usuarios. De esta forma los atacantes pueden robar información, saltarse algunos sistemas de control de acceso…

En Secure Coding 101: 4 Common Mistakes Developers Make When Fixing Cross-Site Scripting nos recuerdan cuatro errores frecuentes:

• Utilizar listas negras. Por largas y completas que sean siempre será posible que algún atacante encuentre una forma de saltárselas. En seguridad informática siempre que sea posible hay que concentrarse en permitir lo que está bien, y no en prohibir lo que está mal.
• Aplicar filtros en lugar de ‘escapar’ la salida. Es muy difícil filtrar correctamente todos los caracteres necesarios en una aplicación normal, es mucho mejor aplicar códigos que evitan que determinados caracteres sean interpretados como caracteres de control (comillas, metacaracteres, …).
• ‘Escapar’ los caracteres de forma inconsistente. Cuando utilizamos esta técnica, hay que hacerlo siempre y en todas las partes de nuestro programa. No sólo para evitar algún problema que ya hemos encontrado (o nos han encontrado).
• ‘Escapar’ los caracteres que no son. A pesar de que es una solución recomendada, tampoco es trivial de realizar. Por ejemplo, ¿qué sucedería si tus cadenas de texto que han sido tratadas de manera individual son concatenadas después?

Tengo mis dudas sobre el tema que traigo hoy aquí: porque soy culpable (cuando necesito hacer algo mínimamente complejo busco a ver si alguien ha hecho algo parecido y lo publicó para reutilizarlo). También porque me parece una buena práctica que favorece la economía, robustez…

Sin embargo en NPM & left-pad: Have We Forgotten How To Program? expone algunas quejas que pueden ser relevantes.

Dice que parece que el objetivo de la comunidad alrededor de NPM fuera escribir el mínimo código utilizando bibliotecas de otros para conseguir sus objetivos:

It feels to me as if the entire job of an NPM-participating developer is writing the smallest amount of code possible to string existing library calls together in order to create something new that functions uniquely for their personal or business need.

Sin embargo, no hay ninguna garantía de que esas componentes estén bien (y lo vayan a estar en el futuro, si hay evoluciones de los sistemas):

There’s absolutely no guarantee that what someone else has written is correct, or even works well.

De hecho, esta es una de las grandes prevenciones que se suelen contar en seguridad: no sólo tienes que estar seguro de que tu código es seguro, sino también el que utilices de terceros.

El último argumento que señalé es el de que, según el autor, juntar llamadas a APIs no se puede considerar programar y que puede convertirse en hacer cosas demasiado complejas:

Finally, stringing APIs together and calling it programming doesn’t make it programming. It’s some crazy form of dependency hacking that involves the cloud, over-engineering things, and complexity far beyond what’s actually needed to create great applications.

Me parecen argumentos interesantes, pero que hay que manejar con cuidado: ni hayque volverse locos juntando piezas y creando auténticos ‘Frankensteins’; ni tampoco hay que programar todo desde cero, gastando tiempo en desarrollar cosas que podríamos aprovechar para cubrir lo que es específico a nuestras necesidades.