Cuidado con los secretos

Hay gente que cree que es suficiente con ofuscar algo para que otros no puedan acceder a la información (de hecho, creen que sus métodos de ofuscación son realmente métodos de cifrado). En Nuclear sub secrets revealed by mod ‘schoolboy error’ nos cuentan un caso de estos:

But in what was described as “a schoolboy ­error” the technique used by MoD staff to censor the ­document was easy to reverse. The bunglers turned the text background black – making the words unreadable – but crucially left them in place. That meant anyone wanting to read the censored sections just had to copy the text.

Lo que todo programador debería saber sobre aritmética de coma flotante

No conocía What Every Programmer Should Know About Floating-Point Arithmetic. Lo descubrí en Lo que todo programdor debería saber sobre…. Recomienda algunos otros ‘Lo que todo programador debería saber sobre …’

Errores frecuentes al utilizar MySQL

Aunque creo que es mejor aprender principios generales positivos, en lugar de lo que no hay que hacer (porque casi nunca seremos capaces de saber todo lo que es malo), seguiemos con listas de cosas que deberíamos evitar.

En 10 errores MySQL de programadores de PHP hay una traducción de Top 10 MySQL Mistakes Made By PHP Developers que incide en ese tema y da pistas a los desarrolladores de PHP que quieran hacer las cosas mejor.

12 errores de programación que deberíamos evitar

En 12 programming mistakes to avoid. Cuidado con tomarse nada muy a pecho, porque casi todas tienen su contra-parte: se trata de un compromiso entre hacer algo demasiado, o demasiado poco.

  1. Hacerlo rápido y con poco cuidado
  2. Decicarse en exceso a los detalles
  3. No simplificar el control
  4. Delegar demasiado a las herramientas (frameworks)
  5. Confiar en el cliente
  6. No confiar suficiente en el cliente
  7. Confiar demasiado en soluciones mágicas
  8. Reinventar la rueda
  9. Dar demasiado control al usuario
  10. Controlar excesivamente la experiencia de usuario
  11. Cerrar el código
  12. Suponer que la apertura lo cura todo

Esto es el resumen pero lo mejor es leer la explicación asociada a estos puntos en el artículo.

Algunas cosas falsas que los programadores creen sobre los nombres

Programar es decidir y suponer cosas: una parte importante de la disciplina es tener claro que es lo que se supone y que esas decisiones sean lo más conscientes posibles. Muchos problemas de seguridad (y también de robustez y simple funcionamiento) tienen que ver con el ‘es que yo creía …’, ‘¿quién imaginaba que alguien podría hacer eso?’ y afirmaciones similares.

En Falsehoods Programmers Believe About Names Patrick McKenzie escribe 40 suposiciones que vemos frecuentemente sobre los nombres de personas que no tienen por qué ser ciertas.

Dos ejemplos:

# My system will never have to deal with names from China.

# People have names.

Es muy difícil imaginarse todos esos casos, pero hay que tener cuidado (sobre todo dependiendo del contexto en el que nos movamos) de que nuestra aplicación no termine teniendo (o causando) problemas por suponer demasiado.

En forma humorística, ya lo decían en Exploits of a Mom.

Corrección de errores con algoritmos genéticos

Lo vi en un tuit de JJ Merelo y enlaza a un artículo curioso: A Genetic Programming Approach to Automated Software Repair (pdf). Proponen utilizar algoritmos genéticos para resolver fallos en los programas: esencialmente se trata de ajustar los parámetros del algoritmo para que proporcione valores malos con programas modificados que no pasan los tests y que proporcionan valores buenos cuando se cumplen las restricciones del problema.
Curioso.

Ya habíamos hablado en vidas anteriores de Algoritmos evolutivos y el gcc (se usaban para optimizar la selección de parámetros que se le pasan al compilador). También de Algoritmos genéticos, spam y expresiones regulares y de Algoritmos genéticos: historias de éxito interesantes.