La siguiente lista puede proveer algunas novedades y obviedades al respecto:

• Usar contraseñas dificiles de adivinar y fáciles de recordar
• Usar letras (mayúsculas/minúsculas), números y símbolos
• Chequear la fuerza de la contraseña con alguna métrica
• No usar la misma contraseña para varias cosas
• No decirle tus contraseñas a nadie
• Una contraseña larga ayuda a evitar ataques de fuerza bruta

Sin embargo, y siguiendo a Neri, me animo a plantearles mi propio sistema/algoritmo “original” (desconozco si lo es… pero una vez se me ocurrió y anda perfecto. Edit: Como bien dice el propio Neri en su comentario, el algoritmo es MUY similar al suyo, sólo que agrega la parte de los reemplazos manuales) para generación de contraseñas. Este sistema se denomina “Once upon a time” y hace hincapié en los primeros puntos de la lista anterior:

• Elegir alguna frase (o frases) de una canción o libro que tenga al menos ocho palabras
• Tomar la primer letra de cada palabra de la frase elegida
• Reemplazar las letras que les recuerden a números o símbolos por esos números o símbolos (esta es la parte más dificil y creativa)
• Pasar algunas de las letras a mayúsculas (puede ser una por medio, o las primeras o las últimas)
• Si la contraseña es débil, agregar algún símbolo extra al final

Como verán, el algoritmo deja bastante del lado del usuario, pero creo que es un buen comienzo para que empiecen. A continuación un ejemplo:

Voy a usar los primeros dos versos de “Stairway to Heaven”, de Led Zeppelin:

There’s a lady who’s sure
All that glitters is gold

Las primeras letras serían talwsatgig (fuerza según The Password Meter: very weak).

A continuación, reemplazo la primer “a” por un 1 (hay UNA dama), puedo reemplazar “all” por un 8 (hey.. es mi algoritmo.. para mi 8 es un “infinito” parado.. así que me representa el “todo”). Por último “glitter” (brilla/reluce) lo reemplazo por un * (¡como una estrella!). Hasta ahora queda:

t1lws8t*ig (fuerza según The Password Meter: strong).

Agregando un par de mayúsculas, nos queda:

t1LwS8t*Ig (fuerza según The Password Meter: very strong).

Como verán, la contraseña resultante no es fácil de adivinar, y tampoco de recordar, PERO si uno recuerda la frase y el algoritmo, a la tercera vez de usarla, ya queda grabada en la mente perfectamente

Les dejo una LT que me gustó mucho, ya que deja varios mensajes importantes (y es graciosa):

Además, rescaté cosas interesantes como:

• Bluepill: Un monitor de procesos con una API un poco más linda que la de God
• Teambox: Una herramienta para manejar la comunicación entre miembros de un proyecto
• El sistema 6×50, 1×25 de Bebanjo (6 porciones de 50 minutos de trabajo ininterrumpido por dia, y 1 de 25 minutos para un proyecto propio)
• Básica, pero que siempre vale la pena recordar, la charla sobre cómo lidiar con código legacy

Pueden encontrar todos los videos en AgoraNews

Como comentario final, voy a putear contra LocosXRails, evento al que asistí el año pasado, por no haber subido nunca los videos de las charlas, como prometieron… (algunos, igual, se pueden conseguir)

Dia > png > Latex = borroso

Hace un tiempo, en el blog de Aurelianito, encontré la forma de exportar desde Dia a una macro TGF, y de ahí incluirlo en el documento (exportar como “LaTeX PGF macros”). El resultado:

Dia > PGF macro > Latex = nítido

La magia se debe al paquete tikz:

\usepackage{tikz}

Y después, simplemente:

\input{archivo_exportado_de_dia.tex}

Reef Knot, by katiedee

En general, me gusta tomar principios o ideas de una disciplina e intentar aplicarlos en otra, y ver si aplican o no. Creo que algo que puede ser transpolado de esa manera y superar la prueba, es mucho más fuerte de lo que uno podría suponer.

En los últimos días, en particular, estuve pensando en el armado de nudos (sí, los de soga) y cómo relacionar sus principios con la vida en general, y el desarrollo de software en particular. Los tres principios básicos de un buen nudo son:

1. Que sea fácil de armar
2. Que cumpla su cometido
3. Que sea fácil de desarmar

Fácil de Armar

K.I.S.S (el principio, no la banda) es algo que debería ser conocido para todos. Hay que mantener las cosas simples y fáciles de hacer. La navaja de Occam pasa rasante por acá, recordándonos que de varias soluciones posibles, la más simple es la que debería ser elegida.

Si algo es complicado de hacer, también lo será de analizar, entender, modificar, etc.

Cumplimiento de Cometido

Un nudo puede servir para muchas cosas: prolongar una soga, acortarla (sin necesidad de cortarla), unir una soga a algo, amarrar dos objetos, servir como elemento decorativo, etc. Sea cual sea el cometido del nudo, uno que sea bueno tiene que cumplirlo.

De la misma manera, cualquier software, para cumplir con este principio, debe satisfacer su cometido.

Fácil de Desarmar

Por más que haya cumplido su cometido, si un nudo no puede ser desarmado cuando se lo quiera desarmar, no es bueno. Debe ser posible deshacerlo en caso de voler a necesitar la cuerda usada, o si el propósito que cumplía ya no es necesario. Transladar este principo al software no es tan sencillo, pero alcanza con pensar el “desarmar” como “destripar”, y así poder analizar el funcionamiento interno de algo. También, se puede ver como “desacoplar”, a fin de reutilizar partes, o reemplazar módulos de ser necesario.

De esta forma, tenemos una nueva forma de ayudarnos a corroborar si lo que estamos haciendo tiene buena pinta o no.

En las cercanías de terminar mis estudios fiubenses, y observando un proyecto de Datos actual de cerca, me inspiré para hacer las siguientes imágenes, ideales para usar como emoticones al comunicarse con comparñeros de grupo, como avatar en los mensajeros instantáneos o, incluso, como medidor de status en la wiki/web del proyecto (habrá que encontrar algo que suene parecido a “Anda Todo” y a “Casi Estamos” o algo así)

Ambas imágenes liberadas bajo dominio público, al igual que la idea

Todo el evento parece muy copado, pero las charlas que más me interesan, a priori, son:

• “Rails i18N”, por Fabio Akita
• “Tools in the Toolshed: Understanding the Ruby Environment”, por Evan Phoenix
• “Debugging Rails applications”, por Emilio Tagua

Cuando termine, les cuento

El resultado es bueno (dada la simplicidad de la tarea a realizar, otro resultado no sería aceptable). El mismo está lanzado bajo dominio público, y puede bajarse desde acá.

Últimamente me choco bastante con esta realidad: La mayor parte de lo que uno necesita a la hora de desarrollar cosas nuevas, ya está hecho. Hacer las cosas de 0 es algo que cada vez se hace menos. Sin embargo, uno siempre quiere meter su toque personal, y termina haciendo un mashup de cosas sacadas de todos lados. ¿Por qué? Porque si bien ya hay cosas hechas, no siempre encajan al 100% en lo que estamos haciendo. Además, muchas veces hay cosas hechas, pero que no están bien documentadas… así que es más esfuerzo entender lo que hicieron los demás que hacerlo de nuevo uno mismo.

“No reinventes la rueda” es algo que escucho continuamente (e incluso yo también lo digo)… Pero creo que usamos mal la frase. La rueda ya fue inventada. Pero al principio era de piedra, después de madera, de madera reforzada con metales (cada vez más livianos), de metales y caucho, etc. La rueda es la misma, pero fue perfeccionada. Incluso a partir de la rueda descubrimos la polea, los engranajes, las orugas para vehículos que transitan sonas inhóspitas.

El progreso tiene dos madres: la adversidad y la competencia.

REINVENTEMOS LA RUEDA. Juguemos a hacer ruedas que rueden. La reutilización de lo ya hecho a veces no es él en sí mismo, sino el concepto que representa.