¿Cuál es tu segundo lenguaje de programación?

Después de la eterna discusión sobre qué lenguaje es mejor o peor y si dejamos de lado por un momento el hecho de que, probablemente, deberíamos elegir el lenguaje en función del proyecto y sus objetivos, es cierto que cada uno (y una) tenemos algún lenguaje en nuestro corazoncito.

Clase de programación En What’s Your Secondary Language? se concentran en la siguiente pregunta: una vez que tienes claro cuál es tu lenguaje favorito, ¿cuál sería el siguiente?

The important question is not “Which programming language is best?” but “What’s your secondary language?” The language you reach for to solve problems, prove that ideas work before implementing them for real, and to do interesting things with files and data.

En mi caso diría que mi lenguaje favorito es, siguiendo la línea expresada arriba, el que toca en cada momento: de vez en cuando C, pero también Perl (que no elegiría voluntariamente jamás, creo), u otros…

Pero cuando quiero hacer pruebas, jugar y desarrollar pequeños proyectos, elijo Python. Y últimamente, que hago más de esto que desarrollos más serios tengo que decir que casi se ha convertido también en el primero. Tampoco le hago ascos a un programita en la shell (shellscript) para un apaño rápido.

Eso sí, también tengo claro que no dejaría de hacer un proyecto porque tuviera que usar un lenguaje que me gusta menos, o aprender uno nuevo.

El correo como sustituto de las contraseñas

Una pequeña provocación en How to Fix Authentication: Email as a Password Manager que, en realidad, se parece bastante a lo que ya mucha gente usa cuando accede a sitios poco habituales. En estos casos, en muchas ocasiones, le damos al botón de reiniciar la contraseña, que nos llega al correo.

Candados

We want to propose dead simple and secure approach to authentication. Your email account is a password manager out-of-box. The idea is to remove passwords from classic authentication scheme and stick to email only: every time user wants to log in / sign up your app sends a link with one time password to their email

Según el autor tiene muchas ventajas que incluyen la simplicidad, no necesitar productos adicionales, gratuidad, …

No se si puede ser válido para cualquier producto pero, desde luego, es cierto que podría resolvernos algunos problemas.

Seguridad informática y niños

Siempre que hablamos de seguridad en informática tenemos que recordar que algunas herramientas las terminan usando niños y que, con ellos, todavía debemos ser más cuidadosos con la gestión de datos y otros detalles.

Robot de juguete Una opción es la táctica del avestruz: prohíbimos y nos quedamos tranquilos. Suponiendo que nos creamos que esa prohibición tiene algún efecto. Mi opinión siempre ha sido que deberíamos facilitar que los niños utilicen las aplicaciones (Siempre que tenga sentido, claro) y que sea fácil para sus padres poder controlar qué sucede con ese uso.

En todo caso, en Tech Toys And The Child Protection In The Age Of The IoT nos recuerda cómo se les ha ido la cabeza a algunos fabricantes y ponen características potencialmente peligrosas en los juguetes sin prestar mucha más atención. Y los padres las compran.

Let’s face it. Even the most powerful governments in the world are far from immune to hackers. Tell me now that you still believe that some cheap products like the internet-connected dolls and baby cams are better protected? Think again.

Hablan de la ‘internet of toys’, esto es la internet de los juguetes y los riesgos que se están asumiendo por puras estrategias que sólo se preocupan de la parte comercial.

No decimos que no haya que conectar los juguetes, o darles características que se consideran interesantes (si no, el juguete elegido será otro y ya está) pero con los niños hay que tener todavía más cuidado.

Moreover, for that alone, when dealing with children in an IoT context, their security and privacy must be your priority. In a tech toys context, the child protection must be paramount to you. You, the parent. You, the IoT maker. Right from day one.

Continúa dando algunos consejos intersantes: cifrar, compartimentalizar, proteger, no almacenar datos, actualizar, …

¡Atención!

Pistas sobre la semilla para generar números aleatorios

Dados Hacía tiempo que no traíamos el tema de la aleatoriedad. en Random number generator seed mistakes hablan justamente de los errores más frecuentes en este tema, aunque no desde el punto de vista de la seguridad. Más bien les preocupan los aspectos de simulación.

Una primera solución (no muy buena desde el punto de vista de la seguridad, por su predecibilidad y/o posibilidad de control externo) es usar como semilla la hora. Desde luego, no es una buena idea pedir la semilla al usuario (sin, al menos, darle unas instrucciones razonables).

Pero la cosa se complica cuando trabajamos con hilos en paralelo:

A more subtle problem I’ve seen with random number generator seeding is spawning multiple processes that each generate random numbers. In a well-intentioned attempt to give each process a unique seed, the developers ended up virtually assuring that many of the processes would have exactly the same seed.

No es una buena idea utilizar un generador aleatorio para generar las semillas, fundamentalmente porque no sería raro que se produzcan repeticiones:

Suppose you seed each process with an unsigned 16-bit integer. That means there are 65,536 possible seeds. Now suppose you launch 1,000 processes. With 65 times as many possible seeds as processes, surely every process should get its own seed, right? Not at all.

Casi siempre, lo que parece simple no lo es tanto.