Es interesante para todo aquel que se dedique o quiera dedicarse al desarrollo de software el libro “Foundations Of Programming“, de Karl Seguin. Propone varias buenas prácticas, así como patrones y tips para el día a día del nerdo programador.

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.

Antes de ayer estuvimos con Dari (y gracias a que nuestro PL nos dejó ausentarnos un rato) en el Google DevFest 2009. Tras un rico desayuno con medialunas, fuimos a ver la Keynote, a cargo de Patrick Chanezon, encargado de que a todos se nos caiga la baba con HTML5,   geolocalización, y todas las magias que después se vieron a lo largo del día (estas son las cosas que él mostró).

A continuación, pasé por el “Geo Web Track”, en donde mostraron una introducción a las 10+ APIs que tiene google para mapas/geolocalización y compañìa (la que más me llamó la atención fue la API para flash, ya que la desconocía). También, contaron algunos truquitos sobre KML y la forma de hacer que Google indexe el contenido de los mapas. Sobre el final, presentaron una demo de Bondicom (el sistema de predicción de arribo de colectivos) con una interfaz reducida de Ojos del Cielo (el backend de monitoreo de Bondicom).

Antes de irme, le tocó el turno al “Development Tools Track”, en donde Christian Schalk habló sobre el Google App Engine, una solución completa para el hosteo de aplicaciones (Python o Java), dejando en sus manos toda la infraestructura. Sobre el final, hubo una demo sobre cómo construir un robot para Google Wave, y hostearlo ahí (que, de hecho, es la única forma de hacerlo).

Lo bueno: se ve que hubo mucha organización (y plata) puesta en este evento. Trajeron conferencistas copados que le pusieron mucha onda, mostrando cosas realmente interesantes.

Lo malo: Sentí que si me quedaba un rato más, venía un hombre de rojo a hacerme firmar el contrato por mi alma. Fue DEMASIADO marketinero para mi gusto (¿nadie de los que fué notó el logo de la gran G girando todo el tiempo al costado de los escenarios?). La movida de Google viene por el lado de hacer que todos programemos con sus APIs, en su infraestructura, para sus plataformas, en su sistema operativo y hasta en su lenguaje (monopolio, anyone?). Los productos que vimos hasta ahora son buenos (algunos excelentes), pero la idea de lanzar cosas verdes y aprovechar a la comunidad para hacerlas madurar y seguir quedándose con el nombre no me parece muy buena.

En esta otra reseña, pueden encontrar links a las presentaciones y a las demos mostradas

Otra cosa que no se nombra ahí, pero que puede ser útil es el comando subst, que mapea un directorio contra una unidad de disco (cuando hay rutas absolutas que no se pueden evitar, por ejemplo).

Para los extremistas, que no quieren usar los comandos de Windows que “se portan como los de Unix”, también existe Cygwin, que permite usar directamente muchos comandos con un look&feel bien Linux.

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

Péguenle una miradita, programen o no en Ruby, ya que tiran varias cosas interesantes, más allá de la librería utilizada.