Cuando se empieza como un desarrollador, hay una enorme cantidad de cosas que captar. En primer lugar está el propio lenguaje; después, todas las peculiaridades del marco de trabajo; y después de eso (o tal vez antes) hay que mezclar el desarrollo con las interfaces de usuario. Y es en ese momento donde hay que decidir dónde almacenar todos los datos que se van a usar. Después de tantas cosas, quizás sea a la base de datos a la que menos importancia se le da, de ahí que surjan las malas prácticas.

En el mundo impuro en el que vivimos se producen situaciones inesperadas que escapan a nuestro control. Es por ello que los programas necesitan un mecanismo mediante el cual poder controlar dichos casos excepcionales, al más común de esos mecanismos se le llama Exception handling. Sin embargo, el uso de excepciones tiene consecuencias en la calidad de nuestro código haciéndolo más frágil. ¿Podemos hacer algo al respecto?

Investigadores de Google Project Zero han hecho pública una vulnerabilidad en macOS, después de que Apple no haya liberado un parche en los 90 días previos a la publicación. Descubierta por el investigador Jann Horn y demostrada por Ian Beer, la vulnerabilidad reside en la forma que el kernel de macOS, XNU, permite a un atacante manipular el sistema de ficheros sin informar al sistema operativo.

La mayoría de los lenguajes de programación están diseñadas para desarrolladores profesionales con conocimiento de algoritmos y estructuras de datos. SQL es diferente. SQL lo utilizan analistas, científicos de datos, gerentes de producto, diseñadores y muchos más. Estos profesionales tienen acceso a bases de datos, pero no siempre tienen la intuición y la comprensión para escribir consultas eficientes. En un esfuerzo por hacer que mi equipo escriba mejor SQL, he recompilado fallos comunes y oportunidades de optimización perdidas.