miércoles, 5 de noviembre de 2008

Reflexiones sobre el trabajo: la metáfora de la autopista y la metáfora del barco.

Soy del tipo de desarrolladores que siempre trabajará en una empresa (nunca digas nunca jamás). Ése es el contexto que me gusta y en el que me siento cómodo: sistemas medianos más que grandes (pero no pequeños), trabajo en equipo, y ciertos temas que me serían una pesada carga ya resueltos: infraestructura, organización, insumos, administración, ventas, contacto con el cliente, esas cosas.

Sin embargo, he aprendido a ser crítico, muy crítico de las relaciones laborales. Entre compañeros de equipo, de trabajo, con dueños, jefes y subordinados, proveedores y clientes, y sus respectivos empleados. Todas. Por supuesto no siempre en voz alta, que tampoco es cuestión de andar metiendo cuchara en todo.

Crítico en el sentido de pensar en las idiosincracias, las falencias, los riesgos y los beneficios de esas relaciones. De poner todo el tiempo personas, situaciones y sentimientos al respecto en la balanza, verificando constantemente si me conviene o no, si quiero o estoy dispuesto a otra cosa, y analizando lo mismo en las personas que me rodean.

Creo haber encontrado una sola y sólo una norma absoluta, cuya aplicación es beneficiosa siempre, incluso cuando estamos en un entorno en el que no se la respeta: autocontrol y transparencia (¡son dos! ufa, una era mejor).

Autocontrol es, simplemente, no explotar, no actuar compulsivamente, no dejar de pensar, de medir, de valuar y evaluar absolutamente todo. Es llevar siempre cortas nuestras propias riendas... los que me conocen saben que por más que lo intento... bueh, uno hace lo que puede. Me ha servido siempre que he podido.

En la segunda me va mejor: transparencia. Si algo molesta, decirlo (vincularlo con la primera: no a cualquiera y de cualquier manera, evaluar), explicitarlo. Si algo deja de molestar, o se hace soportable, también. Dejar en claro cómo nos afectan las acciones de los demás, anunciar lo que vamos a hacer, hacernos previsibles.

Esta segunda puede desecharse si uno no tiene aires de ser una buena persona. Pero si uno tiene una conciencia y no le gusta que le moleste por las noches, es bueno seguirla. Contrariamente a lo que a veces se piensa, no nos pone en desventaja ante nadie.

Me gusta aplicar al trabajo la imagen de la autopista, que alguna vez desarrollé para el equipo de desarrollo: vamos todos por la misma autopista.

Algunos viajamos juntos, algunos queremos llegar al mismo destino, no necesariamente todos. Algunos van en ciclomotor y otros en un Mercedes. En un tramo acotado, todos deberíamos ir hacia la misma dirección.

Lo que es importante, como en la autopista, es no hacer maniobras bruscas o inesperadas. Si hay un choque algunos morirán, otros saldrán heridos y otros ilesos... pero independientemente de las consecuencias a nadie le conviene (como regla general).

Pero cada uno va como quiere y puede. Como en las autopistas, siempre hay un loco dando vueltas o jugando carreras, con mayor o menor suerte para él y para los demás.

Otra imagen o metáfora muy utilizada es la del barco: vamos todos en el mismo barco.

Es decir, somos un equipo, una tripulación. Nuestra suerte está estrechamente relacionada, viajamos con viento en popa, nos golpea la tormenta o nos hundimos todos juntos y por igual.

Cada uno se embarca y aporta sus conocimientos para llegar a destino (si es que lo hay) o navegar indefinidamente.

Es una linda imagen para tener en mente. Muy heroica en tiempos difíciles. Es una imagen que cada dueño o jefe gusta de ver en la cabeza de sus empleados. Es una imagen muy conveniente de tener en la cabeza de quien trabaja para nosotros.

Si todo va bien es una imagen que lo puede llevar a muy buen puerto, o que nos puede llevar a buen puerto. Siempre y cuando la tengan los demás, dándonos ventaja si no la tenemos nosotros.

Como en Matrix, hay situaciones que la rompen y nos devuelven a la realidad. Pero no a la cruda, dura, y horrible realidad. A la realidad, con todos sus blancos, negros y grises.

Esto se aplica en todos los niveles. Si lo vemos desde arriba, es ingenuo contar con que los empleados tienen un compromiso a toda prueba... de hecho lo es contar con que tienen algún compromiso. Ese compromiso hay que obtenerlo y mantenerlo negociando, dando y recibiendo, y el compromiso pasado no garantiza el futuro. De hecho ni siquiera la negociación lo garantiza. Cualquiera de las partes puede levantarse y abandonar la mesa sin previo aviso ni motivos ni explicaciones (una maniobra brusca, un volantazo), y es una situación a la que hay que arriesgarse o estar preparado.

Volviendo a la imagen del barco, es bueno que "hacia abajo" esté lo más difundida posible. Fomentándola (o creyendo en ella) el de arriba se lleva algunas piezas gratis...

...o una sorpresa. Es un certificado de defunción por adelantado apoyar demasiado un emprendimiento en una o varias personas, por más capaces que sean. Salvo que sea uno mismo, o personas con las que uno tiene un fuerte vínculo por fuera de lo laboral o profesional.

Visto desde abajo esa idea de "todos juntos remando para adelante" puede llevar a cumplir los objetivos grupales olvidando (o en contra de) los propios sólo para encontrarse de un día para el otro chapoteando entre las olas pensando en ese salvavidas que tan generosamente (o no, lo mismo da) ofrecimos en trueque (por un par de billetes que ahora flotan a nuestro alrededor, para más detalles).

Dependiendo de lo fuerte de la tormenta, en ese barco todos somos lastre, incluido el barco mismo.

Y sin ser tan drásticos (tal vez me entusiasmé un poco), puede llevar a negociar a menos o a no poner límite a lo negociable.

No es malo pensar: si me gano la lotería y me voy a recorrer el mundo ahora, ya mismo (digo, para desvincular estas preguntas de la idea de conflicto): ¿me iría conforme con lo que yo aporté en relación a lo que me pagaron? ¿si estuviera del otro lado del mostrador, también? La respuesta debería ser "sí", todo el tiempo, siempre. Está en cada uno responder esas preguntas y mantener la balanza nivelada, nadie lo va a hacer por nosotros.

¿Conclusión? Manejen con cuidado, y si alguien les dice de subirse a un barco síganle la corriente, pero tengan cuidado de comenzar a creer que el barco realmente está ahí.

martes, 4 de noviembre de 2008

Religiones del mundo (Religions of the world).

No tiene nada que ve con nada de este blog, es simplemente demasiado gracioso como para no compartirlo. A no ofenderse que hay para todos, incluso para ateos:

Taoism: Shit Happens.
Hare Krishna: Shit Happens Rama Rama Ding Ding.
Hinduism: This Shit Happened Before.
Islam: If Shit Happens, Take A Hostage.
Zen: What Is The Sound Of Shit Happening?
Buddhism: When Shit Happens, Is It Really Shit?
Confucianism: Confucius Say, "Shit Happens."
7th Day Adventist: Shit Happens On Saturdays.
Protestanism: Shit Won't Happen If I Work Harder.
Catholicism: If Shit Happens, I Deserve It.
Jehovah's Witness: Knock, Knock, "Shit Happens."
Unitarian: What Is This Shit?
Mormon: Shit Happens Again & Again & Again.
Judaism: Why Does This Shit Always Happen To Us?
Rastafarianism: Let's Smoke This Shit.
Southern Baptist: Send Us Money And Shit Won't Happen.
CALVINISM: Shit happens because you don't work hard enough.
HEDONISM: There's nothing like a good shit happening.
MOONIES: Would You Like To Buy Some Shit?
STOICISM: This shit is good for me.
ZOROASTRIANISM: Shit only happens half the time.
CHRISTIAN SCIENCE: Shit is in your mind.
Environmentalism: You produce shit, so you have to eat it.
Socialism: Sorry, we are out of shit today.
Feminism: That's not funny!
Atheism: There is no shit.
Atheism: Can you believe this shit?

Lo ví en lol god - About Shit y lo busqué y copié de skepticfiles.

Codificación: datos de la aplicación como recursos XML embebidos (parte II).

Parte I: Resumen.

Parte II: La definción del archivo XML.

Parte III: Encapsulamiento.

Parte IV: Que funcione.

II. La definción del archivo XML.

Para empezar con algo realmente simple, supongamos la siguiente estructura de menú definida en XML:

<?xml version="1.0" encoding="utf-8" ?>
<menu id="inicio">
  <titulo>Mi ERP 0.0.1</titulo>
  <submenues>
    <menu id="compras">
      <titulo>Compras</titulo>
      <submenues>
        <menu id="compras_presupuestos">
          <titulo>Presupuestos</titulo>
        </menu>
        <menu id="compras_ordenes">
          <titulo>Ordenes</titulo>
        </menu>
        <menu id="compras_seguimiento">
          <titulo>Seguimiento</titulo>
        </menu>
      </submenues>
    </menu>
    <menu id="ventas">
      <titulo>Ventas</titulo>
      <submenues>
        <menu id="ventas_catalogo">
          <titulo>Catálogo</titulo>
        </menu>
        <menu id="ventas_pedidos">
          <titulo>Pedidos</titulo>
        </menu>        
      </submenues>
    </menu>    
  </submenues>
</menu>

Como verán, es una organización recursiva de elementos menu. Cada uno de ellos tiene un atributo id que lo identifica unívocamente, un elemento título que corresponde al texto a mostrar al usuario y un elemento submenues que contiene una lista de elementos menu, cada uno de ellos con las mismas características.

En el ejemplo estamos definiendo la siguiente estructura de menú:

Mi ERP 0.0.1
 Compras
  Presupuestos
  Ordenes
  Seguimiento
 Ventas
  Catálogo
  Pedidos

Es lo mínimo indispensable para sacar algo por pantalla. Así que lo primero que tenemos que hacer es agregar un nuevo archivo xml al proyecto y establecerlo como recurso embebido. Esto último le indica al compilador que debe incrustar el archivo xml en el ensamblado.

Ya estamos listos para escribir la definción (o mejor, copiar y pegar el ejemplo anterior) y hacer una pequeña prueba: colocamos un botón sobre el formulario del proyecto. El código para el botón será:

        private void button1_Click(object sender, EventArgs e)
        {
            string resourceName = "EjemploRecursosXMLEmbebido.Menu.xml";
            
            XmlDocument menuesXML = new XmlDocument();
            using (Stream s = this.GetType().Assembly.GetManifestResourceStream(resourceName))
            {
                menuesXML.Load(s);
            }

            XmlNodeList titulos = menuesXML.SelectNodes("descendant::titulo");
            foreach (XmlNode titulo in titulos)
                MessageBox.Show(titulo.InnerText);

        }

(Nota: hay que agregar los using a los namespaces System.IO y System.Xml para que compile.)

La idea es cargar el archivo en un objeto XmlDocument para poder acceder a los datos por código utilizando XPath, que es el lenguaje de consulta para XML. Como prueba presentamos un MessageBox para cada título de menú en el archivo.

Aquí ya tenemos un par de líneas para resaltar. Por un lado, noten el nombre que se le asigna al recurso embebido: [nombre del ensamblado].[nombre del archivo (con extensión)]. En nuestro caso: "EjemploRecursosXMLEmbebido.Menu.xml".

El archivo se encuentra incrustado como recurso en el ensamblado. Para recuperarlo tenemos que obtener una referencia al ensamblado que lo contiene (clase Assembly) y a través del método GetManifestResourceStream obtener un Stream. Todo es lo hace la instrucción

using (Stream s = this.GetType().Assembly.GetManifestResourceStream(resourceName))

que coloca la referencia al Stream en la variable s.

Luego pasamos esa referencia como parámetro al método Load de un objeto XmlDocument. En nuestro caso, la variable menuesXML contiene al documento, por lo que hacemos:

menuesXML.Load(s);

El resto del código obtiene todos los nodos "titulo" del documento y muestra el texto que contiene.

La magia se termina aquí (no era mucha). Investigando un poco de XPath ya se podría recorrer el documento e ir cargando los datos en, por ejemplo, un TreeView. Lo que haremos de aquí en más será brindarle estructura a la solución de manera de hacerla funcional (todo muy lindo, pero esto no hace nada) y más sólida, mantenible y reutilizable.

Parte I: Resumen.

Parte II: La definción del archivo XML.

Parte III: Encapsulamiento.

Parte IV: Que funcione.

lunes, 3 de noviembre de 2008

Codificación: datos de la aplicación como recursos XML embebidos (parte I).

Parte I: Resumen.

Parte II: La definción del archivo XML.

Parte III: Encapsulamiento.

Parte IV: Que funcione.

Hoy tengo ganas de meter las manos en el barro y jugar un poco. Esta es la primera entrega de un artículo en el quiero ejemplificar algunas técnicas de manejo de recursos en C# con Visual Studio que hemos ido perfeccionando en el trabajo y que nos han resultado de muchísima utilidad.

I. Resumen.

Utilizamos recursos cuando se trata de almacenar datos propios de la aplicación que no deben ser modificados durante la ejecución y que conviene tener en un repositorio propio más que hardcodeados por todo el código.

El ejemplo típico, el texto que corresponde a etiquetas y mensajes con la posibilidad de que se requieran varios juegos por idioma, tiene un tratamiento muy específico (ver Recursos en aplicaciones (MSDN)).

Pero aquí pretendo ejemplificar el tratamiento de recursos que a) no dependen del idioma en el que el usuario esté utilizando la aplicación y b) son más complejos que un diccionario de cadenas de texto.

Para desarrollar el código, utilizaré como ejemplo el menú de la aplicación: supongamos que tenemos una aplicación con una estructura de funcionalidades organizada en menúes y submenúes, y que no queremos que ésta sea configurable por el usuario ni que pueda ser modificada de manera alguna luego de la compilación y el pasaje a producción.

Con estas especificaciones podríamos crear un menú directamente sobre el formulario principal del sistema utilizando el diseñador. Sin embargo, esto es muy incómodo cuando la aplicación es grande, y difícil de modificar y mantener a futuro. Por otro lado, estaríamos mezclando conceptualmente la estructura de funcionalidades (propia del negocio) con la forma específica de presentarlo al usuario. Si un día en vez de un menú queremos presentarla en un Treeview, o de cualquier otra manera, estaremos en problemas.

Empezaremos con algo simple y "que funcione" y luego lo iremos refinando.

Parte I: Resumen.

Parte II: La definción del archivo XML.

Parte III: Encapsulamiento.

Parte IV: Que funcione.

domingo, 2 de noviembre de 2008

Responsabilidades en el desarrollo de software: Del error a la catástrofe.

Este post viene a cuento del intercambio iniciado en Iboisset's Ruminations, en los comentarios de la entrada Responsabilidad de Qué.

La frase que da el puntapié inicial es de diazjc, en Twitter:

En nuestro sector lo que veo es que el informático no sabe el coste real de sus fallos, de sus acciones, su responsabilidad.

Dos artículos me vinieron inmediatamente a la mente. Al primero lo había referenciado en Gestores vs. realidad. Es Cuando los ingenieros se ponen en la piel de los gestores, de Historias de la ciencia. Llegué a él a través de Engañemos a la realidad, artículo de Un Punto Azul Pálido que también viene al caso.

Se comenta el accidente del Challenger. Sin entrar en detalles aquí (el artículo es absolutamente recomendable), resumo lo que viene al caso:

[...]Los ingenieros de Morthon Thiokol volvieron a advertir a sus jefes y a los responsables de la NASA del Centro de Vuelo Espacial Marshall, quienes gestionaban las relaciones con el contratista, que las frías temperaturas de la Florida podían tener un efecto negativo sobre las juntas tóricas.[...]

[...]La presión desde arriba, las dudas sobre los datos y la insistencia en que pensara “como un gestor y no como un ingeniero” fueron suficientes para que Lund cambiara de parecer. Se sumó a los otros gestores de Morthon Thiokol y, pasando por alto la opinión de sus ingenieros, certificó la seguridad de los cohetes aceleradores para el lanzamiento.[...]

[...]Como ingeniero, me vais a permitir unas reflexiones. Estoy seguro que Bob Lund, el ingeniero al que presionaron “para que se pusiera en la piel de un gestor”, se sintió terriblemente responsable por ceder ante la presión. Sin embargo, sospecho que Mason, aquel ejecutivo que le presionó, se lavó las manos de cualquier responsabilidad, ya que él nunca tuvo que estampar su firma para garantizar la seguridad de los cohetes aceleradores y no era responsable de la seguridad de los mismos.[...]

El segundo es uno que referenciaba en La cadena del error. Es un artículo de TCAS Aviation Blog (a cuento de las repercusiones del accidente del avion de Spanair en Barajas) que había aparecido como referencia en Dirección de proyectos:

[...]Que un avión salga en hora es un milagro. ¿O no?

No es tanto un milagro si no un éxito del sistema, que funciona. Pero está claro que no siempre. Normalmente cuando alguno de esos elementos no funciona en el momento que le corresponde o de la manera que toca, se producen incidencias en la operación de mayor o menor calado, y que normalmente afectan tan sólo a la puntualidad o a la economía, nunca a la seguridad.

¿Pero qué pasa cuando son varios elementos los que fallan simultáneamente?

Ahí es donde entra el concepto de la cadena del error. Imaginemos que desde el primer “mal funcionamiento del sistema” hasta el último hay cinco eslabones, y el quinto significa un accidente. Es relativamente fácil que el primero aparezca, puede incluso que el segundo lo haga, es posible que aparezca un tercero, pero alguien, en algún momento (incluso sin llegar a saberlo) debería haber roto alguno de esos eslabones, impidiendo así que llegara el cuarto, y mucho menos el quinto. [...]

Creo que se entiende hacia dónde voy... volvamos al desarrollo de software.

En principio, diferenciemos claramente "error" o "fallo" de "catástrofe" o "desastre". Según la RAE:

  • Fallo: Falta, deficiencia o error.
  • Catástrofe: (1) Suceso infausto que altera gravemente el orden regular de las cosas. (5) Cambio brusco de estado de un sistema dinámico, provocado por una mínima alteración de uno de sus parámetros.

¿Cuál es el coste real de un fallo de un informático? ¿Cuál es su responsabilidad?

Un negocio es un sistema, diseñado por una o varias personas, con el objetivo de ganar dinero. Un sistema de software es uno de tantos subsistemas de un negocio. Puede ser más o menos importante, central o periférico (no es lo mismo la venta de pañales que una red social con publicidad), pero nunca deja de ser parte de ese sistema más grande, el negocio.

Ese subsistema de software es construído por muchas personas (necesariamente) que conforman, junto con otros elementos, un sistema de desarrollo de software. Ahí están "los informáticos". Muchas veces este sistema de desarrollo excede los límites de lo que llamamos "empresa": puede estar compuesto por personas del lado del "cliente" y del lado de "el proveedor del sistema".

El objetivo del subsistema de software está acotado por el del sistema "negocio" al que pertenece. Lo que quiero dejar en claro en este punto es que el objetivo del subsistema "software" no puede ser "ganar dinero", porque ése es el objetivo del sistema "negocio" que lo contiene.

En el lenguaje cotidiano, cuando hablamos de "desastre" o "catástrofe" informática estamos hablando de pérdida de dinero o de cualquier situación que pueda traducirse en tal. Si hay una pérdida de dinero, el sistema que está fallando es el "negocio", porque ganar dinero es su objetivo, y no lo está cumpliendo, o deja de cumplirlo por un período de tiempo determinado, o en vez de ganarlo lo está perdiendo.

Ahora, ¿quién o quiénes son los responsables del negocio? ¿"El informático"?

El origen de una catástrofe (léase: evento que implica pérdida de dinero, fallo del negocio) puede estar en el subsistema de software. Es como decir que el primer eslabón en la cadena del error (que mencionaba arriba, en el artículo sobre el accidente de Spanair) se encuentra en ese subsistema.

No puedo hablar de otros subsistemas (recursos humanos, gerencia, ventas, facturación...), pero si hay algo que conozco bien son las características generales de un subsistema de software.

Una de ellas es: este sistema, tarde o temprano, fallará (probablemente como cualquier otro, pero yo soy experto en éste, y no quiero pisar terreno desconocido).

Si un programador dice que su código no tiene errores miente o peca de soberbia, y se equivoca.

Si un administrador de base de datos manipula la base sin un resguardo, está pecando de soberbia (eventualmente se equivocará). Si lo están obligando o presionando a ello estamos en una situación como la que describíamos arriba, hablando del Challenger.

Lo mismo sucede cuando se administran redes, proyectos de desarrollo, o cualquier elemento informático.

Cuando un líder de proyecto presiona a los programadores para que escriban código sin errores, no hace más que mostrarle al mundo su absoluto desconocimiento del desarrollo.

Cuando un cliente o empresario se apoya únicamente en un sistema informático para hacer funcionar su negocio está pecando de soberbia, ceguera, optimismo, pensamiento mágico, mala administración, falta de previsión... muchas cosas. Pero bueno, es su negocio y es libre de llevarlo como le venga en gana.

Entonces, cuando un cliente o empresario se queja de que el software le ha hecho perder dinero, demuestra que no ha sabido o sido capaz de crear un sistema de negocio tolerante a un fallo en uno de sus subsistemas. Un subsistema con alta probabilidad de fallo, característica harto conocida por todo el mundo.

¿O ha sido engañado por alguien?

Volvamos a la frase:

"[...] no sabe el coste real de sus fallos [...]" : No, no lo sabemos. No lo sabemos porque somos parte de un sistema externo (de desarrollo de software) que crea un subsistema (de software) que es parte del sistema en el cual se puede hablar de "coste" (el negocio)... y a veces ni siquiera eso (si el sistema de software es de depósito, por ejemplo, habría que agregar un nivel más).

A ver, yo escribo una línea de código para un sistema que conozco bien en cuanto a su flujo de información (lo administrativo), pero del cual desconozco completamente sus números monetarios, su aporte al negocio (porque se me ocultan, y en todo caso no me interesan más que como curiosidad). ¿Cómo podría evaluar el coste de un fallo? ¿Si el software falla, puede mantenerse la operatoria "a mano"? ¿Cómo podría saber yo eso?

Sólo saben decir 'ya está arreglado, ya no falla': obviamente. Es lo único que podemos decir. Es la única información de la que, como informáticos, disponemos (cuando la tenemos, que no es siempre).

Ésta es la dura verdad, aunque podemos ser soberbios y pensar que realmente somos responsables por todo lo que ocurre en "el negocio".

Lo demás, es limar asperezas. Podemos asumir responsabilidad sobre un sistema que no controlamos para quedar bien con el cliente. Puedo no decirle al jefe del equipo que el problema no está aquí para quedar bien o para no enojarlo. Puedo no decir "¿dónde están los procedimientos alternativos?", arremangarme y corregir las cosas lo más rápidamente posible. Podemos tener conciencia de equipo y ayudar en todo lo posible.

Si éstas son las actitudes que el autor de la frase siente en falta, puede ser. La vida es más fácil cuando están presentes. Pero hay veces en las que es difícil ser comprensivo y ponerse la camiseta cuando un cliente, líder de proyecto o jefe de lo que sea descarga su ira hablándonos de números sin sentido, pidiendo explicaciones que no quiere escuchar, y exigiendo que hagamos lo imposible: no generar errores.

(Las imágenes en caricatura de este post fueron encontradas en El ciclo de la vida, en "El rincón de Basulto".)

Cómo ser insoportable (How to be annoying).

  • Toca la batería en todas las superficies disponibles.
  • Canta la canción de Batman una y otra vez sin parar.
  • Esconde los productos de uso diario en lugares inaccesibles.
  • Escribe el final de una novela en la primera página.
  • Ajusta las alarmas de los relojes a cualquier hora.
  • Aprende código morse y habla en público con tus amigos utilizando "Beeeep Bip Bip Beeeep Bip..."
  • Deja un disco de Nine Inch Nails en el estéro de tu abuela, con el volumen apropiadamente ajustado.
  • Prueba en público qué tan despacio puedes imitar a una rana.
  • Cambia de canal 5 minutos antes del final de cada programa.
  • Comienza todas tus oraciones con "ooh la la!".
  • Levanta a tus compañeros de cuarto con "Lou Reed's Metal Machine Music" todas las mañanas.
  • ESCRIBE SÓLO EN MAYÚSCULAS.
  • escribe sólo en minúsculas.
  • tampoco uses signos de puntuacion
  • Paga con monedas de a un centavo.
  • Cose campanas a toda tu ropa.
  • Repite todo lo que te dicen como una pregunta.
  • Repite constantemente: "¿Escuchaste eso?" "¿Qué?" "Nada, ya pasó".
  • Antes de comer, pasea por el restaurant preguntando a los demás su parecer sobre la comida.
  • Deja propinas en moneda Boliviana.
  • Exige que todos se refieran a tí como "Conquistador".
  • Acopla bien fuerte todas las piezas planas del Lego.
  • En el lavadero usa una máquina para cada media.
  • Usa una capa que diga "El magnífico".
  • Párate detrás de cualquiera que esté leyendo y haz "mmmmm.... ajá".
  • Termina la canción de las 99 botellas de cerveza... y empieza de nuevo.
  • Maneja con la señal de giro encendida.
  • Imagina que el mouse es un comunicador y hábla a través de él.
  • Intenta tocar William Tell golpeando los dedos en tu barbilla. Cuando estés cerca del final anuncia "no, me equivoqué" y empieza de nuevo.
  • Ponle "Perro" a tu perro.
  • Dile a los demás que existen sólo en tu imaginación.
  • Pregunta a los demás de qué sexo son.
  • Responde constantemente "eso es lo que tú piensas".
  • Lame el relleno de todas las Oreos y colócalas de vuelta en el paquete.
  • Habla con acento extranjero.
  • Interrumpe un largo chiste con "olvidé el remate, pero era muy bueno".
  • Sigue a alguien limpiando todo lo que toca.
  • Canta canciones pegadizas cerca de tus compañeros de trabajo.
  • Miente obstinadamente acerca de cosas obvias como el estado del tiempo.
  • Haz "beep beep" cuando una persona obesa retrocede.
  • Deja el árbol de navidad hasta septiembre.
  • Cambia tu apellido a Aaaaasmith para conseguir la gloria de ser el primero en el directorio telefónico. Dí que es un apellido hawaiano y obliga a los demás a pronunciar cada "a".
  • Apunta a los autos con un secador de pelo para ver si disminuyen la velocidad.
  • Mastica los lápices que pides prestado.
  • Inventa jerga sin sentido en las conversaciones para ver si la gente te sigue.
  • Usa un MONTÓN de perfume.
  • Escucha discos de 33 revoluciones a 45 indicando que la es necesario porque tienes un "poder de procesamiento superior".
  • Termina todas tus frases con "de acuerdo a la profesía".
  • Pide al mozo un asiento extra para tu amigo imaginario.
  • Haz preguntas misteriosas a tus compañeros de trabajo, mientras anotas en un block. Si te preguntan, murmura algo acerca de "perfiles psicológicos".
  • Repite incesantemente trabalenguas insoportables como "tres tristes tigres".
  • Quédate mirando la estática del televisor y jura que puedes ver una "imágen mágica".
  • Selecciona 50 veces la misma canción en la máquina de música de los bares.
  • Acumula estática y ve por víctimas.
  • Finaliza tus frases con una entonación neutra, produciendo silencios con la impresión de que dirás algo más en cualquier momento.
  • Nunca establezcas contacto visual.
  • Nunca rompas el contacto visual.
  • Anuncia el final de una conversación tapándote las orejas con las manos.
  • Construye tu propio tricorder y escanea a la gente anunciado los resultados.
  • Relata cada acción de una persona como si fuera un encuentro deportivo.
  • Dispara números al azar cuando alguien cuenta.
  • Corta elaborados "círculos misteriosos" en el césped de tu jardín.
  • Prepara citas para el 31 de septiembre.
  • Invita un montón de gente a fiestas ajenas.
  • Borra todas las líneas del archivo .newsrc de alguien menos alt.sex.fetish.hamster.duct-tape.
  • Abrocha papeles al medio de las páginas.
  • Invita a salir a 800 operadoras telefónicas.
  • Coloca en alquiler un video que sólo contenga advertencias antipiratería del FBI.
  • Abrocha detectores antirrobo a la espalda de la gente.
  • Al comprar comida en el auto especifica claramente que es "para llevar".
  • Compra hilo dental sabor a menta sólo para lamerlo.
  • Toca la bocina y saluda a desconocidos.
  • Vístete siempre completamente de naranja.
  • Usa los pantalones al revés.
  • Rechaza una mesa en el restaurant y quédate junto a la caja comiendo caramelos.
  • Compra conos naranjas y reordena el tránsito.
  • Escribe "X - Tesoro enterrado" en varios lugares del mapa de alguien.
  • Informa a todo el mundo de tu propia teoría conspirativa acerca del asesinato de Kennedy/OVNIS/OJ Simpson.
  • Enciende bengalas en una torta de cumpleaños.
  • En navidad, canta "Jingle Bells, Batman smells" hasta que te detengan.
  • Haz cabriolas mientras caminas siempre que sea posible.
  • Maneja por la mitad de la calle.
  • Átate a las paredes, indicando que no quieres caer en caso de "que venga el grande" (terremoto).
  • Poda los árboles con figuras sugerentes.
  • En una presentación, cada tanto mueve tu cabeza como la de un perico.
  • Canta siguiendo al intérprete en la ópera.
  • Corta el pasto con tijeras.
  • En un recital de poesía, pregunta el por qué de cada verso que no rima.
  • En un torneo de golf, haz "swing-batatatatatata-suhWING-bateador!"
  • Deja la impresora en modo itálico-comprimido-apaisado-cirílico.

El original, aquí. La traducción es mía.

sábado, 1 de noviembre de 2008

Recomendados: The Daily WTF.

El día en que algo del código que escribo aparezca en The Daily WTF será el que me jubile voy a amargarme mucho (lo de la jubilación me pareció una apuesta demasiado alta... todos tenemos nuestros días. No quisiera que una función escrita a los apurones en un mal día me obligue a cumplir esa promesa).

Gracias a la cantidad de seguidores que tiene, es una fuente inagotable de delirios de código, burradas, situaciones delirantes y demás, todas ellas concienzudamente documentadas.

Para muestra dos botones extraídos de One In 3.4*10^38:

1) Kill the children (un poco fuerte el nombre de la función ¿no?):

Public Sub KillTheChildren()
   Dim objIntegrationAccount As IntegrationAccount

   For Each objIntegrationAccount In mcolItems
      Set objIntegrationAccount = Nothing
   Next

   Set objIntegrationAccount = Nothing
End Sub

2) Este es buenísimo, no me puedo explicar cómo se llega a esto:

If blnContinue Then
   If CreateConnection Then
      If DeleteData Then
         If CreateLocations Then
            If SaveServiceProviders Then
               If LoadServiceProviders Then
                  If LoadCategoryNames Then
                     If LoadFiveServiceProviders Then
                        If CalculateAllActivations Then
                           If UpgradesCalcNoExchange Then
                              If UpgradesCalcExchangeReturns
                                 ' (25 more levels here)
                              End If
                           End If
                        End If
                     End If
                  End If
               End If
            End If
         End If
      End If
   End If
End If

En el trabajo surgió esta regla: si estás escribiendo de la mitad de la pantalla para la derecha (por el anidamiento) algo está mal.

¿Alguien conoce algún sitio parecido en español?