David Capello's Blog

The Dumpster Diving Era of Tech

2024-12-21T00:00:00+00:00

This year is ending and I was thinking of writing something thoughtful, something about how the world is going down the drain, with some kind of wishful conclusion. But I’m not in the mood.

The only thing I can think of is how technology is entering in a kind of dumpster diving era. Where everything is considered trash, your creations, your own pictures, your face, your retina, or even your medical record, and they can be taken without any cost, to bring the most outrageous tampered reality.

There is no shame in anonymity. But now big tech companies have no anonymity, and no mortification either. It looks like being a public shameless figure (or company) is the standard. At least real dumpster diving has the dignity of being done for survival. For these companies: we are the trash.

Data-Driven Mistakes

2023-06-10T00:00:00+00:00

Several years ago, I remember reading about data-driven design. How big companies (Google mainly?) were using data-driven approaches to design and evolve their UI. In those years I thought about that like a great idea to know how the UI was being used. But later, in the last few years, I completely dismissed that approach.

It’s a little crazy to drive your design-decision from just some stats:

— How many clicks did this menu item receive?
— Only a couple from hundreds of users.
— Hmm, we might remove the item, or send it to a deeper menu level.

— This is the most used action from the whole program.
— Hmm, I think we should make its button bigger.
— It’s already half the screen…
— It should be as big as the screen, probably the only button in the whole program.

These are totally exaggerated characterizations, but they are a good example about what you can achieve doing data-driven design: You are going to make the problems of your UI just worse.

The data/stats you can receive from the UI are already defined by the initial design of the UI itself. You are going to receive just data about the current design, it’ll tell you absolutely nothing about how to evolve the UI, or what is failing, or not being used because it’s not accessible enough.

The only data you should be listening to are your users. The direct feedback you are getting from them: emails, messages, issues, error reports, etc. That is the most important data that matters in your design decisions.

Ask your users.

Floppy Disk

2023-03-12T00:00:00+00:00

En la película The Matrix existen esos discos de entrenamiento que le ofrecen a uno todo el know-how sobre una determinada área del conocimiento humano:

Un poco de eso ya ocurre hoy en día con YouTube: uno graba un video, lo sube, para que luego una “inteligencia” artificial lo utilice para aprender —por ejemplo— a cocinar un bife, y así nos reemplace.

Siempre “el futuro” se vendió como una imagen donde tendríamos que dedicarnos menos tiempo al trabajo y más tiempo al ocio, a leer, al arte, a crear y hacer cosas que nos conmuevan. Pero parece ser que el futuro llegó como un balde de agua fría —o caliente—: Ahora tampoco será necesario crear, porque los robots ya pueden escribir y dibujar. Gracias a toda esa hermosa nube de datos fácilmente crawleable —amigable al robo masivo de datos— que es Internet.

¿Adónde va el ser humano si no tiene qué hacer? ¿Qué pasa si el “arte” ahora lo “genera” un ordenador? ¿Cómo podremos distinguir lo original de lo sintético? ¿Quién va a pagar todo lo afanado? ¿Cuáles serán los incentivos para crear algo en el futuro? ¿Acaso no estamos trabajando cada vez más y creando cada vez menos? ¿Dónde está ese futuro liberador? Cuestiones sin responder.

Silicon Valley, como sinónimo del progreso tecnológico desenfrenado —más que cómo locación geográfica— es como una patada en los huevos que primero golpea y luego pide permiso. Ya habrá tiempo de preguntar, hacer juicios, y ver quién hizo el bien y quién hizo el mal. Pero el dolor ya lo empezamos a sentir. ¿Creemos que el humano va a quedar cruzado de brazos? ¿Sin hacer nada? ¿Que los corazones de millones de artistas van a dejar de latir, sin ningún deseo? ¿Dónde se alojará toda esta información? ¿Serán servidores infinitos? ¿O será en un simple floppy disk? El futuro, aunque virtual, también se ve bastante frágil 💾

Inteligencia Artificial II

2022-12-05T00:00:00+00:00

Se sabe que Cleopatra (excusen este ejemplo traído de la historia romana) clavaba agujas de oro en el pecho de sus esclavas y que disfrutaba enormemente los gritos y contorsiones de las víctimas. Me dirán que eso ocurría en una época bárbara; que nuestro siglo también es bárbaro, ya que todavía se clavan alfileres; que el hombre, aunque tenga ahora una comprensión más clara de las cosas, no se acostumbra todavía a seguir las reglas de la razón y de la ciencia. Pero ustedes están convencidos de que el hombre se acostumbrará con el correr del tiempo, cuando el sentido común y la ciencia terminen de reeducar completamente la naturaleza humana y la orienten por un camino normal. Creen que con el tiempo el hombre dejará de errar y se verá, entonces, en la imposibilidad de oponerse a sus intereses normales.

Pero hay más. Entonces (según ustedes) la ciencia hará saber al hombre (aunque esto sea un lujo superfluo) que no tuvo nunca voluntad ni caprichos y que es, en definitiva, como una tecla de piano o un pedal de órgano. De modo que actúa, no de acuerdo a su voluntad, sino según las leyes de la naturaleza. Bastará, entonces, descubrir las leyes para que no se pueda considerar al hombre responsable de sus actos, y entonces la vida será fácil. Con estas leyes, todas las acciones de los hombres se podrán calcular tan matemáticamente como los logaritmos, hasta la cienmilésima, y se harán con ellas libros importantes, como nuestros diccionarios enciclopédicos, en los que todo estará exactamente calculado y previsto. Ya no habrá aventuras… y ni siquiera acciones.

Entonces (creen ustedes) se establecerán novedosas relaciones económicas, que se fijarán con precisión matemática, de modo que los problemas desaparecerán enseguida, por la sencilla razón de que se habrán descubierto las soluciones. Entonces se construirá un hermoso palacio de cristal. Entonces veremos el Pájaro de Fuego. Entonces… No se puede garantizar, digo yo, que eso no sea terriblemente aburrido (¿qué se podrá hacer, si todo está ya calculado y fijado?). Como contrapartida, todos serán sabios. Evidentemente, el aburrimiento es un mal consejero: es el aburrimiento lo que mueve a clavar agujas de oro en los pechos ajenos… Pero aun esto no tiene demasiada importancia. Lo grave, lo terrible es, digo, que el hombre se sienta feliz de tener al alcance de la mano agujas de oro. El hombre es estúpido por naturaleza, totalmente estúpido. Y es más ingrato que estúpido: es difícil encontrar otro ser más ingrato que él. Por eso no sería extraño verlo erguirse de pronto en medio de esa felicidad, un caballero sin elegancia, de rostro “retrógrado” y burlón, y que dijera: “¡Bueno, señores! ¿Cuándo vamos a destruir de un solo puntapié toda esta insoportable felicidad, aunque solo sea para enviar todos los logaritmos al demonio y poder vivir de nuevo según nuestra estúpida fantasía?.” Y hay algo peor, y es que muy rápidamente ese personaje encontraría discípulos. El hombre es así. Y la causa de todo es algo ínfimo que, a primera vista, se podría pasar por alto. Esa causa es que el hombre, sea el que sea, aspira siempre a obrar según su voluntad y no según las prescripciones de la razón y del interés. Ahora bien, yo creo que la voluntad de uno puede, y a veces incluso debe, oponerse a sus intereses. Mi voluntad; mi libre albedrío; mis caprichos, por insensatos que sean; mi imaginación sobreexcitada hasta la demencia… Esto es lo que no se tiene en cuenta, este es el precioso interés que ignoran todas esas clasificaciones de ustedes y que hace estallar todos los sistemas, todas las teorías.

¿De dónde sacan nuestros sabios que el hombre necesita una voluntad normal y virtuosa? ¿Por qué suponen que el hombre quiere ser razonable? El hombre sólo quiere una voluntad independiente, sin importar los precios y el resultado. Pero el diablo sabe lo que cuesta ese deseo…

— Memorias del Subsuelo, de Fiódor Dostoyevski

Papá

2022-04-05T00:00:00+00:00

El 14 de noviembre del 2020 falleció mi padre y hoy cumpliría años. Teníamos una relación de amistad, aunque a la distancia por vivir en ciudades distintas. Desde su partida que quiero escribir algo, pero siento que cualquier cosa que diga queda chica para el desborde de palabras que él representaba. Diré poco, y guardo el resto para mí.

Era un delirante, dentro de ciertos límites, pero sólo él conocía esos límites. Uno nunca sabía qué esperar, ni en lo bueno ni en lo malo. Verborrágico, y no por nada se dedicaba a las ventas. Una vez lo ví dormirse mientras hablaba. Podría haber sido periodista deportivo –le gustaban los autos y las carreras, los veleros y las regatas– o conductor de radio –tenía un gusto especial por la buena música. También le gustaba el arte, desde el Renacimiento a las tiras de cómics.

Un poco incomprendido. Con mucho para compartir y poco para escuchar. Enviaba mensajes todos los días, o cada dos o tres días –o dos o tres por día–. A cualquier horario. Nunca le apasionaron las computadoras, ni a mí los autos, y aún así podíamos hablar de todo un poco –o de todo un mucho–. Siempre abierto a nuevas ideas y con buen humor a pesar de cualquier circunstancia.

Lamentaré toda la vida no haber estado con él en sus últimos días, la forma en que –no– nos despedimos, no poder saludarlo ni ayudarlo. No poder compartir más tiempo juntos. Como él solía decir –con mejores palabras de las que puedo recordar– el tiempo es lo más valioso para regalarle a las personas, cada vez que esto ocurra disfrutalo.

Tierra Surreal

2020-10-15T00:00:00+00:00

Allá a lo lejos va el berenjeno triste enterándose de que su representante miente. Será la hierba transatlántica que hace sombra a los chamanes de tu pueblo. O los biseles que no dejan erguirme. Me has generado una lumbalgia cerebral, que deja mirar sólo cerca de la más antigüa cicatriz.

Ahora estoy en mi invernadero marciano, dejando sala al nuevo tratado. La paz intergaláctica es un hecho sólo por tiempos. Las bombas de relojería se aburren en el espacio. Solté mi paloma a tu planeta, volvió mutante con un aceituno rancio. Sé que todavía no están listos para tanta fertilidad. No den a luz a un Cronos matricida.

Consejos para Diseñar Clases (en realidad Software)

2020-10-12T00:00:00+00:00

Gracias a una pregunta que me hicieron hoy sobre algunos consejos para diseñar clases, escribo este pequeño artículo sobre mi enfoque personal hacia el desarrollo de software, y sobre las clases en particular:

Crear un programa no se trata de crear clases, sino sólo de resolver un problema.
Un programa son instrucciones de código que manejan/transforman datos, y esto es siempre así, sin excepción.

Los datos son memoria en el disco o la memoria RAM, y pueden “estructurarse” con un simple un struct. Ejemplo:

struct Jugador {
  char nombre[256];   //< Los primeros 256 bytes representan el nombre del jugador
  uint32_t puntaje;   //< Luego un entero de 4 bytes representan el puntaje del jugador
};

El código que maneja los datos puede estar ubicado en cualquier lugar, pero existe una relación directa entre ese código y los datos que manipulan.
Por lo tanto siempre vamos a preferir tener el código cercanos a esos datos que manipula (en el mismo .cpp, .h, o .java, .csharp, etc.). Ejemplo:
```
struct Jugador { ... };

Jugador* crear_jugador(const char* nombre);
void destruir_jugador(Jugador* jugador);
```
Si comenzamos a manipular los datos en cualquier lugar de nuestro programa comenzaremos a tener problemas a futuro para cualquier modificación que queramos hacer. Mal ejemplo:
```
int main() {
  Jugador* j = crear_jugador();
  memcpy(j->nombre, "David\0", 6);   //< Código que accede a la estructura interna del Jugador
  destruir_jugador(j);
}
```
Luego al querer cambiar la estructura de nuestros datos:
```
struct Jugador {
  string nombre;     //< Ahora el nombre es un std::string
  uint32_t puntaje;
};
```
Nuestro código que llamaba a memcpy() deja de funcionar.

Así es como podemos crear funciones para manipular esos datos:

void cambiar_nombre_del_jugador(Jugador* j, const char* nuevo_nombre);
void sumar_puntos_al_jugador(Jugador* j, uint32_t mas_puntos);

Pero en vez de repetir la palabra _del_jugador, al_jugador, etc. podríamos colocar las funciones que modifican los datos lo más cerca de los datos posible, dentro del struct mismo:
```
struct Jugador {
  string nombre;
  uint32_t puntaje;

  void cambiar_nombre(const char* nuevo_nombre);
  void sumar_puntos(uint32_t mas_puntos);
};
```

Y finalmente podríamos “ocultar” el acceso directo a los campos nombre y puntaje desde fuera del struct:

class Jugador {    //< Esto podría ser un "struct" y no habría diferencia
public:
  void cambiar_nombre(const char* nuevo_nombre);
  void sumar_puntos(uint32_t mas_puntos);

private:
  string nombre;
  uint32_t puntaje;
};

En esta forma tenemos funciones que modifican datos estructurados y que ocultan los detalles de esa estructura.

Objetivos de las clases

Los objetivos de las clases entonces parecen ser:

Ocultar detalles de la estructura de los datos en memoria
Permitir modificar esa estructura manteniendo la misma interfaz (¿modificar menos código a futuro?)
Escribir menos código al evitar usar el nombre del tipo de dato en cada función (ej: cambiar_algo_del_jugador, obtener_algo_del_jugador, etc.) y al ofrecer acceso implícito a las variables miembros de la clase (esto es: al escribir nombre sabemos que hacemos referencia a this->nombre, igual que hacer jugador->nombre en cualquier otra función fuera de Jugador)

Consejos para diseñar clases

Mi consejo es comenzar directamente con structs, todos los datos públicos, y un conjunto de funciones: funciones dentro del struct si modifican esos datos, y funciones globales si son lógica que usa el struct.

Empezaría usando la estructura con sus funciones y en algunos casos accediendo a sus datos directamente. Luego si nos damos cuenta que hacemos algo con los datos repetidamente, aparecerá la necesidad de crear una función (dentro del struct) para evitar duplicar código.

A futuro (cuando el sistema se hace más complejo) colocamos todas las variables miembro en campos private y también la mayor cantidad de funciones en private que podamos. Toda la interfaz (y lo más pequeña posible) en public. Al compilar los errores nos dirán dónde accedemos directamente a los campos que ahoran son private.

Tenemos que tener en cuenta que el desarrollo de software es algo evolutivo. Comenzaremos con el diseño más sencillo que podamos (estructuras y funciones que modifiquen esos datos) y luego a medida que avanzamos empezamos a ocultar más información, agregando funciones miembro (métodos), etc.

En definitiva mi consejo sería:

No hagas algo excesivamente “robusto” en un principio si no sabes que lo que estás haciendo durará por mucho tiempo. Ej. un simple programa para resolver un problema pequeño tal vez no requiere de tanta ingeniería/arquitectura/etc.
Las clases aparecerán solas por necesidad de modificar datos, y las relaciones entre clases por las relaciones entre esos datos. Mientras menos relaciones/dependencias entre distintas clases, y jerarquías de clases tengamos, mejor.

Yo diría que el único enfoque posible es pensar en datos y no en cosas/objetos del mundo real, sino más bien en qué datos necesitamos para resolver el problema que tenemos que resolver.

Comienzo, luego escribo

2020-08-22T00:00:00+00:00

Esto fue escrito el 14 de mayo del 2019. Es un texto perdido de algo que nunca comencé titulado “Comienzo, luego escribo”. Subtitulado “Pensando como una colonia de hormigas.” Creo que vale más para este año 2020.

Sobrevivir, eso es lo único que importa.
Si no comienzo a escribir, moriré sin haber escrito.
¿De qué sirve escribir si todo lo que escribo no lo leerá nadie?
¿Qué es una idea en un mundo donde no existe nadie que la piense?

En caso de una catástrofe a nivel mundial nadie está seguro de nada, o dicho de otro modo, sólo estamos seguros de una cosa, nadie sobreviviría.

¿Podría la inteligencia sobrevivir un cataclismo? ¿Podría luego los seres vivos evolucionar a una forma más pequeña de ser vivo inteligente?

Lo que debemos entender es que nadie nos protege. Una vez superado el miedo inicial de que estamos solos en el universo, debemos empezar la “planificación.” La pregunta es, ¿qué debemos planificar?

Me Estoy Viniendo Viejo

2020-07-31T00:00:00+00:00

Lo que buscan todos los servicios de Internet es destruir tu tiempo personal, masacrarlo con la violencia más deshumanizada posible, hasta que no te queden más ganas de pensar o reflexionar sobre tu vida o tus experiencias personales. Es un baño de bosta que te abraza y asfixia.

O tal vez sólo me estoy viniendo viejo.

La Novedad

2020-03-25T00:00:00+00:00

Los seres humanos nos sorprendemos –obsesionamos– ante una nueva idea, una nueva forma de ver el mundo o resolver un problema, o una nueva tecnología, o algo que nos hace sentir especiales. Como que conocemos algo nuevo que los demás no conocen. Y todo parece encajar en esa nueva forma.

La magia perdura por días, semanas, o meses, pero luego de unos años las máscaras terminan cayendo, y lo que parecía novedoso y perfecto tiene sus fallas. Empieza a notarse el óxido, la mugre, el mantenimiento.

Las ideas terminan siendo no tan perfecta como parecían, sino más bien, un artefacto más del mundo: con sus errores, algo que vino evolucionando y nosotros lo encontramos en medio del camino, todavía imperfecto –y nunca lo será– pero con camino por recorrer.

Esto pasa en todos los ámbitos del universo físico y metafísico: seres vivos, ideas políticas, sociológicas, lenguas y lenguajes de programación, software y hardware, incluso el cuerpo y el sexo, las relaciones, la mente, etc.

Debemos aceptar que sólo estamos en el mundo para ver una parte del tiempo, una versión “no tan buena” de las cosas. Y son nuestros deseos de mejorarlas que crearán la próxima novedad que inspire a las generaciones que siguen —si es que no morimos por una pandemia global dentro de unas semanas.

La evolución de la naturaleza nos gana en tres aspectos al crear artefactos físicos: 1) millones de años de ventaja, 2) no piensa ni razona, 3) oculta los porqués y las relaciones en su larga historia de caos.

Todo Constexpr: Parte 1

2019-09-22T00:00:00+00:00

Este post es la primera parte de una serie en el que hablaremos un poco sobre la historia de la palabra clave const, la aparición de constexpr (C++11), y las futuras consteval y constinit (C++20).

Anteriormente vimos que usar const en todo es una buena idea para que el compilador chequee que no estamos modificando algo que no deberíamos modificar. Lo mismo se aplica con los contratos de las APIs, el compilador puede chequear que los tipos de los argumentos y valor de retorno de una función coinciden al ser usada. En una forma más general, podemos decir que un lenguaje de programación debería permitirnos que la mayor parte de código se ejecute y evalúe en tiempo de compilación —en vez de run-time, tiempo de ejecución.

En estos días estuve haciendo una búsqueda bibliográfica sobre las palabras claves const y constexpr, ya que existen algunas propuestas para C++20 que agregarían aún más ruido al asunto, como P1073r3: Immediate functions (consteval) y P1143r3: Adding the constinit keyword.

Origen de la palabra clave const

Conseguí una copia del libro The Design and Evolution of C++ de Bjarne Stroustrup, siguiendo las recomendación del paper P0939r3: Direction for ISO C++ para que los que quieran sumarse u oponerse a las propuestas al estándar de C++, tengan una idea del cómo y el porqué del origen del diseño de determinadas características de C++.

Jamás podré proponer algo al estándar, pero si lo hiciera, sería sólo para quitar features, no para agregarlas.

En la sección 3.8 Constants, Bjarne indica que el origen de const se remonta a la idea de los sistemas operativos de asignar memoria de sólo lectura o sólo escritura a los procesos. Inicialmente se proponían dos palabras claves: readonly y writeonly, con lo cual podrían haber sido posible escribir cosas como:

void f(readonly char* entrada,
       writeonly char* salida)
{
  // Se puede sólo leer datos desde "entrada", y sólo escribir en "salida".
}

La historia hizo que sólo readonly sobreviviera como la palabra clave const y el cambio se adoptara en C, no sólo en C++ —según cuenta Bjarne, este fue su primer contacto con los estándares en el Bell Labs C standards group.

Es interesante notar que nuevos lenguajes como Rust ahora cambiaron la opción por defecto, haciendo que todo sea read-only, y obligando a usar mut para las variables que se pueden modificar.

Pero esto no quedó ahí. Bjarne experimentó un poco más con la palabra clave const como una alternative a las macros para especificar constantes (tipadas y con scope):

const int n = 100;

int main()
{
  int valores[n]; // Podemos usar "n" en expresiones constantes
}

En vez de:

#define n 100

Y así evitar aún más el uso del preprocesador en el lenguaje —uno de los objetivos de C++ es eliminar el uso del preprocesador.

Inicialización de objetos globales

En la sección 3.11.4 Initialization of Global Objects, Bjarne nos recuerda cuál fue su objetivo con los tipos de datos definidos por el usuario: poder ser utilizados en cualquier lugar donde un tipo de dato built-in puede ser usado. Esto incluía la posibilidad de crear variables globales del tipo class (algo que Simula no poseía):

class Doble {
public:
  double valor;
  Doble(double v) : valor(v) { }
};

Doble s1 = 2;
Doble s2 = sqrt(2); // Se construye s2 llamando la función sqrt(2) en run-time

Aquí Bjarne explica que este tipo de inicialización no puede realizarse completamente en tiempo de compilación ni en tiempo de linkeado. Para eso se necesita una inicialización dinámica en run-time de este tipo de variables globales.

El orden de inicialización es:

Se inicializan todas las variables globales static (static initialization)
Se inicializan las variables globales dinámicamente (dynamic initialization):
- la inicialización dinámica se realiza en orden sólo para variables dentro del mismo archivo (translation unit),
- pero no se establece ningún orden para variables definidas en distintos translation units.
Se llama a la función main().

Esta relajación donde “no se establece ningún orden para inicializar variables globales definidas en distintos translate units” generó algunos problemas —explicados en la sección 3.11.4.1 Problems with Dynamic Initialization—. Aunque el mismo Bjarne admite que si dos variables globales dependen de un orden específico de inicialización, podríamos estar frente a un “diseño pobre” de nuestro software, la misma librería C++ sufre de esta falla con cout/cin. Un simple ejemplo:

#include <iostream>

class A {
public:
  A() { std::cout << "A\n"; }
};

A a;

int main() { }

¿Cómo sabemos que std::cout está inicializado si es una variable global definida en otro translation unit?

In other words, we had been bitten by the order dependency that I had considered “unlikely and poor design.” – Bjarne Stroustrup

Segunda parte

En la segunda parte de este artículo —todavía a escribirse en un futuro incierto— veremos cómo usar constexpr para unir estos dos conceptos: variables globales que se inicializan con una evaluación de una función en tiempo de compilación.

Rock

2019-03-19T00:00:00+00:00

¿Cuándo empecé a escuchar rock? Probablemente mucho antes de lo que pienso, pero no lo recuerdo. Sólo tengo una clara memoria de un evento en particular: cuando empecé a escuchar Queen, me empezó a gustar el rock —y probablemente el funk—.

De chico, en las vacaciones —o en fines de semanas largos— visitaba junto a uno de mis hermanos a mi padre en Rosario, en el monoambiente que alquilaba —en el cual también vivía otro de mis hermanos—. Ese monoambiente tenía una gran ventaja: nos podíamos aburrir. Entre cajas, papeles, y libros, también había un pequeño tesoro: una radio. La combinación aburrimiento + radio nos hacía buscar alguna estación para escuchar algo entretenido.

No tengo un claro registro en mi mente de haberme interesado por la música antes de un día en particular. Ni tampoco tengo registro por aprender el nombre de una banda, ni de una estación de radio antes de ese mismo día. Ese día escuché esto:

Desde ese entonces supe que me gustaba el rock, y Queen, y que la estación era Radiofónica, y que la iba a sintonizar en futuras visitas a Rosario. Esa versión de Another One Bites the Dust siempre me gustó antes que todo. (El fanatismo temporal generó un video juego que es una bizarreada que mezcla Tetris + Queen + bombas.)

¿A qué viene todo esto? A absolutamente nada relevante para el lector. Esto me llevó a conocer un compañero en la secundaria que vendía un par de CDs de Queen –Greatest Hits I y II– con el cual luego terminamos yendo a clases de guitarra –por tres cortos meses—, y que hoy en día es como otro hermano.

A quemar todas las gomas

2018-11-03T00:00:00+00:00

Esto es el futuro. Un infinito flujo de videos. Graffitis en una pared digital. Máximas de gente que nunca se equivocó en la vida. Bots luchando en una red social. Trolls ladrando en su eterna soledad.

Rellenando cada espacio vacío de nuestra vida con nuestros celulares. De abuelos nos preguntarán “¿cómo era vivir en tu época, nono?,” y la respuesta me da terror. “Había tantos memes que no podíamos ni pensar.”

Bienaventurados los que puedan experimentar la vida sin necesidad de contar cuántos vieron sus historias.

Internet, a vos te digo: I gave you my money, I gave you my time. Why you want to hurt me, girl.

Inteligencia Artificial

2017-07-16T00:00:00+00:00

Para los que no saben, tengo una libreta donde anoto cosas “importantes” —importantes para mí, claro. El 12 de marzo de 2015 escribía:

El mundo virtual es una hermosa puerta al mundo “ideal.” El mundo ideal no existe, pero es un mundo ficticio formado en nuestra cabeza, donde todo parece funcionar perfecto, y se acerca a lo que nosotros queremos. Donde somos pequeños dioses omnipresentes. Podemos “escuchar” todo y “participar” en todo. Como si fuéramos posibles engranajes en la construcción de algo importante que nunca llega. Pero que ahí parece estar.

Un mundo ideal de posible —aparente— construcción. Y en este mundo nuestra palabra parece tener importancia. Nos convencemos —mentimos— que nuestras contribuciones son significativas, que hacemos un aporte a la sociedad con la más mínima intervención. Que nuestros gustos y opiniones tienen algún tipo de valor.

Al usar la computadora, nos acercamos a un mundo platónico, de ideas perfectas. Probablemente este mundo ideal sea para seres ideales. Nosotros —seres humanos— no estamos incluidos en esta ecuación.

Consejos para desarrolladores de herramientas

2017-07-13T00:00:00+00:00

Hace unos días me preguntaron por algunos consejos que pueda ofrecer para los desarrolladores independientes de herramientas de software para escritorio. No se me ocurren muchas cosas pero estos son algunos puntos:

Primero concentrarse en Windows, sólo porque existe la mayor cantidad de usuarios y puede ser el mejor pay-off a corto plazo —y además no van a querer dar soporte en tres plataformas inicialmente si son realmente independientes.
Seguiría con macOS —empezaría por macOS si la aplicación es de diseño gráfico o sonido— y finalmente Linux.
Si el framework que utilizan provee soporte a estas tres plataformas casi de manera automática, podrían publicar para las tres plataformas desde el arranque de su proyecto.
Prefieran librerías en vez de frameworks, y envuelvan la librería con su propia capa. Si en el futuro necesitan cambiar la librería, deberán sólo cambiar la implementación debajo de esa capa, todo el resto del programa está a salvo y sin requerir modificaciones.
Si eligen un framework, tengan en cuenta que a futuro podría limitarlos mortalmente. Literalmente un framework puede condenar a un programa a no tener determinado feature o no poder arreglar un bug en particular. Elijan los frameworks con cuidado.
Necesitarán una PC con Windows —preferentemente una Surface— para dar soporte apropiado a usuarios en Windows 7/10, y una Mac para macOS —y una MacBook o un Magic Trackpad para dar soporte apropiado a eventos touch. En otras palabras: necesitarán hardware real para saber cómo funcionan sus programas en ese mismo hardware. Las máquinas virtuales no sirven para esto.
Recuperación de errores: Si alguien crea o diseña cosas con sus herramientas tengan en cuenta que los errores valen oro. Intenten obtener la mayor cantidad de información de cada usuario que tiene un error —memory dumps, bug reports, etc. No subestimen la importancia de los memory dumps y .pdbs en Windows. Y recuerden que perder datos es lo peor que les puede pasar a sus usuarios —y más cuando estos datos son arte. Aprovechen un crash para arreglar un bug.
Tratar de dar el mejor soporte de usuario, y de ser posible, centralizado —ej: un foro propio. También dar una dirección de email support@my-desktop-tool.com podría ser bueno para tener una conversación privada en caso de ser necesario —ej: para compartir un memory dump.
¿Código fuente abierto? ¿Libre? ¿O cerrado? Hagan lo que quieran. Son libres de elegir la licencia que vaya mejor con ustedes y recuerden que no le deben nada a nadie. Sus creaciones son suyas y pueden hacer con ellas lo que quieran.
Intenten ponerse en contacto con gente que sea profesional en el área que maneja su programa y sigan sus consejos. Deberán aprender a procesar todas las ideas recibidas y crear una interfaz que se ajuste a sus requerimientos, y en el mejor de los casos, que los supere.

Apaguen Todo

2017-02-22T00:00:00+00:00

Veo este blog y cada vez escribo menos aquí –y más en otros lugares privados–. Un blog es una fuente de preguntas que nadie hizo. Y las redes sociales comparten el mismo problema. Nos ofrecen millones de bytes de información, datos, hechos –y no-hechos–, que nunca nos llegamos a preguntar en primer lugar. ¿Para qué los necesitamos? Y aún así las seguimos usando. Eso es una adicción. (Aunque los blogs no comparten esa adicción con respecto a las redes sociales, parecen ser más aburridos, tal vez porque hay que procesar más datos.)

La mejor forma de obtener nueva información –leer– hoy en día es como lo hacían siglos atrás. Apagando todos los aparatos –menos el aire acondicionado– y prendiendo una vela. Incluso sospecho que la luz artificial está ayudando al cansancio de mi vista. Citando Wikipedia –la fuente de “la verdad”–:

Según un estudio reciente parece ser que los ledes que emiten una frecuencia de luz muy azul, pueden ser dañinos para la vista y provocar contaminación lumínica.

¿Vas a correr el riesgo de arruinar tu vista con esas luces? Por eso ayer hice una prueba: Teniendo la vista muy cansada de ver tantas pantallas intenté leer, pero a la luz de la vela. Noté dos cosas inmediatamente: 1) La vista ya no me resultaba cansada luego de un rato, 2) No me sentí con más sueño al final de la lectura que al inicio. ¿Será la luz artificial el problema?

Como gran wikipediano –y mentiroso del mundo real– me gusta sacar conclusiones universales a partir de una sola muestra. En unos meses tendré información más concreta sobre mi experimento. Por ahora, apaguen todo.

Cajas Caminando

2016-10-15T00:00:00+00:00

Veo un futuro donde caminamos por las calles, subimos a los colectivos, entramos a negocios y nunca nos hablamos. Un futuro donde una palabra, un gesto o una opinión podrá ser tomada en tu contra.

Veo un futuro lleno de cajas caminando. Sin boca ni ojos. Sin poder desear un buen día, o decir algo bonito a otra persona. Veo un futuro donde el saludo será considerado un insulto. Y la sonrisa un intento de violación.

El Nuevo Sentido

2016-08-28T00:00:00+00:00

Quiero creer que una sociedad que desarrolla la capacidad de los viajes interestelares también desarrolla la capacidad de despojarse de toda creencia religiosa, egocentrismo, y sentimiento de conquista hostil.

Generalmente existe un temor sobre el posible accionar de una llegada de extraterrestres al toparse con la tierra, poniendo de ejemplo el mismo comportamiento del hombre al colonizar otras regiones. Hay que tener en cuenta que este miedo se da a partir de la historia humana del pasado, lo que no establece un parámetro o condición a futuro para una civilización que puede viajar a otros mundos.

La pregunta es ¿cómo nos comportaríamos al poder visitar otros planetas?, al enterarnos que las religiones existentes eran sólo historias que abarcaban nuestra visión miope, ¿qué nuevas religiones vendrán a explicar lo inexplicable? ¿qué será lo inexplicable?

El futuro de la humanidad nadie lo conoce y el comportamiento, o nivel de sinceridad espiritual, al que llegaremos al conquistar nuevos mundos no podemos predecirlo. Mi único consejo para las civilizaciones futuras es: “estemos preparados para cambiar nuestras mentes y deshacernos de todo lo que ya no tenga sentido, cuando el nuevo sentido llegue.”

Escrito originalmente el 12 de abril de 2016.

Lambda en C++

2016-06-26T00:00:00+00:00

C++11 proporciona funciones lambda a C++. A veces me pregunto ¿cómo se imagina alguien que viene de C qué son las funciones lambda en C++?

Supongamos una estructura que puede trasladar un punto x, y unas dx, dy unidades:

struct Trasladar {
  int dx, dy;

  Trasladar(int du, int dv) {
    dx = du;
    dy = dv;
  }

  void aplicar(int* x, int* y) {
    (*x) += dx;
    (*y) += dy;
  }
};

Con esta estructura podemos crear traslaciones y aplicarlas cuantas veces queramos a un punto x, y:

int main() {
  int x = 5;
  int y = 10;

  Trasladar t(2, 4);
  t.aplicar(&x, &y);
  t.aplicar(&x, &y);

  assert(x == 9);  // 9 = 5+2+2 al aplicar "t" dos veces
  assert(y == 18);
}

En vez de aplicar podríamos sobrecargar el operador de llamada a función operator(), entonces la estructura Trasladar puede ser utilizada como una función (a nivel sintaxis):

struct Trasladar {
  int dx, dy;

  Trasladar(int du, int dv) {
    dx = du;
    dy = dv;
  }

  void operator() (int* x, int* y) {
     //^ "operator()" no es distinto a cualquier otro nombre de
     //  función, ej: como nuestra anterior función "aplicar"
    (*x) += dx;
    (*y) += dy;
  }
};

int main() {
  int x = 5;
  int y = 10;

  Trasladar t(2, 4);
  t(&x, &y);
  t(&x, &y);
//^ La única diferencia es que ahora podemos usar "t" con la
//  misma sintaxis que una llamada a función
}

¿Qué ventaja tiene utilizar “la sintaxis de llamada a función” (ej t(...)) en vez de una llamada a una función miembro como t.aplicar(...)? La ventaja es que la sintaxis a llamada a función es “más genérica” para componer otras funciones:

template<typename T>
void aplicar_n(int n, int* x, int* y, T t) {
  for (; n > 0; --n, ++x, ++y)
    t(x, y); // Llamar la transformación "t" para los "n" puntos
}

Lo bueno de esta función genérica aplicar_n es que sirve para cualquier “cosa” T que soporte la sintaxis de llamada a función:

void mover_x_2_unidades(int* x, int *y) {
  (*x) += 2;
}

int main() {
  int u[] = { 1, 2, 5 };
  int v[] = { 3, 5, 2 };
  aplicar_n(3, u, v, mover_x_2_unidades);

  // O lo que sería igual a usar nuestra estructura "Trasladar"
  aplicar_n(3, u, v, Trasladar(2, 0));

  assert(u[0] == 5);
  assert(u[1] == 6);
  assert(u[2] == 9);
}

En este punto, se dice que Trasladar es un functor (objeto que actúa como una función). En C++11, la nueva sintaxis para funciones lambda básicamente nos permite crear “functors” al vuelo, anónimos, sin nombre, en la misma línea donde los necesitamos:

aplicar_n(3, u, v,
  [](int* x, int* y) {
    (*x) += 2;
  });

El parámetro

[](int* x, int* y) {
  (*x) += 2;
}

Crea la estructura

struct Lambda {

  void operator() (int* x, int* y) {
    (*x) += 2;
  }

};

También podríamos utilizar variables del ámbito donde creamos la “función” lambda

int a = 2;
aplicar_n(3, u, v,
  [a](int* x, int* y) {
    (*x) += a;
  });

Lo que crearía un “functor” como el siguiente

struct Lambda {
  int a;

  Lambda(int a) {
    this->a = a;
  }

  void operator() (int* x, int* y) {
    (*x) += a;
  }
};

En conclusión, la sintaxis para funciones lambdas en C++11 no es más que una forma de crear estructuras anónimas con el operator() sobrecargado.

Puertas

2016-02-16T00:00:00+00:00

Nuestra mente está llena de puertas. Cada vez que leemos un cuento o vemos una película, abrimos una de estas puertas. Y ahí aparecen los personajes, como si hubieran estado todo este tiempo dentro nuestro pero sin ser descubiertos, en un mundo de oscuridad.

Ahora sentimos cosas por ellos y no se van. Se quedan con nosotros y nos acompañan. Aunque cerremos la puerta, o los tapemos con una sábana, sabemos que ahí están. No los podemos matar. No podemos destruirlos nunca más.

UI Eterna

2015-12-02T00:00:00+00:00

¿Existe una Interfaz de Usuario eterna al tiempo? ¿Que atraviese todas las épocas y nunca quede obsoleta? ¿Que pueda ser utilizada en el presente y en el futuro, o mejor aún, en todos los futuros posibles?

¿Hay una interfaz que perdure más allá de los estándares actuales? ¿Algo que no sea ni desktop, ni touch, ni realidad virtual, y al mismo tiempo sea todo eso?

¿Por qué hablamos de botones, menús, check boxes, combo boxes, list boxes, radio buttons? ¿Cuáles son los conceptos y datos que se esconden detrás de ellos? ¿Y por qué existen tantas cosas para seleccionar o decir lo mismo? ¿Serán Ctrl+C, Ctrl+X y Ctrl+V (o ⌘C, ⌘X y ⌘V) atajos del teclado en el futuro?

¿Por qué los elementos en la pantalla no mutan y se transforman a algo más acorde a nuestro dispositivo? ¿Por qué un list box es un list box? ¿Por qué no se convierte en un combo box cuando achicamos la ventana, o en un botón con un ícono que al “clickearlo” muestra un menú contextual? ¿Y por qué no en una hamburguesa?

Todo este conglomerado de widgets forman el “estándar actual” de las interfaces de usuario. Y desarrollar aplicaciones para los distintos dispositivos implica crear una interfaz de usuario totalmente distinta para cada uno de ellos. Y en la mayoría de los casos, cada interfaz en su propio lenguaje de programación –utilizando herramientas completamente disímiles–.

¿Puede una CLI, una GUI, y una API ser lo mismo? ¿Pueden modificar, accionar, y ejecutar el mismo modelo de datos? ¿Existirá una forma de generar todo el código de estas interfaces a partir de un conjunto de reglas sencillas? ¿Serán los estándares web la forma de desarrollar aplicaciones en el futuro? ¿Será HTML5+CSS3+JavaScript ese conjunto de reglas “sencillas”? Espero que no.

¿Qué es un click en la realidad virtual?

Const a todo

2015-11-05T00:00:00+00:00

Aquí algo para enseñar el día uno en un curso de programación. Dada la siguiente función que suma dos enteros:

 int suma(int x, int y) {
   return x + y;
 }

¿Qué está mal con este código? Respuesta: Que permite cometer errores como el siguiente:

 int suma(int x, int y) {
   x = 0;
   return x + y;
 }

¿Por qué podemos modificar un argumento de entrada que se supone que no debe cambiar? Es decir, en nuestra cabeza hemos diseñado una función, pero en código hemos escrito algo que permite equivocarnos más de lo que debería.

Si forzamos a que un argumento sea const (de sólo lectura, read-only):

 int suma(const int x, const int y) {
   return x + y;
 }

Podemos detectar errores en tiempo de compilación:

 int suma(const int x, const int y) {
   x = 0; // Error de compilación porque "x" es "const"
   return x + y;
 }

En un ejemplo simple como esta función suma no parece tener sentido, pero en funciones complejas, el const de los argumentos se propaga a otras funciones internas y los chequeos que el compilador puede realizar crecen exponencialmente.

Esto nos hace recordar que los argumentos en las funciones son variables locales. Y como cualquier otra variable se puede modificar en el mismo cuerpo de la función. Por ejemplo:
void desde_i_hasta_j(int i, const int j) {
  for (; i <= j; ++i) {
    // Hacer algo con "i"
  }
}

Oda a los terrícolas

2015-09-11T00:00:00+00:00

Tentáculos apasionados.
Tus abrazos hacen sangrar huesos.
No me aprietes despacio,
prefiero morir completo
antes que esta agonía.

Alien embrionario
tu aliento levanta muertos.
No importa el destino,
esta nave está perdida.
Igual batalla damos,
el dentífrico olvidamos.

Un Alf de terciopelo
te espera en la garita.
Este universo tiene dos paradas,
y el boleto come billeteras.
Gatos acá no suben.

Pichón del televisor.
Esponja de mentiras.
Te venden perros
mientras tu correa aprieta.
Loro promiscuo,
deja de ladrar autores.

Profesor con elevada facturación.
No tanto por enseñar
sino más bien por películas hacer.
Otra historia de garras
mutantes va a vender.

Tractor galáctico,
esa cosecha no se echó a perder.
Vayamos a Venus a rescatarla.
Las palabras no son en vano,
es el juego del planeta.

Hovercraft del pasado,
hasta donde llegan tus colchones.
Ir por tierra no es lo mío,
sólo el agua me interesa.
Inflador del tiempo llevo.

Pitufo corriendo un rally
en un plato de ravioles.
No por imposible
los motores no existen.
Este blue ya se escapa,
ni por salsa ni ricota.

Aperitivo galáctico.
Colectivo lleno de cumbias.
No cambio tus labios por estos sonidos.
Más que sonidos son ruidos.
Más que ruido gritos.

Instantáneo, cuantas veces
me has salvado las papas.
Tus proporciones no las entiendo,
pongo cualquier cosa
y siempre puré aparece.

Callbacks

2015-06-01T00:00:00+00:00

Los viejos callbacks de C, ¿quién los recuerda? ¿nadie? ¿punteros a una función? ¿no? Meh, no importa. Imaginemos esta interfaz:

interface Callback {
  bool match(int valor);
}

El método match() devolvería true si el valor es de interés.

En C++ se escribe lo mismo así:

class Callback {
public:
  virtual ~Callback() { }
  virtual bool match(int valor) = 0;
};

Podemos tener un algoritmo que nos dé como resultado el índice del primer ítem que matchea nuestro Callback:

int buscar_primera_coincidencia(const int* array,
                                int elementos,
                                Callback* callback) {
  for (int i=0; i<elementos; ++i) {
    if (callback->match(array[i]))
      return i; // El item i es el primero en cumplir match() == true
  }
  return -1;
}

Así podemos crear miles de implementaciones Callback:

class EsCinco : public Callback {
public:
  bool match(int valor) override {
    return (valor == 5);
  }
};

O también:

class DistintoDeCero : public Callback {
public:
  bool match(int valor) override {
    return (valor != 0);
  }
};

O mucho mejor, hacer una clase genérica:

template<int VALOR>
class EsIgualA : public Callback {
public:
  bool match(int valor) override {
    return (valor == VALOR);
  }
};

Y usarla así:

int main() {
  int array[] = { 4, 8, 15, 16, 23, 42 };

  EsIgualA<16> igual16;
  int resultado = buscar_primera_coincidencia(array, 6, &igual16);

  assert(resultado == 3);
}

Podríamos decir que Callback es algo así como interfaz delegate: Alguien a quien le derivamos parte del trabajo que buscar_primera_coincidencia necesita.

Un ejemplo exactamente igual se da en la función qsort. Sólo que la interfaz Callback en este caso es un puntero a una función:

void qsort(void*  ptr,
           size_t count,
           size_t size,
           int  (*comp)(const void*, const void*));
                 //^ Un verdadero callback: un puntero a una función

Lo que sería igual a:

class Comp {
public:
  virtual ~Comp() { }
  virtual int comp(const void* elementoA, const void* elementoB) = 0;
};

void qsort(void*  ptr,
           size_t count,
           size_t size,
           Comp*  comp);

En un próximo post vamos a ver cómo la STL utiliza conceptos similares a callbacks y delegates en su diseño.

Este es el primer post de una seguidilla que tengo planeada sacar respecto a callbacks, signal programming, signals y slots, patrón observer, cálculo lambda, inversión de control, inyección de dependencias, etc.

REPL y tests

2015-04-29T00:00:00+00:00

Un REPL (Read–Eval–Print Loop) es un pequeño programa que lee un comando del usuario, lo interpreta, lo evalúa, e imprime el resultado.

Este tipo de interfaces pueden usarse para: 1) tener una forma simplificada de acceder y ejecutar funcionalidad de nuestro programa, y 2) probar la lógica de una forma directa.

Por ejemplo, supongamos que tenemos una función suma:

int suma(int x, int y) {
  return x + y;
}

Y queremos ver que realmente esté haciendo lo que debería estar haciendo. Una opción es hacer un programa de prueba con varios asserts:

#define _DEBUG
#include <cassert>

int main() {
  assert(suma(0, 0) == 0);
  assert(suma(2, 3) == 5);
  assert(suma(4, 8) == 12);
  assert(suma(2, -3) == -1);
}

Pero supongamos que tenemos cientos de funciones, y que cada una puede interactuar con las demás generando distintos resultados y combinaciones. (O incluso los resultados esperados pueden no entrar en un archivo de código fuente, ej: el resultado puede ser una imagen.) En estos casos puede ser beneficioso tener un “script” al que se le puedan agregar pruebas.

En C++, la forma más simple de implementar un REPL es utilizando la función std::getline:

#include <iostream>
#include <string>
using namespace std;

int main() {
  string line;
  while (getline(cin, line)) {
    if (line == "exit")
      break;
  }
}

Con este código leemos línea a línea la entrada estándar hasta que el usuario ingrese exit. Ahí termina todo. Lo interesante es que podríamos leer cada línea e intentar interpretar los comandos que se ingresan. Una línea representaría una prueba distinta. Por ejemplo, teniendo un archivo de texto pruebas.txt:

suma 0 0 0
suma 2 3 5
suma 4 8 12
suma 2 -3 -1
exit

Podemos crear un programa que lea estas líneas, ejecute las llamadas a suma, y muestre los resultados:

#include <iostream>
#include <sstream>
#include <string>
using namespace std;

bool eval(const string& line);

int main() {
  string line;
  while (getline(cin, line)) {
    if (!eval(line))
      break;
  }
}

bool eval(const string& line) {
  stringstream input(line);

  string cmd;
  input >> cmd;

  if (cmd == "exit") {
    return false;
  }
  else if (cmd == "suma") {
    int x, y, expected;
    input >> x >> y >> expected;

    int result = suma(x, y);

    cout << "suma(" << x << ", " << y << ") = "
         << result << " "
         << (result != expected ? "(FAILED) ": "(OK)")
         << endl;
  }

  return true;
}

Así podemos ejecutar el programa por medio de la línea de comando pasándole el archivo pruebas.txt como entrada estándar. Es como si cada línea del archivo fuera escrita por el usuario a mano, sólo que todo sucede de forma automática y obtenemos los resultados al instante:

suma(0, 0) = 0 (OK)
suma(2, 3) = 5 (OK)
suma(4, 8) = 12 (OK)
suma(2, -3) = -1 (OK)

Creamos un pequeño script tests.bat que sólo haga:

repl.exe < pruebas.txt

¿La ventaja? Podemos –nosotros y otra gente– agregar más pruebas sin recompilar el programa original, y con doble-click ver los resultados.

Somos bufones

2015-04-28T00:00:00+00:00

¿Todavía siguen haciendo eso de votar? Porque aquí en Argentina es obligatorio.

Encuentro fascinante todo el acto de la votación. Esa pantomima berreta que nos ofrece la dosis justa de sedante para olvidarnos de un posible despertar. “Oigan, podríamos estar haciendo algo verdaderamente significativo para la gente.”

Toda la imagen me parece surrealista. Esa cola en espera para el cuarto oscuro –debe llamarse así por lo macabro de la situación–. Viéndonos a pasos de dar un voto a personas que no conocemos –y que nunca vamos a conocer–. Dando votos a seres que probablemente ni los amigos conocen del todo. Que ni sus parejas confían en ellos. ¡Qué verdadero salto de fe –al vacío– al que nos obligan!

El acto viene condimentado con un poco de todo, hasta se asimila a esos casamientos arreglados: “Sí hijo, está mujer es la que te conviene, ya nos pusimos en los detalles con sus padres, vos no te preocupes.”

Siempre que voto, en mi mente repaso las opciones: El voto en blanco es el de la anarquía. El de la izquierda un engaño. Y el de la derecha imposible que falle –para otro bando–. Pero seguimos votando chantas, porque no sólo nos obligan a votar, nos convencieron de que es justo, a la fuerza. “¡Mirame! Valgo la pena, no soy un impostor, ¡votame!” Y ahí va otro voto ciego a esos fanáticos de la mercadotecnia. ¡Vivan los representantes –de no sé qué– carajo!

Por suerte, de vez en cuando en una elección aparece un payaso. Esos bufones que hacen que los demás candidatos parezcan hombres de bien. Honrados. Hasta inteligentes. ¡Me mato de risa de los que se horrorizan de estos grotescos seres! Pensando que los “honrados” son ahora dignos de recibir voto alguno. Para que todo el teatro continúe. ¡Cómo necesita la política de esas nefastas caricaturas! Porque los ridículos enaltecen hasta al más incompetente. “Vení, ponete al lado mío, me haces sentir más lindo.”

Y quiero aclarar que esto no es un ataque a la democracia. ¡Nada más errado! Soy pro-democracia, pero no representativa. Y aquí quiero hacer notar que encuentro fascinante –y no distingo diferencias– tanto en el que dice “hoy vamos a cumplir con ese hermoso deber cívico” como el que lo afronta desde un “vamos a votar así nos sacamos este peso de encima.” Ahí siempre está, en ambos casos, la actitud infantil de votar un rostro.

— ¿Y nene? ¿Ya votaste? ¿Votaste bien? ¿A la más linda, no?
— Sí pa, voté a la más linda, ¿puedo seguir viendo televisión ahora?

¿Tendrá la democracia representativa los días contados? Sé que debe existir una gran cantidad de gente que vale la pena votar y lucha contra todo un sistema corrupto, políticos honestos –dos palabras difíciles de escuchar juntas–, pero el estado actual de la política no promueve un flujo de voto hacia ellos, sino más bien, todo lo contrario.

Sentido de hogar

2015-03-08T00:00:00+00:00

¿Existirá grabado en nuestro cerebro un sentido de hogar? ¿Un sentido de estar en casa? ¿Estar a salvo? ¿Es sólo el miedo lo que nos moviliza a protegernos en cuatro paredes? ¿Es también la vergüenza? ¿A veces estamos más seguros afuera que adentro?

Existe un lugar –sea un departamento alquilado, una casa rodante, o un castillo– donde estamos a salvo de los fantasmas del mundo. Parece ser que necesitamos un lugar donde poder sobrevivir del exterior, y vivir en nuestra privacidad. Poder pensar tranquilos, poder dormir y dejar afuera el mundo hostil.

La necesidad de techo debe ser la primera necesidad no fisiológica. Las cuevas, nuestros primeros refugios. Nada sofisticadas, pero suficientes como para no morir de una lluvia, el frío y el viento. Parece ser que necesitamos estar envueltos para sentir seguridad. Al menos sea con unos diarios.

Luego el exceso de modernización convirtió al hogar en cuatro paredes. Llenas de adornos y comodidades. Y aun así, el exceso trajo los miedos a nuestro propio hogar. Ahora el fantasma no está sólo afuera, sino también adentro. Debemos salir para no morir asfixiados por lo cotidiano de estas paredes. Lo artificial es nuestro nuevo peligro, y probablemente el sentido de hogar esté afuera más que adentro.

Energía del desamor

2014-12-08T00:00:00+00:00

Uno necesita tiempo, recursos y energía para poder mantener una relación estable. La idea es que si esas cosas se dan naturalmente entonces se disfruta todo el proceso –en teoría, según dicen–. Aunque la estabilidad de una relación ya es suficiente motivo para sorprenderme, esto no es lo más extraordinario. Lo más extraño del ser humano es toda la energía utilizada en la no relación, o mejor dicho, el desamor. Esos restos que quedan de una relación que no funcionó –o que nunca fue–.

La cantidad de tiempo que uno piensa en lo que no fue es monumental. Cuando uno se embarca con una persona el viaje asegura un consumo de tiempo y energía –tanto en lo que dure la relación como a futuro–. Romper con alguien es como sacar vacaciones inversas: pasar tu tiempo libre en tu casa consumiendo energía en algo que no estás disfrutando.

Hay dos cosas que me resultan interesantes:

La facilidad con la que podemos dejar entrar a alguien a nuestra vida, decirle “bienvenido a mi mundo”, “quiero que me acompañes”, etc.
La facilidad con la que pueden echarte de ese mundo. Algo así como un firme fuck you antes de que te cierren la puerta en la cara.

Es esa energía que fluye en el universo la que más me sorprende. Esa posibilidad de abrir y cerrar puertas con facilidad por un lado, y con dificultad del otro.

Tal vez tenga que ver con la conservación de la energía: para que una pareja funcione tienen que existir los desamores de otros. O tal vez es un poco de energía oscura: El desamor es esa energía que ayuda a expandir el universo, principalmente el personal, el de los solteros.

No sé si existo

2014-11-09T00:00:00+00:00

Intentando escribir ficción me di cuenta que no existo. No sé si soy real, eso está en otro sitio. Nadie más que vos y mi cerebro ven esta danza de dedos y ahora lees algo nuevo. ¿Dónde va nuestro ser cuando estamos escribiendo, creando, produciendo? Existo cuando no pienso, no existo cuando escribo.

A las palabras el viento ni las toca. Ni cuerpo tienen fuera de nuestra cabeza. Conceptos relampagueando en el cráneo, sólo aparecen y desaparecen a medida que nos alimentamos de estos garabatos, líneas negras sobre blanco.

A las palabras se las llevan los teclados. Combinaciones exactas de golpes producen un viaje de la mente a otros universos. Una secuencia irrepetible de teclas produce un texto único. ¿Cuántos años pasarán para que otras manos pasen por los mismos interruptores? ¿Es la ficción una mano sobre un teclado? ¿Unos dedos escribiendo? ¿Un cerebro pensando? ¿Unos conceptos volando? ¿Son sólo una simulación de relámpagos? ¿Negro sobre blanco?

La ficción existe, pero es como una hermosa mujer inalcanzable, que ya está adentro de tu cabeza intentando escapar, y no puede salir nunca más.

Parásitos del open source

2014-04-09T00:00:00+00:00

El reciente bug de OpenSSL deja al descubierto la cultura que rodea al open source: ~~todos~~ muchos son unos parásitos. ¿Cuántos proveedores de hosting habrán dado tiempo, dinero o recursos para mejorar el código de OpenSSL? ¿Uno? ¿Dos? ¿Cien? ¿Cuántos millones usarán servidores HTTP como Apache sin devolver absolutamente nada a la comunidad? ¿Cuántos tienen corriendo su negocio “de arriba”?

El software sin bugs no existe, pero si tu empresa depende de un software X, deberías invertir algo en ese software. Los bugs no desaparecen por arte de magia, sino más bien aparecen por arte de magia. Y en este caso me alegra decir esto: La culpa no es de los desarrolladores de OpenSSL. La culpa es de todos los que usan el software y nunca pusieron un peso para nada. (Por ejemplo para montar una buena estructura de testing automatizado que mitigue la introducción de nuevos bugs.)

¿Cómo sería una buena cultura de open source? Que los que usen un programa open source sepan que le deben algo a sus desarrolladores. Si alguna vez pierden datos por un crash, información sensible de sus clientes por un bug, o la vida de alguien está en riesgo por un error en un pedazo de código abierto, la culpa es suya por usarlo y no devolver nada a cambio.

Ideas Interesantes

2014-03-24T00:00:00+00:00

¿De dónde vienen las ideas interesantes? ¿Por qué lo que a mí me resulta interesante lo que a otro no? ¿Existe una fuente de ideas? ¿Existe la “cigüeña de ideas”? Y si existe, ¿por qué no me contaron ese cuento? ¡Malditos!

Llega el final de marzo y no escribí ningún artículo, post, y/o barbaridad en esto que se hace llamar blog. Es feriado y aprovecho a escribir. Me preparo un café. Leo algo, intento escribir. Nada. Más café. No viene ninguna idea interesante a mí. Miro el desorden de mi casa. Realmente prefiero escribir antes que ordenar este chiquero. “Ideas vengan a mí.”

¿Qué hace que algo genere interés? Ayer –hoy– estaba leyendo artículos de diario a la una de la mañana –sí, una de la mañana, yo, leyendo el diario–. Estuve tan inmerso a tal punto que dormí entre diarios. No podía dejar de leer o dejar pasar por alto ciertos artículos. Algunos de los cuales ya no me explicó porqué no podía dejar de leerlos. Si pasaba a otra cosa, luego tenía que volver al anterior y terminarlo.

Pero poniendo la pava para calentar más agua, tuve algo revelador: La idea no importa, todas son interesantes. El problema no es el contenido, el problema es la forma.

Es cierto que algunas ideas son interesantes por la misma naturaleza de la pregunta. Por ejemplo, “¿existe vida después de la muerte?” es el tipo de pregunta que puede hacernos volar por un buen rato. Pero también es una pregunta que se puede arruinar completamente. Si la presentamos como “sí, la vida después de la muerte existe, vino un alienígena ancestral y me tiró la posta” corremos el riesgo de perder el interés rápidamente.

Nuestro cerebro parece estar más a gusto con ciertos patrones de belleza. El diseño gráfico, la publicidad, la producción editorial, no son cosas que aparecieron “por casualidad”. Una buena historia no es buena si no está bien contada. Un chiste no es gracioso si no se cuenta bien. Y si cosas tan pequeñas como los chistes nos abren un sin fin de posibilidades de cómo contarlo mal, no quiero pensar en artículos, cuentos o novelas.

¿Entonces las buenas ideas son ilimitadas? Sí, están por todas partes. Cualquier cosa puede ser una idea interesante. Sólo hay que ponerles un buen escote y la gente tendrá ganas de consumirlas.

Reading time in Jekyll

2014-02-22T00:00:00+00:00

Do you want to display the reading time in your Jekyll’s blog –e.g. like in Medium.com–? Here you have a simple way –without plugins–. First of all we’ve to calculate the reading time dividing the number of words of your page’s content by 180 –assuming that we can read 180 wpm on a monitor–:

{% capture read_time %}
  {{ page.content | number_of_words | divided_by: 180 }}
{% endcapture %}

Then if the read_time variable is equal to 0, we can display 1 just to avoid a 0 min read message:

{% if read_time != '0' %}
  {{ read_time }}
{% else %}
  1
{% endif %} min read

And that’s all. You can put those two snippets of code in your _layouts/post.html file.

El problema de Bitcoin

2014-02-10T00:00:00+00:00

Más que el problema son los problemas. En este post intento explicar las fallas que veo en Bitcoin –y cualquier moneda virtual basada en Bitcoin– desde un punto de vista de usuario y humano.

Uso masivo, limitado

Para llegar a la masa de gente se necesita comprensión sobre “cómo funciona” la moneda. Bitcoin es complejo de entender y explicar en un 100% sin entrar en detalles técnicos. Comprender cómo funciona la criptografía con pares de claves públicas y privadas puede no ser tan sencillo de digerir para la gente común.

En pocas palabras, la complejidad aleja a la gente común, salvo que ofrezcamos facilidad de uso.

Facilidad Complejidad de uso

Existen dos puntos en conflicto: Facilidad de uso vs. Seguridad. Guardar una clave privada –un bloque de bits– a salvo puede ser una de las tareas más complejas hoy en día. Debido a que la clave debe ser generada por una máquina, siempre hay sospechas de que 1) el programa que la genera también se encarga de enviarla a “alguien más”, o 2) la máquina tenga un virus de un tercero que se encargue de robar claves.

Lo más seguro: Crear una clave privada en una computadora sin acceso a Internet, imprimirla en papel, guardar el papel como si fuera oro, quemar la computadora que usamos para generar la clave.

Lo más fácil de usar: Que un sitio al que entramos con usuario/contraseña nos mantenga nuestra la billetera por nosotros, y mediante una app en el celular podemos comprar y vender. Claro está que además de sencillo, esto es infinitamente inseguro –el dueño de la app es dueño de nuestra clave–.

Medio de ahorro consumo

Por un lado, existen casos de personas que perdieron todas sus bitcoins. Casos donde le roban a alguien su clave privada para hacer transacciones a su nombre, y al otro día –o minuto– se da cuenta que ya no tiene nada, su dinero se fue, por siempre.

Por otro lado, el precio de las bitcoins parece una montaña rusa, podes perder 25% en unos días –o ganar 10 veces–.

Al parecer tener bitcoins ahorradas por mucho tiempo no parece ser un negocio debido a la volatilidad e inseguridad. Es mejor quemarlas lo antes posible –sirve más para consumir que para ahorrar–.

Conversión a dinero real

Los billetes tienen sus ventajas: Existe una autoridad central que los emiten y respaldan. Ese papel que tenemos en la mano equivale a una fracción de metal precioso –u otros papeles– que alguien está guardando en una bóveda por nosotros. Alguien en quien todos confían.

Por otro lado, con las bitcoins la información sobre qué cantidad de dinero tiene cada billetera está distribuida en una red P2P. Nosotros no vemos nada físico, son sólo ceros y unos en un gran archivo que guarda las transacciones desde la primera hasta la última. La red se dedica a alojar y validar transacciones, por lo tanto podemos confiar en que las billeteras dicen tener la cantidad de dinero que tienen.

El problema es que no hay autoridad central que de soporte a nuestras bitcoins con otro tipo de moneda/metal. Si la red dice que mi billetera tiene 10 bitcoins, podemos asegurar que eso es válido, pero, ¿a cuántos dólares equivalen 10 bitcoins? El valor depende de la disponibilidad de convertir bitcoins en alguna otra moneda, o pagar bienes o servicios. (Por eso cada vez que cierra una “casa de cambio” de bitcoins, el valor de la moneda cae estrepitosamente.)

Legalidad de las transacciones

¿Qué pasa con todas las leyes fiscales de cada lugar del planeta? Existen transacciones que –pasado cierto monto– deben ser justificadas de algún modo, por ejemplo, para evitar prácticas de lavado de dinero. Ejemplo en Florida. Ejemplo en Rusia.

Impacto ambiental

Por último, el punto más macabro de las bitcoins es el posible impacto ambiental que presentan los servidores haciendo mining continuamente. Algunos dicen que no hay costo en las transacciones de bitcoins. Aunque a simple vista es lo que parece, la red P2P se encarga de “absorber” ese costo. Creo que si en el futuro más gente comienza a adoptar esta forma de pago, el consumo de energía puede representar un impacto ambiental considerable.

Tarea para el hogar: ¿Qué impacto ambiental tiene nuestro dinero actual? Teniendo en cuenta todo el sistema de extracción de metales, almacenamiento/seguridad, transporte, emisión de moneda, transacciones bancarias, funcionamiento de cajeros automáticos, etc.

Un no-lenguaje de programación

2014-02-05T00:00:00+00:00

¿Será la manipulación de árboles AST el futuro? En The Future of Programming, Paul Chiusano habla sobre una organización del código fuente en forma de bases de datos relacionales. En vez de editar texto, editaríamos esta base de datos –mediante alguna buena UI supongamos–. Así todo un nuevo conjunto de herramientas se hace posible, y lo que hoy nos parece complicado de implementar –por ejemplo un refactor– se podría implementar como un UPDATE a un campo de una tabla. En otras palabras, podríamos almacenar los AST en vez del texto crudo, y manipularlos directamente. Un proyecto que apunta a esto es: Lamdu.

Existe todo un mundo detrás de la manipulación del texto en la programación. Somos artesanos del texto. Y con esto no me refiero exactamente a “escritores”. Sino a la cantidad de tiempo que invertimos en cosas inútiles que no afectan al código. Por ejemplo: espacios en blanco, tamaño de tabs, cantidad de columnas en la pantalla, nuevas líneas y enters (CRLF vs CR vs LF), nivel de sangría, etc. (A veces en vez de programar, siento que estoy pintando un cuadro.)

Para empeorar la situación, las reglas deben ser acordadas entre todos los miembros del equipo, que a su vez, tienen batallas constantes dentro de sus cabezas entre lo acordado y sus preferencias personales.

¿Por qué cuando programamos no nos podemos concentrar únicamente en la lógica del programa? ¿Por qué debemos lidiar con todos estos problemas sobre caracteres que no vemos? Y el problema no es sólo en los editores de texto, se extiende a programas controladores de versiones (ej: git), websites para revisar código, herramientas para formatear el código y para buscar dentro del código (find/grep), etc. Si pudiéramos desligarnos de la representación en texto, podríamos evitar estos problemas.

La edición, navegación, presentación, comparación y control de versiones de árboles AST abre todo un nuevo mundo de opciones que hoy en día se nos escapa por estar preocupados en si un tab debe tener un ancho de 4 u 8 espacios. Por ejemplo, la búsqueda de código duplicado podría hacerse mediante búsqueda de árboles AST similares. Un nuevo tipo de refactor podría buscar estos árboles y crear métodos, funciones o clases que los agrupen automáticamente. Ya no estaríamos manipulando texto, sino “pedazos de lógica”. ¿Qué pasaría si convirtiésemos todo el código de GitHub en árboles AST y pusiéramos a andar este refactor semántico? Tal vez podríamos unir muchos cuerpos de funciones en micro-librerías que se reutilizarían entre los proyectos más disímiles.

En fin, por ahora veo lejos la posibilidad de reemplazar los editores de texto. A pesar de todos los problemas que presentan, la entrada y navegación de caracteres es demasiado ágil. También sospecho que existen elementos psicológicos e históricos guardados en nuestros cerebros: hemos evolucionando y crecido leyendo y escribiendo, es “a lo que estamos acostumbrados”.

Bonus: Esto me trae a la cabeza otra pregunta, ¿los árabes encontrarán fácil de programar en lenguajes de programación que se escriben de izquierda-a-derecha? Existen lenguajes que no están basados en el inglés, y entre ellos Qalb, un lenguaje funcional parecido a Scheme pero que se programa totalmente en árabe (de derecha-a-izquierda).

Escalera a la privacidad

2013-11-22T00:00:00+00:00

Algunos secretos sobre cómo escalar permisos en las aplicaciones móviles (o cómo hacerle perder toda la privacidad al usuario).

Primeros pasos

Hacemos una aplicación que pida muy pocos permisos.
De alguna manera debemos conocer cuánto tiempo el usuario pasa en nuestra aplicación (ej: usando peticiones HTTP a un servidor nuestro con todos los datos del usuario, la máxima información que pudimos obtener con los permisos iniciales).
Luego, cuando sabemos que el usuario depende lo suficiente de nuestra aplicación (ej: tiene muchas conexiones/comunicación con otras personas), sacamos una actualización.
La actualización es una nueva versión de nuestra aplicación (tal vez con cero beneficio) que requiere más permisos que la versión original.
Finalmente el usuario cede cada vez más y más privacidad (en realidad nunca estará seguro de cuánto ofreció).

Esto son los baby steps de una aplicación que quiere obtener cada vez más datos del usuario. Lo importante en realidad no es tener mucha información, sino algo de información, y principalmente, la identidad del teléfono.

Ahora, ¿qué hacemos? tal vez existan otras personas que quieran comprar nuestra información…

Todas las escaleras confluyen a un punto, ¿el cielo?

Ahora imaginemos que somos dueños de una empresa que compra información de usuarios. Lo único que necesitamos es contactar a desarrolladores de aplicaciones móviles, y ofrecerles algo de dinero por su bases de datos. Lo interesante aquí no es la cantidad de información que tiene cada uno de estos pequeños desarrolladores, lo importante es que nosotros podemos reconstruir mucha más información haciendo corresponder las identidades de los teléfonos.

Por ejemplo, si una aplicación pide la identidad del teléfono y GPS, sabemos que ese desarrollador puede darnos las coordenadas por donde anduvo una persona. Si otra aplicación pide la identidad del teléfono, el propietario y acceso a fotos, sabemos que ese otro desarrollador puede darnos fotos de determinado teléfono, y el nombre del propietario del celular.

Si unimos los datos de ambos desarrolladores (haciendo coincidir la “identidad del teléfono”), ya tenemos nombre de la persona, ubicaciones por donde caminó, y su biblioteca de fotos. Y esto comprando sólo los datos de dos aplicaciones.

Cabe destacar que lo expuesto aquí debería ser considerado una de las peores prácticas en el desarrollo de software. Tal vez la menos ética, y tal vez debería estar penado por ley. Por lo menos hasta que se encuentre un caso en contra de esos check-boxes “Juro por Dios y la Patria que he leído la licencia”. Es probable que algunos lectores, al comenzar el artículo, hayan dicho “es verdad, ¡yo también puedo hacerlo!”, bueno, pues para ser sincero, sí, también puedes hacerlo. Hasta que se termine la fiesta. (O hasta que la fiesta nos termine matando a todos.)

Contratos

2013-11-09T00:00:00+00:00

Introducción

Este post es el desarrollo de una simple idea de un tweet que lancé hace un mes atrás:

I've to write a post about this: with dynamic typing you get static code, with static typing you get dynamic code
— David Capello (@davidcapello) October 15, 2013

Traducido, eso dice algo así:

Con el tipado dinámico obtienes código estático y con tipado estático obtienes código dinámico.

¿Qué quiero decir con esto? El código con tipado estático es código que busca un contrato bien definido, una forma de comunicación entre cliente y servidor. Puede ser una interfaz, o la signatura de una función, o el tipo de una variable, o un API completo. Todos son contratos.

Lo bueno de estos contratos es que están ahí, definiendo explícitamente lo que debe cumplir un cliente. Los compiladores chequean que todos estos contratos (tipos, cantidad de argumentos, valores de retorno) se cumplan correctamente, y mientras más meta-información definamos en los contratos mejor será el chequeo estático (en tiempo de compilación).

En contrapartida, sin estos contratos, como ocurre con el tipado dinámico y el duck typing, estamos al horno. Perdemos el compilador, nadie chequea nada, y sólo en runtime podemos ver cómo falla estrepitosamente nuestro programa si el contrato no se cumple. Es una forma de programar “a lo compilador”, en vez de programadores nos convertimos en compiladores (¿comprogradores?).

Al no tener compilador, tomamos su puesto y empezamos a usar el depurador como compilador, o en el mejor de lo casos, nuestros test automatizados pasan a ser el compilador.

Ejemplo

Vamos a ver un ejemplo muy sencillo en pseudocódigo. La siguiente es una interfaz muy simple con un método, pero el método tiene dos argumentos y cada argumento un tipo (todo esto es información útil para los chequeos que hace el compilador):

inteface Logger {
  void log(int level, String message);
}

Existe sólo una forma de usar la interfaz. Llamando el método Logger.log() con dos argumentos, el primero es un entero y el segundo una cadena de caracteres. No existe otra forma posible de usar la interfaz. Podemos ver un ejemplo de cliente:

void ProcesarTareas(Logger logger) {
  logger.log(0, "Comenzar a procesar tareas");

  while (tareas.pendientes()) {
    Tarea tarea = tareas.proxima();

    switch (tarea.hacer()) {
      case Exito:       logger.log(0, "Tarea con éxito");       break;
      case Advertencia: logger.log(1, "Tarea con advertencia"); break;
      case Error:       logger.log(2, "Tarea con error");       break;
    }
  }

  logger.log(0, "Finalizar");
}

Todas las llamadas a Logger.log() son iguales. Un entero y una cadena de caracteres. Si erramos en el contrato obtenemos un error de compilación. ¡Gracias compilador por ofrecernos tanto!

También podemos notar que a simple vista el argumento level del método Logger.log() indica el nivel de severidad del error, donde cero (0) es éxito o mensajes de información, uno (1) es una advertencia, y dos (2) es un error. Esta información está oculta en la interfaz, y estaría bueno hacerla explícita (modificando la interfaz). Imaginemos que cambiamos Logger a algo como esto:

interface Logger {
  void info(String message);
  void warn(String message);
  void error(String message);
}

Al compilar la función ProcesarTareas() de arriba obtendríamos cinco errores. Lo bueno es que los errores se detectan en tiempo de compilación, no necesitamos ni ejecutar el programa para saber que estamos fallando. Podemos saber las líneas exactas donde están los errores y cuáles son nuestras faltas en el incumplimiento del contrato. Una versión corregida del programa podría ser:

void ProcesarTareas(Logger logger) {
  logger.info("Comenzar a procesar tareas");

  while (tareas.pendientes()) {
    Tarea tarea = tareas.proxima();

    switch (tarea.hacer()) {
      case Exito:       logger.info("Tarea con éxito");       break;
      case Advertencia: logger.warn("Tarea con advertencia"); break;
      case Error:       logger.error("Tarea con error");      break;
    }
  }

  logger.info("Finalizar");
}

En un rato mejoramos el diseño del programa agregando mayor información visible (qué queremos loguear, info, warning o error), y eliminamos constantes duplicadas sin significado por todo el programa (los números 0, 1 y 2). Lo bueno es que esto lo hicimos sin ejecutar el programa. Sin test cases. Sin tiempo de ejecución.

Si magnificamos este simple ejemplo a millones de líneas de código, con cientos de módulos que se conectan entre sí, podemos ver una ventaja grandísima en el uso de estos contratos entre módulos para poder hacer refactoring a gran escala.

Conclusión

Las interfaces definen contratos, pero estos contratos no son fijos, pueden cambiar a lo largo del tiempo (y todos los programadores saben que van a cambiar). Por suerte el compilador va a seguir chequeando por nosotros el cumplimiento de los contratos hasta el infinito. En definitiva, el tipado estático favorece el refactoring, porque permite que herramientas extras (como el compilador) nos ayuden en la tarea.

El tipado estático promueve el código dinámico.

Por otro lado, el tipado dinámico no nos ofrece ninguna mano para modificar el código, sino todo lo contrario: promueve el código estático. Si tocamos las interfaces no tenemos más que ejecutar todo el programa nuevamente para chequear que no rompimos nada. En el mejor de los casos, vamos a tener pruebas de cobertura, pero eso raramente suele ocurrir. En el peor de los casos, no vamos a tener ningún test, y tendremos que ejecutar toda la funcionalidad afectada de nuestro sistema desde cero.

Mi consejo personal: Los lenguajes de tipado dinámico no ayudan a crear grandes sistemas mantenibles/modificables/dinámicos. Al principio pueden parecer divertidos, interesantes, y de alta productividad, pero sólo si estamos haciendo programas de juguete. Cuando lleguemos a mayores escalas, el tipado dinámico es el peor enemigo con el que nos podemos encontrar. El peor.

Arriesgarse

2013-07-27T00:00:00+00:00

La situación actual, o el state-of-the-art, de la propaganda política –al menos aquí en Argentina– es una foto del político con su mayor cara de imbécil, sumado a una frase digna de ser escrita –y tachada– en la puerta de un baño público.

Así es, los políticos no se arriesgan por nada. La mínima transmisión de una idea significa ubicarse en un lugar. Decir “estas son mis ideas, no aquellas, yo soy esto” es colocarse en un lugar. Una posición incómoda, que trae como consecuencia perder los votos que no están de acuerdo conmigo. Al fin de cuentas, no elegir ninguna posición, resulta ser la mejor posición para un político sin ideas.

La especulación perpetua sobre posibles votos ganados y perdidos hace que los políticos estén “ahí”. Muertos. Estampados en un cartel. Clavados en una foto. Apretados en sus trajes. Acompañados con un eslogan berreta, su único acompañante leal.

Lo más interesante de esto, no es el mensaje nulo que transmite la campaña. Lo que me resulta realmente inaudito es que esa gente luego reciba voto alguno. En una legislación regida por el sentido común, debería estar penado por ley –multado con 5 a 10 años de servicio comunitario– el no transmitir ninguna posición política, ninguna idea, ningún mensaje, y sólo generar ruido en el ambiente con un cartel inservible que crea la más penosa polución visual.

UI de un instalador

2013-02-28T00:00:00+00:00

Intenté instalar Fedora 18. Estos son los problemas en la primera pantalla de la instalación. (Demás está decir que tuve ganas de dejar la instalación acá mismo.)

La primera pantalla (ver screenshot) muestra la selección de lenguaje. Una lista con todos los lenguajes, y por defecto seleccionado inglés (fair enough). Selecciono español con el mouse. No hay problemas por ahora.

Debajo de la lista hay un texto box y un check box. No entiendo muy bien para qué sirve el text box, y el checkbox dice “Fijar la distribución de teclado predeterminado para el idioma seleccionado.” (mensaje totalmente incomprensible). Generalmente cuando instalo un sistema operativo pienso “seguro voy a tener que configurar el teclado”. Por experiencia previa en Windows siempre hay dos cosas que configurar: idioma y teclado, después lo demás viene cocinado (o por lo menos es lo mínimo que espero).

Escribo algo en el text box y resulta ser que actúa como filtro del lenguaje, como para buscar el lenguaje según escribimos. Esto tiene tres fallas (sí, tres fallas en una misma pantalla):

El text box sirve para filtrar una lista que está encima de él, no por debajo, ¿para qué filtrar una lista que ya seleccioné con el mouse? generalmente los campos de búsqueda muestran los resultados abajo, no arriba, inclusive una lupa dentro del text box no vendría nada mal, por lo menos para saber que sirve para buscar,
Al escribir el lenguaje, puse “spanish”, pero no aparece nada, hay que escribir “español” (extraño, ya que en el listado se muestra una columna con el nombre del idioma en inglés),
Al intentar escribir “español” aparece “espa;ol”, porque todavía no pude configurar el teclado.

En conclusión: tengo un text box que sirve para filtrar según el nombre del idioma, pero necesito colocar caracteres unicode que todavía no puedo ingresar porque no configuré el teclado, o sea, el text box no sirve absolutamente para nada. ¡¿Quién demonios diseñó esta pantalla?!

Y todavía falta el check box, que dicho sea de paso lo presioné pensando que servía para configurar el teclado. Pero después de clickear en “Continuar” comprendí el mensaje: “Fijar el teclado predeterminado”. “Fijar predeterminado”. “Set/use default”. Entonces dije “Ah claro no, no, no, yo quiero especificar mi teclado, no quiero uno por defecto”, y luego no pude volver a la pantalla anterior (no hay botón “Volver”). Tuve que salir de la instalación y comenzar de nuevo.

A veces me preguntan “¿qué tiene de malo Linux?”. Use Debian por más de 5 años (por línea de comandos, porque el GUI nunca me terminó de cerrar), y ya hace muchísimo tiempo volví a Windows, ¿por qué? por esta mentalidad endemoniada y retorcida que está detrás del diseño de cada simple pantalla, ventana, diálogo, botón.

Si sos un programador, el entorno de Linux te puede beneficiar porque tiene las herramientas justas para programar, de fácil acceso e instalación, scripts, etc. Pero al tiempo que empieces a usar la interfaz gráfica, te va a dañar el cerebro. Vas a comenzar a creer que esas pantallas están bien diseñadas, y por lo tanto, terminarás siendo un peor programador.

¿Capacidad ilimitada o brain overflow?

2012-12-02T00:00:00+00:00

¿Qué nos ofrece Internet? ¿Qué le podemos dar? ¿Qué somos? ¿Somos lo que consumimos? Y si hoy hay un desborde de información, ¿no estaremos engordando de información? ¿no necesitamos ponernos a dieta?

Antes de la aparición de las redes sociales era un poco más complicado publicar contenido en Internet, lo cual hacía que haya menos vías de comunicación, menos canales de información, menos distracciones, y menos gente publicando material. Ahora, el “problema” es que cualquiera puede publicar –y republicar– lo que sea. No sólo tenemos un exceso de información, sino que tenemos duplicación de información en exceso.

¿Qué pasa cuando vemos una imagen? ¿O cuando escuchamos una música? ¿O leemos algo? ¿Dónde van a parar dentro nuestro? Internamente, no tenemos idea de cómo se almacenan esas imágenes en el cerebro, pero sí podemos afirmar que: si vemos algo nuevamente, con seguridad somos capaces de aseverar que ya lo vimos con anterioridad. Estamos seguros que esas imágenes están “guardadas” en nuestra mente. No podemos recordarlas con exactitud –o tal vez no recordamos nada– pero cuando la vemos nuevamente algo se activa, algo dentro nuestro que nos dice “esto ya lo vi”.

Y aquí introduzco la parte más interesante: todo esto que nosotros vemos, esta marea de información que nos inunda, millones de imágenes que día a día siguen entrando en nuestras cabezas, ¿realmente nos sobrepasa? ¿o tenemos una capacidad ilimitada de decir “esto ya lo vi”?

Y es una de las dos respuestas: o tenemos una capacidad infinita de recordar cosas, o nuestro cerebro, llegado su momento de la vida, no da más, sufre un brain overflow¹, donde: 1) lo que vemos con nuestros ojos ya no entra en la cabeza –no asimilamos más–, o 2) el cerebro va descartando –olvidando– las imágenes más antiguas. Claro que existe una tercera opción: 3) nos quedamos inmediatamente ciegos y sordos.

Haciendo alusión a un stack overflow, que de manera simplificada es cuando una aplicación corriendo en una computadora se queda sin memoria para continuar, y la única resolución posible es matarla. ↩

Eternos

2012-12-01T00:00:00+00:00

“¿Dónde puedo publicarlo?”, “Necesito un blog”, “Necesito otro blog”. No, no necesito ningún blog. O al menos, no necesito otro. A veces pienso que el contenido que genero va a mejorar por cambiar de lugar. La realidad me demuestra que esto nunca sucede.

La mayoría de gente no necesita un blog. La mayoría de gente no tiene nada importante para compartir, o que decirnos. Yo no tengo nada importante para ofrecerles. Y aún así, escribo esto. O mejor dicho, lo estoy escribiendo –sí, con papel y lápiz, o papel y microfibra en este caso–.

Y mientras escribo, pienso, “¿qué pasaría si todos los servidores se apagaran? ¿qué perderíamos? ¿qué parte como sociedad nos faltaría? ¿qué sociedad pasaríamos a ser? ¿o a volver a ser? El impacto no sería tanto. Sería más a nivel personal, si es que teníamos cosas “ahí afuera” en Internet. Y cuando digo “cosas” me refiero a material que nos costó esfuerzo creativo realizarlo.

Por eso, estoy pensando que sería muy triste –para uno– perder su blog. Perder todo eso que escribió. A nadie más le importaría. Pero sí, cada una de esas almas perdería un poco de sí mismas, de eso que crearon y ahora no está más. Para la gente que nunca creó, la angustia sería nula. Como hacer zapping en el TV, o pasar a otro libro. “¿Ahora qué dan?” se escucharía a continuación del apagón.

Tal vez los servidores nunca exploten. Tal vez la nube llegó para quedarse. Igual, el mejor consejo que se me ocurre es: si realmente tienes algo que vale la pena compartir, escríbelo, dibújalo, grábalo, hazlo partitura. Porque en el futuro, es muy probable que sea lo único que tengamos para recordarnos que fuimos jóvenes, y soñamos, y un día nos sentamos, y escribimos en una hoja, pensando que seríamos eternos.

Aclaración: Esto fue escrito bajo el título “Nada que decir”, en papel, el día 14 de noviembre del 2012 a las 19:30 hs.

Ayer leí esto lo cual va un poco con este estilo de escribir en papel.

Excepciones desde un destructor

2012-08-20T00:00:00+00:00

Hace tres días, en C++Next publicaron un artículo sobre tirar excepciones en los destructores. Hasta el mismo Herb Sutter anda por los comentarios.

Para los que no saben, los destructores no deberían tirar excepciones. Y si la clase se usa en los contenedores de la STL, las excepciones en los destructores están completamente prohibidas. Por lo tanto, ya existe un consenso general en donde tirar excepciones desde un destructor es sólo una fuente de problemas.

Así, ¿qué trae de nuevo el artículo? Bueno, aunque el artículo es interesante y lo recomiendo leer, básicamente no llega a nada. A tener en cuenta:

Si tiramos una excepciones en un destructor, la excepción se propaga como en cualquier otra función. Se siguen llamando los destructores de los subobjetos (variables miembro) y se libera la memoria utilizada por el objeto. La excepción se propaga hasta algún catch. Aquí todo funciona bien, no quedan objetos zombies ni memory leaks.
Cuando ocurre una excepción, se destruyen los objetos que estaban en su ámbito y en todos los ámbitos hasta llegar al catch (este proceso se llama stack unwinding). ¿Qué ocurre si en medio de esos objetos que se están destruyendo ocurre otra excepción? Veamos el siguiente ejemplo:
```
class A { ... }

class B {
public:
  ~B() { throw 2; }
}

int main() {
  try {
    A a;
    B b;
    throw 1;   // Comienza el stack unwinding, los destructores
               // se llamarán en orden: ~B y luego ~A, pero ~B tira
               // otra excepción
  }
  catch (...) { }
}
```
La pregunta prevalece: ¿qué pasa en este caso donde ~B tira una excepción en su destrucción? ¿qué excepción continúa? ¿la primera o la segunda que generó el destructor?

El artículo propone pensar sobre este tema y que tal vez podríamos descartar la segunda excepción. El estándar propone resolverlo con un terminate (ver §15.2 párrafo 3). Sencillamente, no se puede tirar otra excepción en medio del stack unwinding.

De los comentarios de Herb Sutter podemos sacar varios puntos muy concisos:

Una excepción es un error dentro de una función, y un error ocurre cuando las postcondiciones de la función no se pueden cumplir.
La postcondición de un destructor es que el objeto estará destruido al salir del destructor.
La vida del objeto termina al momento que entramos en el destructor, es decir, la postcondición se cumplirá de cualquier modo. No podemos -en medio de un destructor- decir “eh, ok, esperen, este objeto no se puede destruir, cancelen todo, vayan para atrás”. Esto no es posible, al salir del destructor, la memoria ya será liberada.
Entonces, ¿por qué no tirar excepciones en un destructor? Porque no existe posibilidad de reintento o cancelación de la operación. Una vez que entramos al destructor el objeto será liberado de la memoria de cualquier modo.
Podemos llegar a usar una función b.close() en el caso que necesitemos atrapar excepciones en la liberación de recursos. El destructor podría simplemente llamar a this->close() y hacer un catch de todas las excepciones para evitar que se propaguen.
Él aclara que hubiera preferido destructores con noexcept en C++11: Un modificador de funciones que especifica que el compilador debe chequear que al destructor realmente no se le escapan excepciones.

Para divertirse un poco más con todo esto, recomiendo leer:

Ítem 16 “Writing Exception-Safe Code” en Exceptional C++ de Herb Sutter.
Ítem 51 “Destructors, deallocation, and swap never fail” en C++ Coding Standards de Herb Sutter y Andrei Alexandrescu.

Sobre el tiempo

2012-08-02T00:00:00+00:00

Muchas veces decimos “perdí el tiempo en tal cosa” o “invertí el tiempo en tal otra”. Estas expresiones dan a entender dos puntos: 1) que el tiempo tiene un valor, y 2) que nuestra vida, a medida que transcurre, va consumiendo ese tiempo, y vamos devaluándolo. Es como que, si pasamos tiempo fuera de algo “constructivo” (a nivel económico), le hacemos daño o quitamos valor a alguien -o a algo- superior a nosotros.

Esa es la visión comercial del tiempo, y es la visión que la sociedad actual tiene acerca del tiempo. Creo que deberíamos comenzar a “invertir” más tiempo en pensar sobre el tiempo mismo.

Personalmente, sospecho que el tiempo no se pierde, ni se gana, ni se invierte, ni desaparece. El tiempo simplemente pasa, y nosotros estamos en algún lugar, sencillamente pasando el tiempo. No hay nada ni nadie superior a quien le estemos fallando si usamos nuestro tiempo en cosas que no son vistas como “productivas” por los ojos de la sociedad actual.

Ver una película, escuchar una música, estar tirado en la cama, usar Internet, ver televisión, escuchar la radio, leer una novela, poesía, jugar, o sentarse en la vereda, no es una pérdida de tiempo. Es una “inversión” del tiempo en nosotros mismos, y ese tiempo simplemente debe pasar, para llenarnos.

Tal vez no nos damos cuenta que el tiempo es necesario que lo pasemos. Que no existe inversión alguna, ni pérdida. Sólo es eso, pasar el tiempo.

La gran unificación de la programación

2012-07-18T00:00:00+00:00

Imaginemos un mundo donde no exista código duplicado, nada. Sólo un gran repositorio con “pedazos de lógica” Eso significa que la más insignificante porción de lógica, por ejemplo, calcular el mínimo entre dos números, existe una única vez codificada en un lenguaje de programación universal al cual todos podemos acceder. Ejemplo en pseudo-código:

importá "el código para calcular un mínimo entre dos valores"
         y dejalo en una función que se llame "min"
definí la variable a = min(3, 2)
devolvé a

Así nunca nadie debería codificar nunca jamás cómo se calcula el mínimo de dos valores. Inclusive nuestro pequeño programa se podría dejar en el repositorio como “el calculador del mínimo entre 3 y 2”. (Completamente inútil, pero podríamos dejarlo, e inclusive, debería estar ahí, porque yo ya lo escribí aquí.)

¿Cuál es el problema? Las interfaces. Por ejemplo ¿Qué requisito necesita nuestro “código para calcular un mínimo”? ¿Usará el operador < para comparar los argumentos? ¿O el >? ¿Y si usamos nuestro propio tipo de dato? ¿Podemos calcular el mínimo entre dos archivos, o documentos, o personas, o naranjas? ¿Qué devuelve min, una copia de los argumentos o una referencia? Si devuelve una copia ¿cómo crea la copia? ¿qué es una referencia?

Los templates de C++ resuelven muchas de estas preguntas (y los “conceptos” intentaban ser esta especificación de esta interfaz). Pero C++ sólo anda en C++. Lo que aquí me pongo a imaginar es un lenguaje universal, que puede ser importado y convertido a cualquier otro lenguaje y luego interpretado o compilado a lo que sea. Es decir, un repositorio de pseudo-código para resolver cualquier tipo de cuestiones.

Ejemplos: Quiero un calculador de la sucesión de Fibonacci, PUM! ahí lo tenes para Fortran. Quiero una implementación de un radio button para Java, PAM! Ahí lo tenes. Quiero un Tetris andando con highscore y todo en… sí, en C mandamelo, SALE CON FRITAS!

¿Existirá algún día la cero duplicación de código?

Publicado originalmente aquí.

La utopía de Nietzsche

2012-07-07T00:00:00+00:00

Hace ya unos años atrás leía el siguiente aforismo de Friedrich Nietzsche de Humano, demasiado humano:

462.- Mí utopía. En un mejor orden social, habrán de atribuirse las tareas pesadas y los trabajos arduos de la vida a aquél que menos sufra, es decir, al más insensible, e ir subiendo así gradualmente hasta el hombre más sensible a las formas más nobles y sublimes de dolor, a quien una vida aliviada al extremo no impedirá, entonces, que siga sufriendo.

Un mundo donde todos sufren por igual.

Tipos para todo

2012-07-03T00:00:00+00:00

Consejos para desarrolladores: Si un programa tiene que manejar una entidad, por más mínima que sea, no subestimes el poder que tiene crear un tipo de dato para esa entidad. Por ejemplo: un DNI (Documento Nacional de Identidad) se pueden representar con un string o un entero de 64 bits, pero tal vez sea mejor usar un tipo de dato propio (ej: una clase); una coordenada X podría ser un entero, o realmente una clase CoordenadaX (o un simple typedef de C++ como para comenzar).

¿Ventajas? En lenguajes de tipado estático, podemos obtener muchísimas validaciones en tiempo de compilación. Por ejemplo, validaciones del tipo “aquí espero un DNI, no espero cualquier entero”; o validaciones de unidades como “aquí espero gramos, no un double cualquiera”.

No me extrañaría ver en un futuro que Java y C# adopten los sufijos personalizables de C++11. Estos sufijos permiten hacer más sencillo definir literales de nuestro propios tipos. Ejemplos:

DNI algunDni = 14304890_dni;
CoordenadaX posicion = 32_x;
Width ancho = 320_width;
Gramos peso = 10_kg + 500_g;
Bits datosCrudos = 10010_bits;

Sí, todas son posibles expresiones de C++11 definiendo los tipos de datos correctos y sobrecargando el operator"". (Vale la pena ver la implementación del _bits en esta respuesta de StackOverflow.)

Tools for web development

2012-06-23T00:00:00+00:00

This is a set of tools, projects, libraries, frameworks, etc. to create web applications that I recommend you to check out. I’ll be modifying this list if I found more and more libraries. Feel free to recommend one in the comments section below.

Application logic at client side

jQuery: jQuery gives you an easy and portable way to query for DOM elements, create AJAX requests, create animation, etc. It’s like the de facto framework to extend JavaScript. There are others like script.aculo.us, mootools, etc.
Handlebars.js: Templating engine at client side. You can render JSON objects to HTML.

Style, HTML organization, and UI helpers

Twitter Bootstrap: All your website style should be based on this. Forget your way to layout HTML elements and CSS style, this is the right way to do it.
less: A dynamic stylesheet language. Useful to avoid duplicating colors/styles all over a CSS file.
jQuery UI: UI widgets and extensions to build really interactive pages with JavaScript and jQuery.
jQuery UI Layout: A way to organize your page like a desktop app with docking panes. Example
fancybox: A library to show screenshots with fancy transitions (depends on jQuery).

Data visualization

SlickGrid: A super customizable open source JavaScript grid to display a lot of data. You’ll need JavaScript knowledge to customize this grid, but it feels really good when you found a bug and you can fix it (also you can send pull requests to the author). Grooveshark uses this grid.
dygraphs: Create zoomable charts.

WebFonts & Icons

The League of Moveable Type: Open web fonts.
Font Awesome: A web font where each glyph is an icon.
Black & White Icons

Entrando a otro mundo

2012-05-09T00:00:00+00:00

Forward declarations de enumerados

2012-04-10T00:00:00+00:00

Continuando las discusiones con los forward declarations, podemos destacar un pequeño tipo de dato que nunca tuvo esta capacidad, por lo menos no hasta C++11: Los _enum_erados.

Los enum siempre fueron un problema en la definición de APIs. Actualmente, si queremos usar un enumerado en una función o como miembro de una clase, debemos tener su definición completa con anterioridad, inclusive el listado de valores posibles que puede tomar el enumerado.

Esto es muy sencillo de ver en el siguiente ejemplo. Imaginemos que nuestro programa se comunica con el usuario por medio de una GUI (ventanas, botones, controles de todo tipo). Cada control puede recibir mensajes desde el sistema operativo, por ejemplo, si el usuario clickea un botón, tiene sentido que recibamos el mensaje BotonMousePresionado.

Aquí un enumerado con el listado de posibles mensajes que podemos recibir (imaginemos esto en un archivo tipo_mensaje.h):

enum TipoMensaje {
  AbrirVentana,
  CerrarVentana,
  BotonMousePresionado,
  TeclaPresionada
};

En el caso de que declaremos una clase que utiliza el enumerado, necesitamos de la definición de TipoMensaje completa:

#include "tipo_mensaje.h"   // Necesitamos la definición del enumerado

class Mensaje {
  TipoMensaje mensaje;
public:
  // ...
};

Inclusive aunque no utilicemos los valores posibles del enumerado, no hay forma de desacoplarlo. Esto se debe a que según el estándar de C++, la cantidad de memoria usada por un enumerado depende de la implementación del compilador y del rango de valores permitidos del enumerado. Ejemplo: Un compilador podría decidir usar un char en vez de un int para representar nuestro TipoMensaje.

¿Cuál es la desventaja?
Debido a que el compilador decide, según reglas internas y los valores posibles del enum, qué tipo de dato usar para representarlo, cada vez que agreguemos un nuevo valor al enumerado debemos recompilar todos los archivos que lo estaban referenciando.

¿Cómo podemos solucionarlo?
C++11 introduce el concepto de los “enumerados fuertemente tipados” (strongly typed enumerations). Con lo cual podemos decidir qué tamaño específico tiene el enumerado.

Si conocemos con anterioridad cuántos valores queremos codificar en nuestro enum, podemos especificar la cantidad de memoria requerida por el mismo. Podemos definir un enumerado que ocupe sólo 8 bits:

enum TipoMensaje : char {
  AbrirVentana,
  CerrarVentana,
  BotonMousePresionado,
  TeclaPresionada
}

Y si necesitamos referenciarlo:

enum TipoMensaje : char;    // Forward declaration

class Mensaje {
  TipoMensaje mensaje;
public:
  // ...
};

¿Por qué se llaman “enumerados fuertemente tipados”?
Ese es otro tema que lo dejo para un próximo post.

Referencias: N2347 (pdf)

Reformat XML on Emacs

2012-04-09T00:00:00+00:00

You can reformat XML code adding the following code in your .emacs:

(require 'sgml-mode)

(defun reformat-xml ()
  (interactive)
  (save-excursion
    (sgml-pretty-print (point-min) (point-max))
    (indent-region (point-min) (point-max))))

And executing reformat-xml in your XML buffer then.

Paréntesis en una URL

2012-04-08T00:00:00+00:00

Ya van dos veces que tengo que buscar cómo se codifican los paréntesis en una URL. Aquí dejo esto como futura referencia:

El paréntesis de apertura ( se puede escribir como %28
El paréntesis de cierre ) se puede escribir %29

Ejemplo: Un link a http://en.wikipedia.org/wiki/Tee_(command) se puede escribir como http://en.wikipedia.org/wiki/Tee_%28command%29.

Game concepts

2012-04-05T00:00:00+00:00

These are several (maybe unimplementable) game concepts that I’ll be releasing in my Twitter account and adding them here frequently:

Avoid to bite your tongue. tweet
Social Network Tycoon, you’ve to create and maintain your own social network, destroying the competition. tweet
Prepare as many mates as you can before it became washed out. tweet
Drink as much beer as you can without getting drunk. tweet
You are a book and you must find your writer… because you’ve a typo. tweet

Una cosa por vez

2012-04-04T00:00:00+00:00

Hoy leí el siguiente artículo: The Magic of Doing One Thing at a Time (La Magia de Hacer Una Cosa a la Vez). Más allá de los consejos específicos para un manager o individuos en la empresa, quiero resumir los puntos importantes en general para cualquier ser humano.

Prácticamente, si te sentis abrumado por millones de tareas en el trabajo e información que te llega de todos lados, podes tomar las siguientes estrategias para aumentar tu productividad, o mejor dicho, volverla a su estado natural antes de que este mundo enfermo llegara:

No juegues a la multi-tarea. No hagas malabares con todo. Dedicate a resolver una tarea por vez y bien.
Pequeños tiempos muertos también ayuda. No intentes “rellenar” esos tiempos haciendo otras pequeñas tareas.
Si tenes un teléfono “inteligente”, apagalo el mayor tiempo posible (o quemalo y comprate un celular normal).
No esperes respuesta inmediata de todos. Así tampoco interrumpís el trabajo de los demás.
Hace la cosa más importante al inicio de la mañana, a la primera hora (sin interrupciones ni distracciones).

Lenguaje

2012-03-23T00:00:00+00:00

¿Cómo elijo que una página este en inglés o español?

Este sitio contiene páginas que están en español y otras que están en inglés. Generalmente no podrá encontrar la misma página traducida en ambos lenguajes. Y en esta etapa de mi vida, muy difícilmente me dedicaré a traducir todo lo que escribo.

Dependiendo de lo que quiero transmitir, una página estará en un lenguaje u otro. Si quiero publicar una aplicación o un juego, probablemente lo haga en inglés. Si en cambio quiero transmitir una idea, lo haré en mi lengua materna, español.

¿Por qué?

Prefiero no traducir nada. No soy tan bueno escribiendo inglés como me gustaría y todavía tengo que aprender a escribir en español.

Si vale la pena transmitir una idea compleja correctamente, utilizaré español, en caso contrario, utilizaré inglés. Inclusive, le recomiendo hacer lo mismo. Se disfruta más escribiendo y leyendo en la lengua de uno antes que en la ajena, es más sencillo expresar ideas y es probable que contenga menos errores.

Y como punto adicional: prefiero comunicarme y discutir con gente que entienda mi lengua.

iosfwd

2012-02-24T00:00:00+00:00

La librería estándar de C++ ofrece un archivo de cabecera de forward declarations de las clases de entrada y salida a flujos de bytes (iostreams):

#include <iosfwd>

De esta forma podemos utilizar los tipos ostream, istream, etc. sin necesidad de traer la definición de todas las clases de entrada y salida. Generalmente deberíamos utilizar el <iosfwd> en nuestro .h cuando no hagamos un mayor uso que sólo referenciarlas. Un ejemplo:

#ifndef EMPLEADO_IO_H
#define EMPLEADO_IO_H

#include <iosfwd> // forward declaration de ostream

class Empleado;    // forward declaration de nuestro tipo

// Aquí no necesitamos conocer el tamaño ni de Empleado,
// ni de ostream, podemos compilar sólo con sus forward
// declarations.
void write_empleado_en_formato_binario(const Empleado&, ostream&);

#endif

Regla: Siempre intenta usar las forward declarations antes que incluir los archivos de cabecera que definen las clases, los cuales suelen mostrar detalles de implementación que son propensos a cambiar. Siguiendo esta regla mejoraremos el tiempo de compilación y la cantidad de archivos a compilar al realizar una modificación en un .h.

Para más información, ver la sección 27.3 Forward declarations [iostream.forward] del último borrador público del estándar de C++

Año nuevo

2011-12-23T00:00:00+00:00

Bueno, este año fue poco productivo en este blog. El próximo no prometo mucho más, pero espero mejorar. Dejo un par de links que agregué en la sidebar:

Pre-defined C/C++ Compiler Macros: Si alguna vez tenemos que detectar la versión de un compilador o en qué plataformas estamos, estas macros pueden ayudarnos a escribir código portable.
C++ Reference Wiki: Una wiki con referencia sobre C++ y C++11

Los próximos años pueden llegar a ser los mejores años de C++. Con clang avanzando sobre gcc, es probable que aparezcan herramientas muy importantes para ayudar a programar en C++. Aquí les dejo un video:

¡Feliz año nuevo!

Ecos de la nada

2011-12-12T00:00:00+00:00

Como el recuerdo melancólico
de un amor que nunca fue,
los ecos retumban.
Y el sonido percibido,
es un silencio atroz.

Una sociedad que no fue

2011-11-30T00:00:00+00:00

No existe el dinero. No existen ricos, ni pobres. Todos trabajan, aprenden y juegan. Todos ayudan a todos. Algunos trabajan en cosas que les gusta. Otros trabajan obligados realizando tareas que nadie desea. No existen los sueldos. Se comercia con tiempo. A peores trabajos mayor el tiempo para aprender y jugar. Cualquiera puede escribir, componer, leer, escuchar, o ver una película. Todos pueden cumplir sus sueños, pero un tiempo lo tenes que donar.

No existe la publicidad, ni dos productos que sirvan para el mismo fin. Los bienes materiales sirven sólo para lo que fueron creados, con el diseño que produzca el menor impacto ambiental. La comida es la mejor para la salud. Se consume todo lo que se fabrica. Se fabrica sólo lo que se necesita.

Código C++ moderno

2011-09-21T00:00:00+00:00

Una excelente charla de Herb Sutter (en inglés) introduciendo algunas de las novedades del nuevo estándar C++11 y sobre cómo escribir código en C++ aprovechando todo el conocimiento acumulado en estos años (si nunca leíste C++ Coding Standards de Herb Sutter y Andrei Alexandrescu, compralo):

http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-835T

Los puntos tratados que no podes dejar pasar por alto:

El nuevo significado de la palabra auto para inferir tipos automáticamente.
La nueva sintaxis de lambdas para definir functors en línea y usarlos en algoritmos estándares (ej: for_each()).
Exception safety y heap lifetime con smart pointers, los cuales ya tenemos varios posts en este mismo blog sobre el concepto de smart pointers y RAII.
Nuevos contenedores de tipo hash table.
Move semantics que evita la creación y destrucción de objetos temporales innecesarias (ej: al retornar por valor).
Varios pequeños nuevos coding standards de C++11: funciones begin()/end(), override explícito, idioma pimpl con unique_ptr<>, etc.

En futuros posts voy a dedicar algo de tiempo en introducir estos temas y explicar por qué nacieron cada una de estas modificaciones en el nuevo estándar de C++.

El Hombre De Múltiples Caras

2011-09-12T00:00:00+00:00

Change volume with mouse wheel over task bar

2011-08-01T00:00:00+00:00

Yeah, you can change the volume just moving the mouse wheel over task bar using AutoHotkey and the following little script:

Assault Rigs y Herbie Hancock

2011-07-10T00:00:00+00:00

Hace ya unos cuantos años atrás (tal vez más de 10), cuando junto con mis hermanos adquirimos una PlayStation, la consola traía un CD de demo ¹ con varios juegos. Entre esos había uno de tanques con una música algo especial. Luego nunca más me acordé del nombre del juego, y la músico quedó perdida en mi inconsciente.

Da la casualidad que ayer escuché Hang Up Your Hang Ups de Herbie Hancock. E inmediatamente recordé la música. Busqué el nombre del CD demo, encontré el listado de juegos y ahí estaba, el Assault Rigs:

La lista de músicos de Assault Rigs:

Andrew Crowley
Stuart Duffield
Matt Furniss

Buscar por “CD Sampler Pack Vol2” aquí. ↩

Víctima de la modernidad

2011-06-29T00:00:00+00:00

Somos rehenes de un mundo que no hicimos. Sufrimos insomnio por una pesadilla que no soñamos. Somos partícipes de una historia que nadie recuerda. Somos guionistas de un papel protagónico que nadie actúa. Somos engranajes en un plan de unos pocos cerebros siniestros. Somos un eslabón de una cadena trunca. Somos el eco que ya no se escucha. Somos la imagen de un ruido perdido.

Somos víctimas de un mundo moderno que sólo fábrica para un futuro en el que no estamos.

One Leg

2011-05-10T00:00:00+00:00

David Capello · One Leg

Short music with a couple of guitars.

Google Chrome - Always on top

2011-03-27T00:00:00+00:00

OK, Google Chrome needs an “Always on top” option for Windows (indeed Windows needs that option for all applications).

Installing AutoHotKey and running this AutoHotKey script, you will be able to put any window on top (with 80% of opacity) pressing just WinKey+O key when you’ve the window active. Here is the script just for reference:

Notes:

You can change #o:: in the first line with other key if you want (e.g. #g:: will be WinKey+G key instead of WinKey+O)
You can change 204 with other level of opacity (0 is completely transparent, 255 is completely opaque)

References:

Slow Walk

2011-03-21T00:00:00+00:00

Hace mucho que no cuelgo una música, vamos con algo simple:

David Capello · Slow Walk

Sucesión de 12 compases clásica de blues en mi tonalidad preferida del piano (la más fácil), Do mayor. La improvisación del punteo con escala pentatónica de Do mayor.

Cola de prioridades (STL priority_queue)

2011-03-08T00:00:00+00:00

La cola de prioridades es una estructura de datos que se puede visualizar como una bolsa, donde podemos ir metiendo elementos uno atrás del otro, pero sólo los podemos retirar según un criterio de prioridad. Por ejemplo, en el caso de un ladrón obsesivo-compulsivo, podría robar un banco cargando bolsas de dinero sin ningún criterio, y al vaciarla podría retirar los billetes según su valor (primero los de $100, luego los de $50, etc.).

Otro ejemplo, imaginemos que tenemos un barco:

#include <queue>
#include <list>

using namespace std;

class Barco {
public:
  void subirPasajero(const Pasajero& pasajero);
  void abandonarBarco(list<Pasajero>& pasajerosEnOrden);

private:
  priority_queue<Pasajero> pasajeros_;
};

La función subirPasajero() debe agregar un pasajero al barco, y abandonarBarco() debe sacar todos los pasajeros del barco y colocarlos (por orden de prioridad) en la lista que se recibe como argumento:

void Barco::subirPasajero(const Pasajero& pasajero)
{
  pasajeros_.push(pasajero);
}

void Barco::abandonarBarco(list<Pasajero>& pasajerosEnOrden)
{
  while (!pasajeros_.empty()) {
    pasajerosEnOrden.push_back(pasajeros_.top());
    pasajeros_.pop();
  }
}

Tenga en cuenta que la función miembro pop() de las colas en C++ (queue, priority_queue, etc.) no retornan el valor extraído. Esto es así para evitar crear copias de los objetos dentro de la cola. De este modo la función top() devuelve una referencia al elemento mismo que se encuentra en la cola, y pop() lo remueve sin devolver nada. Así nos evitamos de crear copias temporales de la instancia removida.

Para poder usar la priority_queue sobre un tipo de dato propio (como Pasajero), debemos ofrecer una implementación del operator<() para comparar distintas instancias de nuestro tipo de dato (este operador se utiliza para saber qué elemento debe salir último de la cola, es decir, el menor elemento tiene menor prioridad):

enum Prioridad { Capitan, Hombre, Mujer, Ninio };

class Pasajero {
public:
  Pasajero(Prioridad p) : prioridad_(p) { }

  bool operator<(const Pasajero& otro) const {
    return prioridad_ < otro.prioridad_;
  }

  Prioridad prioridad() const { return prioridad_; }

private:
  Prioridad prioridad_;
};

De este modo, el capitán tiene prioridad 0 y es tomado en cuenta como el de menor prioridad para abandonar el barco. Los pasajeros que mayor prioridad tienen de abandonar el barco son las mujeres y los niños. En este caso podrían tener igual prioridad, no tendría mucho sentido salvar a todos los niños sin sus respectivas madres.

Ahora podemos crear un ejemplo:

#include <iostream>

using namespace std;

int main()
{
  Barco titanic;
  titanic.subirPasajero(Pasajero(Capitan));
  titanic.subirPasajero(Pasajero(Mujer));
  titanic.subirPasajero(Pasajero(Hombre));
  titanic.subirPasajero(Pasajero(Mujer));
  titanic.subirPasajero(Pasajero(Ninio));
  titanic.subirPasajero(Pasajero(Hombre));
  titanic.subirPasajero(Pasajero(Ninio));
  // ...

  list<Pasajero> pasajeros;
  titanic.abandonarBarco(pasajeros);
  
  for (list<Pasajero>::iterator it = pasajeros.begin(),
         end = pasajeros.end(); it != end; ++it) {
    cout << it->prioridad() << "\n";
  }
  
  return 0;
}

El anterior ejemplo imprime:

Lo que significa que, sin importar el orden en el cual agregamos los pasajeros, primero extraemos los niños, luego las mujeres, los hombres, y finalmente el capitán.

Más información:
http://www.cplusplus.com/reference/stl/priority_queue/
http://en.wikipedia.org/wiki/Priority_queue

Ingenieros en Sistemas de Información

2011-03-06T00:00:00+00:00

La carrera de Ingeniería en Sistemas de Información está llena de casos (brain washers) donde te dicen una y otra vez que “el ingeniero no debe programar”. OK, para poner las cosas claras: El ingeniero en sistemas que no programó nunca, o no piensa programar nunca, ni piensa tocar una línea de código, es en pocas palabras alguien que no sirve absolutamente para nada.

Puedo enumerar algunos caminos que un Ingeniero en Sistemas de Información quisiera tomar para esquivar la programación: diseñador, arquitecto, investigación, project manager, testing, calidad. Pero igualmente no vale la pena ser exhaustivos, ya que todos tienen la misma respuesta: Si nunca programaste, nunca vas a poder hacer otra cosa bien.

Por ejemplo, no concibo a la figura de un diseñador que nunca programó. Siendo el diseñador alguien que “fabrica” las bases para los programadores, ¿cómo puede entender alguien qué es bueno para los programadores si nunca programó? Lo mismo se aplica a la arquitectura del sistema que van a usar los programadores a lo largo de todo el desarrollo. A un project manager que se encarga de manejar programadores. A los testers que se encargan de probar código de programadores. La calidad que intenta arreglar y optimizar todo el proceso que deben seguir los programadores. En todo esto el punto clave es: Si nunca fui programador ¿puedo comprenderlos y mejorar su desarrollo o su forma de trabajo? La respuesta es no.

El único fin de la Ingeniería en Sistema de Información es hacer un sistema o mantener un sistema heredado, y la única forma de hacerlo es comunicándose con la computadora programando. Por lo tanto, los programadores son la pieza fundamental. Sin programación, no hay sistema. En consecuencia, deberías comenzar a respetar a los programadores.

Consejo: Si estás estudiando Ingeniería en Sistemas de Información, aprende a programar. Si no te gusta programar, no importa, el mundo sigue andando con gente que estudió y trabaja de algo que no le gusta, tal vez a costa del sufrimiento de otros.

Intros

2010-12-30T00:00:00+00:00

La primera intro (u “opening”) que me sorprendió en mi vida fue la de Tekken para arcade en una pantalla gigante. En el Bowling 10 de Rosario para ser más precisos hace cientos de años atrás:

Te ponía la piel de gallina.

Después la intro de Tekken 2 para PlayStation que era para caerse de la silla, con una breve introducción a cada personaje y una música increíble. La veíamos por una vidriera y fue lo que nos decidió comprar la PlayStation (en un televisor pasaban esto, y en otro la cabeza de Mario 64, nos decidimos por la PlayStation):

Tekken 3 de Arcade:

Tekken 3 de PlayStation (nivel cinematográfico, aunque es notorio que los modelos 3D y la animación todavía no estaban tan avanzadas para ese entonces):

Igualmente, la intro que más se gravo en mi cabeza es la de Twisted Metal 2. Con menores recursos que las otras (animación 2D, imágenes estáticas que se rotan y desplazan, como una animación de Flash) pero con una voz de fondo espectacular, Welcome to Twisted Metal:

También vale la pena ver los finales de Twisted Metal 2, no tienen desperdicio.

Follow

2010-12-03T00:00:00+00:00

Una importante aclaración sobre el botón “Follow” (Seguir) de Twitter, principalmente para los políticos que lo usan: A veces, este botón no significa algo bueno. Es decir, que un político tenga 100.000 seguidores no significa nada. El “Follow” no equivale a un “Lo voy a seguir” en repuesta a “Síganme, no los voy a defraudar”. El “Follow” significa “¡Síganlo, que no se escape!”.

Sueños

2010-11-17T00:00:00+00:00

Nunca te vayas a dormir después de usar la computadora. La computadora roba sueños. Si te preguntas por qué ya no sueñas más, es porque usas la computadora antes de dormir. 30 o 60 minutos antes lee un cacho de novela o libro de filosofía. No funciona si lees libros técnicos.

Simulador Político

2010-09-30T00:00:00+00:00

Así como existen simuladores de vuelo para entrenar pilotos, debería existir un simulador para aspirantes a político. La idea sería meterlos dentro de una máquina y hasta que no dejan de destruir naciones, no se los saca al mundo real.

Iostream - Redireccionar clog para "loguear" en un archivo

2010-09-18T00:00:00+00:00

La iostream es la librería de entrada y salida de C++. Existen algunos streams estándares de salida: std::cout, std::cerr y std::clog. El primero apunta a la consola, y los dos últimos... también. Las diferencias son estas:

cout apunta a la salida estándar STDOUT (texto de resultado esperado de un programa);
cerr y clog apuntan a STDERR (salida de errores y cualquier otra porquería).

Aunque a primera vista todo el texto se envía a la consola, uno puede redireccionar la salida a otros lados. Por ejemplo, imaginemos que tenemos el siguiente programa test.exe:

#include <iostream>

using namespace std;

int main()
{
  cout << "A\n";
  cerr << "B\n";
  clog << "C\n";
  return 0;
}

Al ejecutarlo, obtenemos por pantalla las tres líneas:

test.exe [ENTER]
A
B
C

Pero resulta interesante saber que podemos redireccionar el STDOUT a un archivo y el STDERR a otro. Ejemplo:

test.exe 1>stdout.txt 2>stderr.txt

¿Qué demonios es 1 y 2? Los archivos tienen un descriptor que los identifica, 1 es para la STDOUT, y 2 para STDERR. El signo mayor (>) significa que "quiero redireccionar toda la salida de texto que vaya para este descriptor a este archivo". En el anterior ejemplo logramos obtener dos archivos distintos, stdout.txt que contiene una línea (A), y stderr.txt que contiene dos líneas (B y C).

Generalmente, los logs van a un archivo, no a la pantalla. Aunque por defecto clog mande todo a STDERR, resulta útil redireccionar este stream a un archivo propio (por ejemplo, test.log). De esta forma, podemos hacer uso de clog para "loguear" todo lo que nuestro programa hace.

¿Cómo se redirecciona clog? Básicamente los streams de C++ tienen un streambuf asociado, y éste es el realmente encargado de leer y escribir datos (en la pantalla, en un archivo, en un string en memoria, etc.). Por lo tanto, si creamos un fstream y le colocamos su propio streambuf a clog, podemos usar clog como un "alias" del fstream original (clog va a estar compartiendo el mismo streambuf que el fstream). El código resultante es bastante sencillo:

#include <iostream>
#include <fstream>

using namespace std;

int main()
{
  // Creamos un archivo de salida para logging.
  ofstream test_log;
  test_log.open("test.log");

  // Obtenemos el streambuf actual de clog (esto
  // lo usaremos luego para restaurar el streambuf
  // a su valor original, por si las moscas).
  streambuf* old_rdbuf = clog.rdbuf();

  // Reemplazamos el streambuf de clog con el del archivo.
  // Ahora ambos streams utilizarán el mismo streambuf (es
  // decir, escriben en el archivo test.log).
  clog.rdbuf(test_log.rdbuf());

  // Hacemos lo mismo que el ejemplo original.
  cout << "A\n";
  cerr << "B\n";
  clog << "C\n";
  
  // Restauramos el viejo streambuf de clog.
  clog.rdbuf(old_rdbuf);

  // Cerramos el archivo.
  test_log.close();
  return 0;
}

Y listo, ahora podemos hacer lo mismo que antes:

test.exe 1>stdout.txt 2>stderr.txt

Con lo cual obtenemos tres archivos:

stdout.txt con la línea A.
stderr.txt con la línea B.
test.log con la línea C.

Compartidor

2010-09-15T00:00:00+00:00

Detrás del éxito de las redes sociales como Facebook o Twitter, se esconde uno de los sentimientos más primitivos del ser humano: El compartir algo que nos gusta. Lamentablemente, en vez de contemplar y aprovechar al máximo nuestras propias vivencias y emociones, intentamos rellenar el alma de las demás personas. Así podemos identificar a un nuevo ser que emerge de la Internet con total majestuosidad: el compartidor.

El compartidor no es sólo el tipo que comparte, es el tipo que en su interior, muy en lo profundo de su ser, cree que todo lo que ve, escucha, huele y siente, puede ser transmitido a otros. Potenciado a base de redes sociales, el sentimiento crece en un éxtasis total al ser compartido lo antes posible con todos los amigos. Con la telefonía móvil a su favor, destruye sus sentimientos al mismo tiempo que teclea su próximo mensaje a compartir.

Fuerza de gravedad

2010-09-07T00:00:00+00:00

El desarrollo de páginas web, y la evolución del universo de la Internet, tuvo una gran fuerza en su contra que hizo, entre otras cosas, que una cantidad inimaginable de personas alrededor del mundo no puedan plasmar sus ideas y creatividad sobre uno de los soportes más ricos conocidos hoy en día: el hipertexto y la multimedia (dos palabras prehistóricas). Dicha fuerza se la conoce como Internet Explorer.

Miembros virtuales

2010-08-30T00:00:00+00:00

Una función miembro virtual tiene la característica de poder ser sobrecargada por subclases para agregar un comportamiento propio. Pero existen dos lugares en donde las funciones virtuales toman un comportamiento especial: en los constructores y los destructores.

Veamos el siguiente ejemplo:

#include <iostream>

using namespace std;

class Lugar {
public:
  Lugar() {                     // El lugar es creado
    creacion();                 // Llamamos a la función virtual
  }
  virtual ~Lugar() {            // El lugar es destruido
    destruccion();              // Llamamos a la función virtual
  }
protected:
  virtual void creacion()    { }
  virtual void destruccion() { }
};

class Universo : public Lugar {
protected:
  void creacion()    { cout << "Big Bang\n"; }
  void destruccion() { cout << "Big Crunch\n"; }
};

int main()
{
  Universo i_am_god;  // ¿Qué imprime este programa?
  return 0;
}

La idea de todo método virtual es poder proporcionar puntos de extensión a las clases derivadas. En este caso, ¿Lugar::creacion funciona como punto de extensión para clases derivadas? La respuesta es: no. El anterior programa no imprime nada.

Aunque creamos una instancia de Universo, ni el método Universo::creacion ni Universo::destruccion se llamaron. ¿A qué se debe esto? Imaginemos que al crear un Universo, primero debemos crear un Lugar en su totalidad, para luego comenzar a crear el universo. Es por eso que si llamamos a creacion mientras estamos construyendo el Lugar, no podemos alcanzar el método Universo::creacion ya que el Universo todavía no comenzó a ser construido (no tiene un Lugar completamente construido donde existir).

La secuencia correcta es:

Alojamos un cacho de memoria suficiente como para que entre el universo.
Algo así como hacer un: this = malloc(sizeof(Universo)) en C.
Construimos el Lugar usando la memoria recién obtenida como puntero this.
Luego construimos el Universo.
Y recién ahí somos capaces de llamar a Universo::creacion y asegurarnos que estaremos usando el método especializado de la subclase.

¿Puedo llamar a creacion dentro del constructor de Universo? La respuesta es sí, todo es posible. ¿Es correcto? Mmmhh, depende, si alguien hace una subclase de Universo y sobreescribe creacion, nuevamente estará en el mismo problema que estamos mostrando aquí.

¿Por qué en el destructor de Lugar no llama a Universo::destruccion? Porque el Universo ya está destruido (¿cruncheado?) para cuando llegamos al destructor del Lugar.

¿Cómo lo soluciono? Usar puntos de extensión en los constructores y destructores presentan más problemas que ventajas. La solución es no usarlos. Solución (obvia):

#include <iostream>

using namespace std;

class Lugar {
public:
  Lugar() { }
  virtual ~Lugar() { }
};

class Universo : public Lugar {
public:
  Universo()  { cout << "Big Bang\n"; }
  ~Universo() { cout << "Big Crunch\n"; }
};

int main()
{
  Universo i_am_god;
  return 0;
}

En un próximo post voy a dar un ejemplo más complejo donde esto no sirve.

¿Y qué sucede si llamo una función miembro abstracta en el constructor o destructor? Es el desastre total. Completamente ilegal. Imposible. Una violación absoluta a la razón y el sentido común. Imagine este código:

#include <iostream>

using namespace std;

class Lugar {
public:
  Lugar() { creacion(); }        // Ja llamo a creacion()
protected:
  virtual void creacion() = 0;   // Jaja y no lo defino ;)
};

class Universo : public Lugar {
protected:
  void creacion() { }            // Jajaja sólo puede llamarme a mí!
};

int main()
{
  Universo i_am_god_x2;
  return 0;
}

Al compilar este código con gcc obtenemos un warning porque estamos llamando un método abstractor en el constructor, y un error de enlace al crear el ejecutable ya que Lugar::creacion no está definido:

test.cpp: In constructor 'Lugar::Lugar()':
test.cpp:7:22: warning: abstract virtual 'virtual void Lugar::creacion()' called from constructor
C:\temp\ccstr9Hr.o:test.cpp:(.text$_ZN5LugarC2Ev[Lugar::Lugar()]+0x16): undefined reference to `Lugar::creacion()'
collect2: ld returned 1 exit status

Aunque dijimos explícitamente que Lugar::creacion() es abstracto (=0), eso no significa que no debamos definirlo en este caso tan particular.

Referencias:
Sutter, Herb & Alexandrescu, Andrei (2004). Item 49: Avoid calling virtual functions in constructors and destructors. C++ Coding Standards: 101 Rules, Guidelines, and Best Practices. Boston, MA: Addison-Wesley Professional, (ISBN 0321113586).

Ridículo

2010-08-22T00:00:00+00:00

A veces la gente pide cosas completamente imposibles. Esta issue de Chromium me hizo reír. El tipo tenía problemas descargando archivos con su versión de Chrome, reporta la issue, pero al mismo tiempo dice: “But please don’t ask me to change another version”…

O sea ¿Tenes un problema con el software que usas pero no querés ni hacer el mínimo esfuerzo de actualizarlo? ¿¡Inclusive si eso significa hacer un simple doble-click?!

Las respuestas a la issue son geniales.

TODO (a hacer)

2010-08-05T00:00:00+00:00

Supongo que todos (los geeks) suelen tener un txt con una lista de “cosas a hacer” (un “to do”). Hoy me di cuenta que, con justa razón, tengo las tareas “a hacer” a un paso de la papelera.

¿Será que nunca termino de hacer todo lo que me gustaría hacer?

Botones

2010-08-03T00:00:00+00:00

Veamos los siguientes requerimientos. Tenemos tres clases de botones:

Button: El botón común que al presionarlo ejecuta un comando (OK, Cancel, Yes, No, Close, Kill Process, etc.)
Check-box: Una caja para poner un tilde.
Radio-button: Un conjunto de botones redondos para seleccionar una opción entre varias.

Cada clase de botón puede verse y actuar como otra clase al mismo tiempo. Por ejemplo: un check-box puede verse como un button pero actuar como check-box, o tres buttons pueden actuar como radio-buttons pero verse como buttons.

Además, existen algunas propiedades específicas:

Los botones que se ven como buttons pueden tener cuatro valores que indican la redondez de cada una de las cuatro esquinas. Recuerde que un check-box o un radio-button puede lucir como un button.
El comportamiento de los radio-buttons necesita de un grupo que los reuna (por ejemplo, un ID que indica que varios radio-buttons pertenecen al mismo grupo). Recuerde que un button o un check-box puede actuar como un radio-button.

¿Cómo resolvería este problema con objetos? Esto es un excelente candidato para aplicar MVC.

Chistes

2010-07-31T00:00:00+00:00

Los eventos de la vida no son aleatorios. Son una hermosa y perfecta sucesión de chistes que se van desencadenando a medida que crecemos.

Blogs

2010-07-31T00:00:00+00:00

En el futuro, los diarios, las páginas web, los blogs, los microblogs, SMS y todo medio de comunicación escrito, será reemplazado por una alternativa más económica y efectiva: El yoctoblogging. Todo podrá ser dicho con monosílabos: soy, yo, fui, bien, sí, pis, más, mal, gas, ¿vos?, ¿y?…

El tiempo libre será tan poco que sólo tendremos lo suficiente como para escribir (y leer) este tipo de mensajes.

Tentación

2010-07-27T00:00:00+00:00

A veces siento que me mira y me habla… y escucho “vení, haceme click, dale ;) … tengo un montón de cosas para ofrecerte”

Al final, siempre me defrauda.

Apuntes y creatividad

2010-07-27T00:00:00+00:00

Consejo: Si vas a enseñar una materia en la facultad o un curso, ¿por qué no agregarle un poco de creatividad al asunto? En vez de usar los mismos ejemplos del libro de referencia, a veces es bueno inventar otros (inclusive, evitar usar una escaneada del libro puede ser una buena idea).

Interfaces gráficas interesantes para diseñar

2010-07-26T00:00:00+00:00

Esta es una lista de interfaces gráficas interesantes para resolver:

Una interfaz gráfica que pueda ser usada inmediatamente por cualquiera que nunca haya visto una computadora.
Un lenguaje de scripting que me permita hacer cualquier cosa en el sistema operativo, sin necesidad de escribir una línea de código. Por ejemplo, una interfaz para configurar una red de pipes y filtros, donde por las tuberías puede pasar cualquier tipo de dato (texto, datos binarios crudos, imágenes, audio, logs, planillas de excel, bases de dato, páginas web, mails, código fuente, etc.) y los filtros los pueden transformar en cualquier cosa.
Una interfaz que permita hacer control de versiones con Git con varios repositorios remotos de forma totalmente gráfica, sólo con el mouse. Comandos complejos como rebase podrían ser un simple drag and drop. Debería poder tener una visión de cada repositorio como una pequeña computadora a la que le puedo hacer pull y push (por branch). Etc.
Un editor de texto como Microsoft Word o OpenOffice.org Writer que produzca documentos de tan buena calidad como LaTeX.

Sólo ideas. ¿Para proyectos open source? ¿para proyectos comerciales?

Alcance

2010-07-26T00:00:00+00:00

Estaba comiendo en un bar. Levanto la vista y miro el televisor. Un tipo pidiendo limosna a un periodista. El periodista lo mira y le dice: “Señor, yo estoy para mostrarle al mundo sus miserias”. El tipo pega la vuelta y sigue comiendo basura. Yo sigo comiendo. Un pibe se acerca y me pide limosna. Lo miro, le doy una moneda, y pienso: “Que poco puedo cambiar este mundo”. Sigo comiendo.

Cuentos

2010-07-25T00:00:00+00:00

Un día un tipo se levantó de la cama y se puso a escribir un cuento. Para la noche ya lo había terminado. El cuento era tan bueno que no podía creerlo. Lo leyó una y otra vez, era increíble.

Nunca más vieron al tipo.

Con el cerebro

2010-07-25T00:00:00+00:00

Llegará el día que programaremos con el cerebro. Los atajos de teclado no servirán de nada. Simplemente miro una ubicación, pienso en qué quiero escribir y… BAM! ahí van apareciendo las letras por arte de magia.

Eso es un editor de texto.

Descargar MinGW con gcc 4.5 automáticamente

2010-06-06T00:00:00+00:00

Este post se podría llamar:

¿Cómo instalar MinGW?
¿Cómo instalar y usar gcc 4.5 en Windows?
¿Cómo compilar programas de C o C++ en Windows?
O también, ¿puedo portar MinGW en un pendrive?

Cualquiera de los casos se responde con el siguiente archivo: MinGW-Downloader.zip.

Los pasos a seguir son los siguientes:

Cree una carpeta donde descomprimir MinGW-Downloader.zip (por ejemplo, C:\Compilers, o C:\GNU, lo importante es que la carpeta no contenga espacios!)
Descomprima MinGW-Downloader.zip en esa carpeta
Ejecute el archivo C:\Compilers\MinGW-Downloader\MinGW-4.5-Downloader.bat
Espere…
Una vez finalizado deberá ver algunos mensajes en la pantalla diciéndole si tuvo éxito (SUCCESS), inclusive el script intenta compilar un programa en C y otro en C++.
Listo, ya tiene MinGW con gcc 4.5 disponible en su máquina.

Puede usar el script Run-cmd-with-MinGW-4.5.bat para ejecutar la línea de comandos de Windows y tener el compilador disponible (gcc, g++, etc.) en la variable PATH. Lo importante es que el proceso de descarga no modifica ninguna variable de entorno suya (PATH), por lo tanto, podría borrar la carpeta C:\Compilers y empezar desde cero siempre que así lo desee.

Puede mover la carpeta C:\Compilers\MinGW-Downloader\MinGW-4.5 a C:\MinGW-4.5 y borrar C:\Compilers\MinGW-Downloader completamente. Si quiere tener el compilador disponible desde cualquier aplicación (por ejemplo, desde un editor de texto o IDE), podría agregar la ruta C:\MinGW-4.5\bin a su PATH.

Cabe destacar que la carpeta MinGW-4.5 (C:\Compilers\MinGW-Downloader\MinGW-4.5) y el archivo Run-cmd-with-MinGW-4.5.bat los puede mover donde usted desee (por ejemplo, llevarlos en un pen drive), sólo tenga en cuenta que para hacer esto los dos tienen que estar en el mismo directorio (e.j. C:\MinGW-4.5 y C:\Run-cmd-with-MinGW-4.5.bat).

Shared Pointers de C++0x

2010-05-29T00:00:00+00:00

En C usted puede hacer esto:

#include <stdlib.h>

struct Persona { };

int main()
{
  Persona* a = malloc(sizeof(Persona));
  free(a);
  return 0;
}

Un ejemplo equivalente en C++:

class Persona { };

int main()
{
  Persona* a = new Persona();
  delete a;
  return 0;
}

Por cada malloc existe un free (al menos que use reallocs), y por cada new existe un delete (y por cada new[] un delete[]).

¿Existe una forma por la cual C++ se "entere" que ya no quiero usar un puntero? La respuesta es: No, no existe. C++ no tiene un garbage collector. Pero existen clases que pueden ayudarnos, como el viejo y tan poco querido auto_ptr, o los mejorados unique_ptr, shared_ptr y weak_ptr del nuevo estándar de C++0x (o el TR1).

Un shared pointer es una clase que se encarga de guardar un puntero a un objeto (o tipo de dato), y cuenta la cantidad de referencias que se están haciendo a dicho objeto (es decir, la cantidad de shared pointers que apuntan al mismo objeto). El último shared pointer que se destruya (cuando las referencias llegan a cero), será el encargado de borrar el objeto apuntado (mediante un simple delete).

Un ejemplo:

#include <iostream>
#include <memory>  // Aquí debería estar shared_ptr<> (GCC 4.4)

using namespace std;

class Persona {
  int n;

public:
  Persona(int n) : n(n) {
    cout << "Nace la persona " << n << "\n";
  }

  ~Persona() { 
    cout << "Muere la persona " << n << "\n";
  }

  static shared_ptr<Persona> Crear(int n) { 
    return shared_ptr<Persona>(new Persona(n));
  }
};

int main()
{
  shared_ptr<Persona> a(new Persona(1));
  shared_ptr<Persona> b = Persona::Crear(2);
  shared_ptr<Persona> c;

  cout << "--- Aquí ambas personas existen ---\n";

  c = a; // Aquí c apunta a la persona 1
  b = c; // Ahora b apuntará a la persona 1 (la persona 2 muere porque
         // ya no existen referencias a ella)

  cout << "--- Aquí la persona 2 ya no existe ---\n";
  
  return 0;
}        // Aquí muere la persona 1 (a, b, c apuntaban a ella)

La salida del anterior programa es esta:

Nace la persona 1
Nace la persona 2
--- Aquí ambas personas existen ---
Muere la persona 2
--- Aquí la persona 2 ya no existe ---
Muere la persona 1

Como puede ver, en el anterior programa se llama sólo dos veces a "new Persona" y dos veces al destructor ~Persona. No debemos preocuparnos por usar "delete", el shared_ptr<> hace todo por nosotros.

¿Cómo hago para que la clase shared_ptr funcione en VS2008 SP1 Express? Debe definir _HAS_TR1 antes de incluir el archivo <memory>. Ejemplo:

#ifdef _MSC_VER      // Si estamos usando el compilador de Microsoft
  #define _HAS_TR1 1 // Esto hará que se incluyan las clases del TR1 (std::tr1)
#endif

#include <iostream>
#include <memory>

using namespace std;
#ifdef _MSC_VER
  using namespace std::tr1; // para tener shared_ptr<> disponible
#endif

// Resto del ejemplo...

C++0x Final Committee Draft (FCD)

2010-03-31T00:00:00+00:00

Ya está disponible el documento N3092, Programming Languages — C++, Final Committee Draft. Este documento es el que más podría corresponder al nuevo estándar ISO de C++ (lo que viene de acá a uno o dos años pueden ser correcciones menores):

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf

Más información acá.

Improving your applications by statistics

2010-03-03T00:00:00+00:00

If you developed an application and published it in a website, you can use things like google-analytics data to adjust your application. E.g. If everybody is accessing your website with 32-bits, 24-bits and 16-bits screen resolutions, you can discard all considerations about 8-bits modes in your application.

Things you should add to your application:

A way to get usage data from your users. E.g. where they do click, how they call commands (menus, keyboard, toolbars, ribbons, etc.). In this way you could focus improvement in the more common methods to run commands.
A way to count how many times a command was used. Maybe there are commands that are rarely used, these commands could be more deeper in menus hierarchies and without keyboard shortcut.
A way to known systems where your application is running. E.g. operating system, version, screen resolution, etc. Improve usability in the most used platform.
A way to known how many computers are running a specific version of your application. If a version is not used anymore, you can stop supporting it (E.g. Adding patches for a version that nobody uses).

All this must be done carefully, with proper check-boxes like “Do you want to send anonymous data about your usage to improve customer experience?” in installers, splash screens, etc.

There are some frameworks to do this kind of work. Anyway you basically need:

An HTTP server to accept packages from users (e.g. through POST requests). Each request should be processed by a script (in PHP, ASP, etc.) which should convert the received package into database model.
A way to differentiate users (you could SHA1 some string like “local user name + pc host name + app name version”). Here I don’t know if the IP could be a good way idea (NAT problems, etc.).
A way to make HTTP requests from your application (firewall + proxy problems) of all collected usage data of the user (identified by the SHA1).
A mini-program to process all the database and print some useful reports.

Emacs: How to open the current buffer with associated application?

2010-03-02T00:00:00+00:00

The following function tries to run the application associated with the current buffer file type (e.g. if you use this function in an .html file, the file will be opened with your default web browser):

(defun open-current-file-with-associated-app ()
  (interactive)
  (shell-command (concat "cmd /c \"start " (buffer-file-name) "\"")))

Emacs: How to locate the current buffer in Windows Explorer?

2010-03-02T00:00:00+00:00

You can use the following function to open the Windows Explorer in the directory of the current buffer:

(defun locate-current-file-in-explorer ()
  (interactive)
  (cond
   ;; In buffers with file name
   ((buffer-file-name)
    (shell-command (concat "start explorer /e,/select,\"" (replace-regexp-in-string "/" "\\\\" (buffer-file-name)) "\"")))
   ;; In dired mode
   ((eq major-mode 'dired-mode)
    (shell-command (concat "start explorer /e,\"" (replace-regexp-in-string "/" "\\\\" (dired-current-directory)) "\"")))
   ;; In eshell mode
   ((eq major-mode 'eshell-mode)
    (shell-command (concat "start explorer /e,\"" (replace-regexp-in-string "/" "\\\\" (eshell/pwd)) "\"")))
   ;; Use default-directory as last resource
   (t
    (shell-command (concat "start explorer /e,\"" (replace-regexp-in-string "/" "\\\\" default-directory) "\"")))))

How it works?

If you are visiting a buffer associated to a file (with buffer-file-name), the Windows Explorer is opened to focus the file in its directory.
If you are in dired mode (browsing a directory inside Emacs with dired-mode), it will open that directory in Windows Explorer.
If you are in eshell-mode, the current working directory will be opened in Windows Explorer.
As last chance it will open the Windows Explorer in the default directory (where you start emacs). E.g. This can happen if you use this function in scratch buffer (which is a buffer without an associated file).

STL string, parseando un número de versión

2010-01-27T00:00:00+00:00

En esta ocasión vamos a ver cómo usar la clase std::string para convertir una cadena de caracteres (como "1.2.3") en una clase "Version" que tenga una interfaz simple de utilizar (por ejemplo, que permita comparar versiones).

Los pasos son simples:

tenemos como entrada una cadena de caracteres,
dividimos la cadena según el caracter '.' (punto),
convertimos cada parte a entero,
guardamos cada número entero de forma ordenada en un vector.

El punto 2 es en el cual nos vamos a enfocar más. El código mostrado aquí es a modo de ejemplo, y está lejos de ser el más óptimo.

Antes de comenzar ¿Podemos usar strcmp para comparar dos versiones? No, no podemos. Ejemplo: strcmp("1.9", "1.10") > 0, cuando en realidad la versión 1.9 es menor a 1.10.

Imaginemos que tenemos una cadena:

std::string ver = "1.10.2.3";

La clase std::string tiene la función miembro find, la cual podemos usar para buscar casi cualquier cosa dentro de la cadena. ¿Qué debemos buscar? Los puntos, sabiendo donde está cada punto, podemos ir recortando la cadena en sus distintas partes ("1", "10", "2", y "3"). Buscamos la ubicación del primer punto:

size_t i = ver.find('.');

if (i != std::string::npos)
  std::printf("El punto fue encontrado en la posición %d\n", i);
else
  std::printf("No hay punto en la cadena\n");

Ejecutando el código anterior, deberíamos obtener el mensaje:

El punto fue encontrado en la posición 1

¿Qué es size_t? Es como el tipo "unsigned int", el tipo de dato retornado por el operador sizeof() y utilizado como índice en las funciones de std::string.

¿Qué es std::string::npos? Es el máximo valor posible de un size_t y se utiliza para indicar (en este caso) que la función find falló (no encontró el punto).

Una vez que tenemos la posición del punto, podemos obtener la porción de texto que contiene la primer cifra, para eso usamos la función miembro substr:

std::string primer_cifra = ver.substr(0, i);

Esto significa: che vos, función substr, devolveme el pedazo de cadena de caracteres que va desde el índice 0, y tiene una longitud de i-caracteres.

El proceso puede ser repetido tantas veces como queramos para seguir obteniendo cifras. Por ejemplo, para la siguiente cifra debemos buscar (find) el siguiente punto, pero comenzando desde el que encontramos hace un rato:

i++;     // ir a la posición siguiente del punto '.'
size_t j = ver.find('.', i);

¿Qué es (o hace) el segundo argumento de find? Le indica a la función desde donde debe comenzar a buscar. La primera vez que usamos find este argumento no se especificó, porque por omisión toma el valor 0, es decir, buscar desde el inicio de la cadena.

¿Por qué i++? Porque si comenzáramos a buscar un punto desde i, nos devolvería la misma posición i (porque justamente, en i, está el primer punto que encontramos). Entonces debemos avanzar una posición.

Ahora, debemos recortar la segunda cifra:

std::string segunda_cifra = ver.substr(i, j-i);

La segunda cifra, comienza desde i y tiene una longitud igual a j-i. Para comprender esto, vea la siguiente figura:

De esta forma, ver.substr(i, j-i) nos devuelve la cadena "10". La versión completa del algoritmo puede quedar algo así:

#include <vector>  // Por std::vector
#include <string>  // Por std::string
#include <cstdlib> // Por std::strtol
#include <cstdio>  // Por std::printf

int main()
{
  std::string ver = "1.10.2.3";

  // Vector con cada cifra.
  // Luego del procesamiento esto debería ser = { 1, 10, 2, 3 }
  std::vector<int> cifras;

  size_t i = 0;   // Comenzamos desde i=0
  size_t j = 0;

  // Repetir hasta no llegar al final de la cadena
  while (j != std::string::npos) {
    // Buscar próximo punto
    j = ver.find('.', i);

    std::string cifra;

    // Si se encontró un punto
    if (j != std::string::npos) {
      // Recortamos desde i hasta j
      cifra = ver.substr(i, j-i);

      // El nuevo comienzo para buscar puntos será "j+1"
      i = j+1;
    }
    // Si no se encontró un punto
    else {
      // Recortamos desde "i" hasta el final de la cadena
      cifra = ver.substr(i);
    }

    // Obtener el valor entero de la cifra
    int cifra_int = std::strtol(cifra.c_str(), NULL, 10);

    // Agregar la cifra al vector
    cifras.push_back(cifra_int);
  }

  for (size_t i=0; i<cifras.size(); ++i)
    printf("cifras[%d] = %d\n", i, cifras[i]);

  return 0;
}

La salida del anterior programa es:

cifras[0] = 1
cifras[1] = 10
cifras[2] = 2
cifras[3] = 3

Con este código, podríamos implementar una clase "Version" con la siguiente interfaz:

class Version
{
public:
  Version(const char*);
  Version(const std::string&);

  bool operator==(const Version& u) const;
  bool operator<(const Version& u) const;
  // ...
};

En un próximo post voy a colocar una posible implementación de la clase "Version".

Punteros por ámbito (scoped pointers)

2009-11-06T00:00:00+00:00

C++ no tiene un recolector de basura, aunque C++0x le va tomando el gustito, tenemos algunas opciones para liberarnos de liberar memoria, valga la redundancia.

Imaginemos un código como el siguiente:

#include <cstdio>

using namespace std;

class A {
public:
  A()         { printf("A\n");    }
  ~A()        { printf("~A\n");   }
  void hola() { printf("hola\n"); }
};

int main()
{
  A* a = new A;
  a->hola();
  return 0;
}

El anterior programa, por más minimalista que parezca, tiene un memory leak. Aunque los recursos suelen ser liberados por el mismo sistema operativo al finalizar el programa, si el proceso se ejecuta por mucho tiempo (e.j. un servicio que se ejecuta por días, semanas o meses dentro de un servidor), los recursos se van agotando poco a poco hasta que la computadora queda hecha una pasa.

Para arreglar el leak, deberíamos escribir:

int main()
{
  A* a = new A;
  a->hola();
  delete a;      // Ahora sí liberamos la memoria
  return 0;
}

¿Cómo hacemos para liberar memoria sin llamar delete nosotros mismos? Podemos crear una clase utilitaria que haga el trabajo por nosotros en su destructor. Por ejemplo, en el siguiente código veremos que el delete es llamado en el destructor de PunteroA:

class PunteroA {
  A* ptr;
public:
  PunteroA(A* p) { ptr = p; }
  ~PunteroA()    { delete ptr; }  // en el destructor borramos 'ptr'
};

int main()
{
  PunteroA a(new A);
  a->hola();          // error, "a" no es un puntero ni sobrecarga operator->
  return 0;
}

El anterior programa nos dará un error de compilación ya que el tipo PunteroA no soporta el operador flecha. Debemos agregarlo en la definición de la clase PunteroA:

class PunteroA {
  A* ptr;
public:
  PunteroA(A* p)  { ptr = p; }
  ~PunteroA()     { delete ptr; }
  A* operator->() { return ptr; } // operador flecha para acceder al puntero
};

int main()
{
  PunteroA a(new A);
  a->hola();        // ahora sí, PunteroA::operator->() nos devuelve
                    // el verdadero puntero A* y A::hola() finalmente
                    // es llamado
  return 0;
}

¿Cómo obtengo el A* desde un PunteroA? Debemos definir el operador de conversión hacia A*:

class PunteroA {
  A* ptr;
public:
  PunteroA(A* p)  { ptr = p; }
  ~PunteroA()     { delete ptr; }
  A* operator->() { return ptr; }
  operator A*()   { return ptr; } // operador para castear a A*
};

Así podemos usar un PunteroA en funciones que reciban un A*. Ejemplo:

void func(A* a) { ... }

int main()
{
  PunteroA a(new A);
  func(a);
  return 0;
}

Generalizando: Podemos generalizar nuestro PunteroA para cualquier tipo de dato:

template<class T>
class ScopedPointer {
  T* ptr;
public:
  ScopedPointer(T* p) { ptr = p; }
  ~ScopedPointer()    { delete ptr; }

  operator T*()       { return ptr; }
  T* operator->()     { return ptr; }
};

Así podemos usar el mismo ScopedPointer para liberar instancias de cualquier clase:

int main()
{
  ScopedPointer<A> a(new A);
  ScopedPointer<B> b(new B);
  a->hola();
  return 0;
}

¿Y si quiero liberar otro tipo de recurso? Si el recurso no es memoria, y es liberado con otra función en vez de delete, podemos generalizar nuestro ScopedPointer con un nuevo parámetro de template llamado Destroyer:

struct DefaultDestroyer {
  template<class T>
  static void free(T* ptr) { delete ptr; }
};

template<class T, class Destroyer = DefaultDestroyer>
class ScopedPointer {
  T* ptr;
public:
  ScopedPointer(T* p) { ptr = p; }
  ~ScopedPointer()    { Destroyer::free(ptr); }

  operator T*()       { return ptr; }
  T* operator->()     { return ptr; }
};

En este caso, el destructor ~ScopedPointer llama a la función estática Destroyer::free. Esta función básicamente puede hacer lo que nosotros queramos. Podría ser útil para liberar ficheros o cualquier otro tipo de recurso:

struct FileDestroyer {
  static void free(FILE* ptr) { fclose(ptr); }
};

int main()
{
  ScopedPointer<FILE, FileDestroyer> file(fopen("hola.txt", "rt"));
  char buf[256];
  fread(buf, 1, 256, file);
}

¿No existen punteros de este tipo ya implementados? Boost tiene su propio scoped_ptr. También existen punteros más avanzados que cuentan referencias, como los smart pointers.

Interfaces vs. Conceptos

2009-10-18T00:00:00+00:00

¿Qué son los conceptos? Vamos a ver con un simple ejemplo, cómo podemos hacer una equivalencia entre las conocidas interfaces y los conceptos.

Imaginen esta "interfaz" (clase abstracta):

class IPortero {
public:
  virtual IPortero() { }
  virtual void ir_a_piso(int piso) = 0;
  virtual int piso_destino() = 0;
};

Tenemos otra clase Ascensor que podemos "personalizar" con nuestro propio portero, así nuestra implementación de portero puede hacer lo que se le de la gana:

class Ascensor {
  IPortero* m_portero;
public:
  Ascensor(IPortero* portero) {
    m_portero = portero;
  }
  void apretaron_boton_en_piso(int piso) {
    m_portero->ir_a_piso(piso);
    mover_ascensor(m_portero->piso_destino());
  }
  void mover_ascensor(int piso) { ... }
};

Con programación genérica, podemos reformular la interfaz convirtiéndola en un "concepto" y la clase Ascensor en una clase plantilla:

template<class TipoPortero>
class Ascensor {
  TipoPortero m_portero;
public:
  Ascensor() { }
  void apretaron_boton_en_piso(int piso) {
    m_portero.ir_a_piso(piso);
    mover_ascensor(m_portero.piso_destino());
  }
  void mover_ascensor(int piso) { ... }
};

La pregunta es, ¿qué demonios es TipoPortero?. La respuesta es sencilla: TipoPortero puede ser cualquier tipo de dato que cumpla los siguientes requisitos:

Tenga un constructor por omisión (que se pueda construir un nuevo TipoPortero sin argumentos, o sea, TipoPortero()).
Tenga una función miembro TipoPortero::ir_a_piso(int), la cual recibe un "int" (o cualquier tipo de dato que se pueda construir desde un "int" implícitamente).
Y otra función miembro TipoPortero::piso_destino() que devuelve un entero.

¿Cómo especificamos la "interfaz" o los "requerimientos" de un concepto? Sencillamente no se puede, C++0x iba a soportar esto, pero ya no. Hoy en día la mejor respuesta es usar algunos comentarios en la clase Ascensor que especifiquen qué espera en sus parámetros de template. En este aspecto se podría decir que IPortero es mejor porque especifica explícitamente lo que el portero tiene que hacer (funciones a implementar, etc.).

¿Qué ventaja tiene el concepto con respecto a las interfaces? La clase genérica Ascensor ahora tiene el mismo portero adentro suyo (no un puntero a la interfaz). Las llamadas a las funciones miembro ir_a_piso y piso_destino son llamadas directas (no tienen el overhead de una llamada a una función virtual).

Clases que "desaparecen" luego de compilar

2009-10-17T00:00:00+00:00

La magia de C++ es que, una vez compilado el código, algunas clases pueden desaparecer por completo (principalmente las que se usan en stack). O sea, aunque las clases abstraen al programador de los detalles de implementación, al final, el código termina siendo tan óptimo como si la clase no fuera utilizada en un principio.

Un ejemplo. Teniendo la siguiente clase Acumulador:

#include <cstdio>

class Acumulador {
  int v;
public:
  Acumulador()         { v = 0;                   }
  ~Acumulador()        { std::printf("%d\n", v);  }
  void acumular(int x) { v += x;                  }
};

Un código como el siguiente:

{
  Acumulador acum;
  acum.acumular(2);
  acum.acumular(4);
  acum.acumular(10);
}

Al compilarlo (optimizándolo), el código equivale a exactamente esto:

{
  int v = 0;
  v += 2;
  v += 4;
  v += 10;
  std::printf("%d\n", v);
}

La clase Acumulador ya no existe. Obtenemos el código más óptimo posible: sin llamadas a la función "acumular", ni ningún byte extra de memoria (Acumulador ocupa lo mismo de memoria que ocupa un "int").

Este ejemplo no ayuda a ver grandes ventajas, pero si el constructor y el destructor hacen tareas complicadas, y las funciones miembros también, el resultado puede llevarnos a dos puntos:

Nos abstrae de la complejidad de la implementación (e.j. para qué quiero saber cómo se acumula si sólo quiero acumular)
Obtenemos código tan óptimo como si no hubiéramos usado la abstracción (e.j. las operaciones se acercan al hardware tanto como sea posible).

SourceForge habla de Allegro Sprite Editor

2009-10-13T00:00:00+00:00

Hoy salió un artículo sobre Allegro Sprite Editor en la SourceForge Community.

Las viejas home pages

2009-10-07T00:00:00+00:00

(Una nota que nadie nunca leerá)

Viendo mi página hoy en día, siento que ya es una reliquia. Hace muchísimo que las páginas personales dejaron de existir como eran antes. Ahora son todos blogs, feeds, artículos, noticias, etc. Las viejas páginas personales (con secciones, site-map, etc.) ya son una antigüedad.

A lo largo de los años fui quitando más y más texto de mi página, hasta dejarla pelada completamente. Hoy en día son sólo links, apuntando a otros sitios para bajarse cosas útiles (¿?). Algún que otro párrafo explicando algo, pero inclusive sospecho que esos párrafos nunca serán leídos.

En fin, las viejas páginas personales fueron devoradas por la “fast-food” de la información en Internet.

Google Wave

2009-09-19T00:00:00+00:00

Una de las mejores cosas que vi:

http://wave.google.com/
http://en.wikipedia.org/wiki/Google_Wave
~~http://code.google.com/intl/es-AR/apis/wave/~~ http://incubator.apache.org/wave/

Editado 2012-04-05: Me causa gracia hoy en día como uno de los mejores proyectos que pensé ver, fue cerrado.

Modernización de Emacs

2009-08-26T00:00:00+00:00

Un artículo de Xah Lee que habla sobre cómo mejorar Emacs. Por fin alguien que piensa en la usabilidad en el software libre.

Y su proyecto para llevarlo a cabo: ErgoEmacs.

Lo que quieras hacer

2009-07-23T00:00:00+00:00

Tema Lo que quieras hacer de Riff

Te dicen que nunca hiciste algo bien,
que no fuiste lo que debías ser;
no saben que acaso no quisiste ser,
como ellos decían estaba bien.

Según pasa el tiempo te das cuenta que
todo fue distinto a lo que iba a ser,
sólo queda ahora seguir adelante,
seguir adelante y no retroceder.

Tuya, es toda tu vida
para hacer lo que tu quieras hacer,
tuya, y no sólo mía
porque yo ya no te puedo ni ver.

C++0x no va a tener "conceptos"

2009-07-23T00:00:00+00:00

En la última reunión del ISO C++ Standards Committee decidieron quitar los "conceptos" del próximo estándar de C++ (que en realidad, en vez de C++0x va a ser C++1x y chirola). Un artículo de Bjarne Stroustrup habla al respecto:

[...] Básicamente, los "conceptos" tenían como meta hacer de la programación genérica algo más accesible a la mayoría de los programadores, pero esa meta ha sido para mí (Stroustrup) seriamente comprometida: En vez de hacer la programación genérica más accesible, los "conceptos" se fueron convirtiendo en otra herramienta más en las manos de los expertos (únicamente).
[...]
Para resumir y de alguna forma simplificar, he afirmado que:
Los "conceptos" como están actualmente definidos son muy difíciles de utilizar, lo que los llevará al desuso, dando la posibilidad a un desuso de los templates mismos y a la adopción completa de C++0x.
Un pequeño conjunto de simplificaciones [BS2009] pueden dejar a los "conceptos" lo suficientemente aceptables como para salir acorde a las fechas planificadas para C++0x o con sólo un retraso menor.
[...]

STL vector en vez de los clásicos buffers de C

2009-07-12T00:00:00+00:00

Algunas veces tenemos que crear buffers temporales. Por ejemplo, la función sprintf necesita de un buffer para poder dejar la cadena resultante. Ejemplo:

char buf[256];
sprintf(buf, "%d", 12345);
// usar "buf"...

Si queremos mantener el buffer en heap:

char* buf = malloc(256);
sprintf(buf, "%d", 12345);
// usar "buf"...
free(buf);

En C++ podríamos hacer uso de los operadores new[]/delete[]:

char* buf = new char[256];
sprintf(buf, "%d", 12345);
// usar "buf"...
delete[] buf;

Pero es aconsejable evitar la creación de arreglos con new[], y en su lugar hacer uso de std::vector:

std::vector<char> buf(256);
sprintf(&buf[0], "%d", 12345);
// usar "&buf[0]" en vez de "buf"...

El resultado: tenemos un buffer en el heap que se libera automáticamente (~std::vector) al salir del ámbito de la función que lo utiliza.

Conscientemente, todo todo, lo podrás lograr

2009-04-06T00:00:00+00:00

Tema Conscientemente, todo todo, lo podrás lograr de Billy Bond y La Pesada Del Rock and Roll

En tu mente, en tu mente vivirán.
Los deseos, los deseos de cambiar.
Concientemente todo todo lo podrás lograr.

No te quedes, no te quedes muy atrás.
Si no sigues, no tendrás con quien hablar.
Concientemente todo, todo lo podrás lograr.

Vamos chicos, vamos chicos a cambiar.
Vamos loco, vamos loco a cambiar.
Concientemente todo todo lo podrás lograr.

No te quedes siempre en el mismo lugar.
Vamos chico, vamos loco a cambiar.
Concientemente, todo todo, lo podrás lograr.

STL for each

2009-03-21T00:00:00+00:00

Para recorrer un arreglo de C, podemos utilizar punteros. Comenzamos apuntando al primer elemento y frenamos una vez procesado el último elemento:

#include <stdio.h>

int main()
{
  int array[] = { 5, 3, 4, 9, 1 };
  int array_size = sizeof(array) / sizeof(int); // cantidad de elementos de "array"
  int *array_begin = array;                     // comienzo del array
  int *array_end = array+array_size;            // final del array (+un elemento)
  int *it;                                      // el iterator

  for (it = array_begin;  it != array_end;  ++it) {
    printf("%d\n", *it);
  }
  return 0;
}

Hay que tener en cuenta que array_end es igual a &array[5]. Sabiendo que sólo podemos acceder a los elementos desde array[0] a array[4], decimos que array[5] está más allá del último elemento del arreglo, es decir, &array[5] es la posición de memoria que ya no es parte del mismo arreglo (de ahí it != array_end significa “mientras nos encontremos dentro del arreglo”).

¿Cómo recorrer un contenedor de la STL? La idea es similar, sólo que en vez de usar punteros utilizamos iteradores, y observe como la sintaxis del for es exactamente la misma. (Nota: en este caso utilizamos un vector.)

#include <iostream>
#include <vector>

using namespace std;

int main()
{
  vector<int> array;
  array.push_back(5);
  array.push_back(3);
  array.push_back(4);
  array.push_back(9);
  array.push_back(1);

  vector<int>::iterator it;

  for (it = array.begin();  it != array.end();  ++it) {
    cout << *it << endl;
  }
  return 0;
}

¿Cómo recorrer un contenedor STL con el algoritmo for_each? (Nota: Lo siguiente también se puede hacer con copy y ostream_iterator.)

#include <cstdio>
#include <vector>
#include <algorithm>

using namespace std;

void print_element(int a) { cout << *it << endl; }

int main()
{
  vector<int> array;
  array.push_back(5);
  array.push_back(3);
  array.push_back(4);
  array.push_back(9);
  array.push_back(1);

  for_each(array.begin(), array.end(), print_element);
  return 0;
}

La función pasada como tercer parámetro a for_each es llamada por cada elemento del arreglo:

template<typename InputIterator, typename Function>
Function for_each(InputIterator first, InputIterator last, Function f)
{
  for (; first != last; ++first)
    f(*first);
  return f;
}

¿Por qué for_each devuelve la función? Principalmente porque la función f podría no ser una función! Podría ser un functor (objeto función), es decir, una instancia de una clase que tiene sobrecargado el operator() (llamada a función). Pero este tema se merece su propio post.

¿Se puede usar el algoritmo for_each para los arreglos de C? Sí.

#include <cstdio>
#include <algorithm>

using namespace std;

void print_element(int a) { printf("%d\n", a); }

int main()
{
  int array[] = { 5, 3, 4, 9, 1 };
  int array_size = sizeof(array) / sizeof(int); // cantidad de elementos de "array"
  int *array_begin = array;                     // comienzo del array
  int *array_end = array+array_size;            // final del array (un elemento más)

  for_each(array_begin, array_end, print_element);
  return 0;
}

STL generate

2008-12-08T00:00:00+00:00

Si usted tiene una función que genera números/valores/instancias (ej: un generador de números aleatorios, o identificadores) puede usar el algoritmo generate de la STL para crear una secuencia de objetos. Por ejemplo, para generar 100 números (pseudo)aleatorios de 0 a 1:

#include <algorithm>
#include <vector>

double uniform_random()
{
  return (rand() % 10001) / 10000.0;
}

int main()
{
  std::vector<double> v(100);
  std::generate(v.begin(), v.end(), uniform_random);
  return 0;
}

El algoritmo generate recibe dos iteradores (inicio y fin), y llama a la función especificada para cada una de las posiciones que recorre:

template<typename ForwardIterator, typename Generator>
void generate(ForwardIterator first, ForwardIterator last,
              Generator gen)
{
  for (; first != last; ++first)
    *first = gen();
}

Los algoritmos de la STL son genéricos porque utilizan la aritmética de punteros. Los iteradores sobrecargan los operadores para poder ser utilizados como punteros. Así un algoritmo puede ser utilizado con los contenedores de la STL (vector) o con los viejos y tan queridos arreglos (y punteros) de C:

#include <algorithm>

double uniform_random()
{
  return (rand() % 10001) / 10000.0;
}

int main()
{
  double v[100];
  std::generate(v, v+100, uniform_random);
  return 0;
}

¿Preincrementar o postincrementar?

2008-08-19T00:00:00+00:00

Hace mucho que quería escribir un post tan inútil como este. La duda que siempre me pasaba por la cabeza era la siguiente: ¿Será exactamente el mismo código ensamblador el que genera el compilador cuando utilizamos el preincremento o el postincremento (sin utilizar el valor de retorno)? Tenía la seguridad de que así debía ser (una optimización tan básica no podía ser dejada de lado), pero me faltaban las pruebas (en ensamblador) para verificarlo.

Recordando un poco, el preincremento

int a = 0;
int b = ++a;

hace a=1 y b=1, mientras que el postincremento

int a = 0;
int b = a++;

hace a=1 y b=0, esto significa que b obtuvo el valor de a anterior al incremento.

Aquí estamos utilizando el valor de retorno del operador incremento. El código ensamblador es distinto para cada caso. Vamos a echarle una mirada (antes le recomiendo ver este excelente artículo para comprender más sobre el stack y las convenciones de llamadas). En el preincremento el código ensamblador (generado por GCC 3.4.5 para i386) es:

subl  $8, %esp          // reservamos 8 bytes en el stack (para variables locales)
movl  $0, -4(%ebp)      // a   = 0
leal  -4(%ebp), %eax    // eax = &a
incl  (%eax)            // *eax= (*eax) + 1
movl  -4(%ebp), %eax    // eax = a
movl  %eax, -8(%ebp)    // b   = eax

En el postincremento

subl  $8, %esp          // reservamos 8 bytes en el stack
movl  $0, -4(%ebp)      // a   = 0
movl  -4(%ebp), %edx    // edx = a
leal  -4(%ebp), %eax    // eax = &a
incl  (%eax)            // *eax= (*eax) + 1
movl  %edx, -8(%ebp)    // b   = edx

donde se ve que el registro edx se utiliza para guardar el valor que tenía a antes del incremento para luego asignárselo a b.

Pero la pregunta original es, ¿qué pasa si no usamos el valor de retorno? ¿el código de ++i o i++ es igual? Debería serlo, y de hecho, lo es. Pero como veremos más abajo, esto sólo se cumple si utilizamos tipos de datos built-in (int, double, long, etc.). Miremos el siguiente código:

void func() { }
void pre () { for (int c=0; c<8; ++c) { func(); } }
void post() { for (int c=0; c<8; c++) { func(); } }
int main()
{
  pre();
  post();
  return 0;
}

Básico, un for pero con las dos variantes posible de incremento. El código generado para ambos casos (tanto para la función pre como post) es el siguiente:


  pushl %ebp              // guardar el viejo puntero a la base del stack
  movl  %esp, %ebp        // establecer la nueva base del stack
  subl  $4, %esp          // guardar 4 bytes en el stack (para variables locales)
  movl  $0, -4(%ebp)      // c = 0
L3:
  cmpl  $7, -4(%ebp)
  jg    L2                // si c > 7 entonces ir a L2
  call  _func             // llamar a la función func()
  leal  -4(%ebp), %eax    // eax = &c
  incl  (%eax)            // *eax= (*eax) + 1
  jmp   L3                // repetir yendo a L3
L2:
  leave                   // restaurar la base del stack (popl %ebp)
  ret                     // retornar al punto de llamada

Realmente es indiferente usar cualquiera de los dos tipos de incremento, salvo, en los tipos definidos por el usuario. C++ ofrece un soporte para tipos de usuario igual a los built-in (bueno, no del todo, pero lo están solucionando). Nos da la posibilidad de sobrecargar los operadores de nuestros propios tipos (clases). Por ejemplo:

class tipo {
  int x;
public:
  tipo(int y) : x(y) { }
  tipo(const tipo& y) : x(y.x) { }
  // preincremento
  tipo& operator++() {
    ++x;
    return *this;
  }
  // postincremento
  tipo operator++(int) {
    tipo tmp(*this);
    ++x;
    return tmp;
  }
  bool operator<(int y) const { return x < y; }
};

void func() { }
void pre()  { for (tipo c=0; c<8; ++c) { func(); } }
void post() { for (tipo c=0; c<8; c++) { func(); } }

int main()
{
  post();
  return 0;
}

No colocaré el código ensamblador por desbordar belleza, pero el código generado en este caso es distinto: cada incremento llama a la función correspondiente a su operador. Esto es debido a que ambas implementaciones varían considerablemente. Por ejemplo, el postincremento necesita de una instancia extra de tipo para poder devolver el anterior valor de this, en cambio, el preincremento devuelve una referencia al mismo this (sin necesidad de hacer una copia).

Como dato curioso, algo interesante ocurre al utilizar las optimizaciones del GCC. Si compilamos este último programa con el parámetro -O3, vamos a ver que todas las funciones correspondientes a la clase tipo desaparecen, y todo el código resultantes es inline, dando como resultado un código tan óptimo como si hubiéramos utilizado un int en vez de nuestra clase tipo.

¿Cómo obtengo el código ensamblador desde un archivo C/C++?
Con el compilador gcc, hay que utilizar el parámetro -S:

g++ -S -o archivo.s -c archivo.cpp

En archivo.s queda el código ensamblador (sintaxis AT&T).

Excepciones, RAII y auto_ptr

2008-06-24T00:00:00+00:00

Una de las mejores formas de realizar un control de errores es por medio de excepciones. Lamentablemente, si no se toman las precauciones adecuadas, se pueden obtener leaks de algunos recursos. Por ejemplo, imagine el siguiente caso:

int main()
{
  try {
    char *ptr = new char[256];
    double *matrix = new double[100000*100000]; // 74 Gigabytes
    // ...
    delete matrix;
    delete ptr;
  } catch (const std::bad_alloc& e) {
    std::cout << "No hay memoria suficiente" << std::endl;
  }
  return 0;
}

Aquí, con el segundo new una excepción bad_alloc es lanzada. El problema es que la memoria asignada con el primer new nadie la libera. Esto es un memory leak. Una opción para solucionarlo es mediante un bloque finally "a la Java":

int main()
{
  char *ptr = NULL;
  double *matrix = NULL;
  try {
    ptr = new char[256];
    matrix = new double[100000*100000];
    // ...
    delete matrix;
    delete ptr;
  } catch (...) { // finally
    if (matrix) delete matrix;
    if (ptr) delete ptr;
  }
  return 0;
}

Claro que esto no hace al manejo de errores una tarea transparente.

En C++ se puede utilizar la técnica RAII (la adquisición de recursos está en la inicialización), lo que ayuda a evitar leaks. La idea básica detrás de esto es que los constructores obtengan recursos, y los destructores los liberen. Al ocurrir una excepción, se van llamando los destructores de los objetos creados.

Para solucionar nuestro problema, podemos utilizar la clase auto_ptr que se encuentra en <memory>. Un auto_ptr guarda un puntero que es liberado automáticamente en el destructor.

int main()
{
  try {
    std::auto_ptr<char> ptr(new char[256]);
    std::auto_ptr<double> matrix(new double[100000*100000]);
    // ...
  } catch (const std::bad_alloc& e) {
    std::cout << "No hay memoria suficiente" << std::endl;
  }
  return 0;
}

Los deletes no son necesarios. Al salir del ámbito del bloque try, ya sea normalmente o por excepción, se llamará al destructor de los auto_ptrs creados, así no se incurre en ningún tipo de leak.

Advertencia: Los auto_ptr deben ser utilizados sabiendo cuál es su verdadero funcionamiento: La copia de un auto_ptr a otro no los deja equivalentes. La última copia se queda con el puntero, los demás lo van perdiendo, y el delete lo invoca el último auto_ptr destruido. Por ejemplo:

{
  std::auto_ptr<Persona> otra_persona;
  {
    std::auto_ptr<Persona> una_persona(new Persona);
    otra_persona = una_persona;
    // ahora "una_persona" apunta a NULL
  }
} // aquí la persona es destruida

Pregunta: ¿Por qué no usar objetos alojados en el stack en vez del heap para evitar los leaks? Porque el stack es mucho más pequeño. Por ejemplo, el siguiente código provoca un SIGSEGV ya que el arreglo no entra en el stack:

double matrix[1000000];

Pero sí entra en el heap:

double *matrix = new double[1000000]; // 7.6 Megabytes

Compilando archivos

2008-05-10T00:00:00+00:00

Suponiendo que conoce qué es un archivo de código fuente, código objeto, un ejecutable .exe, y el código máquina; voy a pasar a explicar algunos comandos del GCC para compilar.

Retomando la idea del anterior post, imagínese que creamos un archivo timemark.h para darle un poco de portabilidad a todo este asunto de medir el desempeño de una rutina. Las declaraciones de timemark.h pueden ser usadas para crear un pequeño programa ejemplo1.c que sea independiente de la plataforma (por lo menos entre Windows y GNU/Linux).

Vamos a probar algunas operaciones sobre la línea de comandos para ver cómo compilar este archivo. Inicialmente, la opción más sencilla es utilizar directamente "gcc ejemplo1.c", esto nos da como resultado el archivo "a.exe" o "a.out". Veamos (teniendo timemark.h y ejemplo1.c en un directorio C:\ejemplo1):

C:\ejemplo1>gcc ejemplo1.c
C:/Temp/ccMjdaaa.o:ejemplo1.c:(.text+0x31): undefined reference to `get_timemark'
C:/Temp/ccMjdaaa.o:ejemplo1.c:(.text+0x3c): undefined reference to `get_timemark'
C:/Temp/ccMjdaaa.o:ejemplo1.c:(.text+0x4e): undefined reference to `timemark_diff'
collect2: ld returned 1 exit status

Como podrá ver, recibimos un error por las funciones no definidas get_timermark y timemark_diff. Esto se debe a que utilizando solamente "gcc ejemplo1.c", se intenta enlazar el código de ese único archivo en el ejecutable. Tenemos algunas opciones intermedias antes de crear el .exe final. Por ejemplo, podemos crear un archivo que contenga el código objeto ya compilado (pero únicamente del archivo en cuestión ejemplo1.c):

C:\ejemplo1>gcc -o ejemplo1.o -c ejemplo1.c

Así obtenemos el ejemplo1.o (código objeto). En este caso no recibimos errores ya que ejemplo1.o hace referencias a las funciones get_timermark y timemark_diff, pero no necesita su implementación específica. Cuando creamos el ejecutable final (.exe) es cuando realmente necesitamos el código de todas las funciones invocadas.

El archivo que falta es timemark.c. Del mismo modo, podemos compilarlo con el comando:

C:\ejemplo1>gcc -o timemark.o -c timemark.c

Ahora resta unir ambos archivos objetos en un único ejecutable, con un único punto de acceso (main):

C:\ejemplo1>gcc -o ejemplo.exe ejemplo1.o timemark.o

Y listo. Por ahora, lo aprendido son estos dos comandos:

gcc -o archivo.o -c archivo.c
gcc -o archivo.exe archivo1.o archivo2.o archivo3.o ...

El primero compila el código fuente para generar un archivo objeto, y el segundo comando reune (enlaza, linkea) el grupo de archivos objetos en un ejecutable único.

De todas formas, es bastante tedioso escribir estos comandos cada vez que queremos compilar. Para resolver el problema podemos utilizar los llamados Makefiles. Claro, lo más interesante queda para un futuro post.

Medir el tiempo de una rutina

2008-03-01T00:00:00+00:00

¿Alguna vez se preocupó por la velocidad con la que corre su programa? ¿No? Entonces usted es un candidato perfecto para jugar al Java. En caso contrario, voy a explicarle un pequeño código que utilizaremos en próximas entregas para medir el tiempo de ejecución de determinadas rutinas.

Ya lo dijo alguien: "La optimización prematura es la raíz de todos los males". No hay nada más cierto, aunque también es verdad que hacer algo simple de la peor forma posible, es la causa de otros grandes males. Con esto quiero decir que debería intentar hacer las cosas de la forma más simple y más óptima que usted conozca (dándole mayor importancia a la simplicidad del código); luego se preocupa por "darle velocidad" a la rutina que provoca el cuello de botella (en próximos posts veremos cómo usar gprof para detectarlo).

La forma de calcular el tiempo de CPU que toma una función es muy simple:

tomamos el valor del reloj antes de realizar la llamada (t_ini),
llamamos a la rutina en cuestión, y
tomamos nuevamente el valor del reloj (t_fin).

La diferencia entre t_fin - t_ini nos da el total de tiempo que tomó: 1) hacer la llamada a la rutina, 2) que esta haga su trabajo, 3) que devuelva el resultado.

Ahora hay algunos pequeños detalles de implementación. Por ejemplo, ¿qué función usar para tomar el tiempo del reloj? Y más importante, ¿qué precisión obtenemos con dicha función?

Para tomar el tiempo podemos usar la rutina clock(), que devuelve el tiempo aproximado de CPU que transcurrió desde que nuestro programa fue iniciado, dicho tiempo representado en un valor de tipo clock_t: un valor entero que indica una cantidad de "tics" de reloj.

La precisión que tenemos con dicha rutina es de CLOCKS_PER_SEC (tics de reloj por segundo), lo que significa que por cada segundo que pasa, la función clock() nos devolverá CLOCKS_PER_SEC unidades más que el valor anterior. En MinGW, CLOCKS_PER_SEC es igual a 1000, pero es mejor no fiarse de esto, ya que en otras plataformas dicho valor varía. Inclusive, según POSIX, la constante CLOCKS_PER_SEC debería ser 1000000.

Veamos algo de código:

#include <stdio.h>
#include <time.h>

int main(int argc, char *argv[])
{
  clock_t t_ini, t_fin;
  double secs;

  t_ini = clock();
  /* ...hacer algo... */
  t_fin = clock();

  secs = (double)(t_fin - t_ini) / CLOCKS_PER_SEC;
  printf("%.16g milisegundos\n", secs * 1000.0);
  return 0;
}

Con esto podemos medir cuántos milisegundos demoró "hacer algo". Todo parece muy bonito hasta que nos damos cuenta de dos grandes problemas:

Tomar una medida única y aislada es igual que tomar un número completamente aleatorio y mostrarlo (no es una muestra representativa). Es mejor repetir las mediciones unas cuantas veces (y hablo del orden de las 100, o 100000, o 1e32 veces), y luego sacar un promedio de todo.
La función clock() no llega a tener una precisión ni de 10 milisegundos (aunque CLOCS_PER_SEC sea 1000 o más).

Una vez dicho esto, el código de arriba no sirve ni para limpiarse los trastes... Así que tenemos que buscar una función con mayor precisión, y además, promediar varias muestras.

Existen otras alternativas como la función gettimeofday, pero bajo Windows sufre del mismo problema de precisión que clock(). Igualmente en Linux funciona perfectamente, así que vale la pena tener en cuenta este código:

#include <stdio.h>
#include <time.h>
#include <sys/time.h>

/* retorna "a - b" en segundos */
double timeval_diff(struct timeval *a, struct timeval *b)
{
  return
    (double)(a->tv_sec + (double)a->tv_usec/1000000) -
    (double)(b->tv_sec + (double)b->tv_usec/1000000);
}

int main(int argc, char *argv[])
{
  struct timeval t_ini, t_fin;
  double secs;

  gettimeofday(&t_ini, NULL);
  /* ...hacer algo... */
  gettimeofday(&t_fin, NULL);

  secs = timeval_diff(&t_fin, &t_ini);
  printf("%.16g milliseconds\n", secs * 1000.0);
  return 0;
}

Como puede ver la estructura timeval contiene dos campos, segundos y microsegundos transcurridos (tv_sec y tv_usec respectivamente), por lo tanto ofrece una precisión de microsegundos. De todas formas, como decía esto en Windows no sirve y la razón es sencilla, en la misma MSDN explican que el temporizador del sistema corre aproximadamente a unos 10 milisegundos, por lo tanto, cualquier función que lo utilice nos estará dando la misma asquerosa precisión (inclusive al utilizar GetSystemTimeAsFileTime y FILETIME). Por lo tanto la solución es utilizar lo que se conoce en el mundo de Windows como el "contador de rendimiento de alta resolución" (high-resolution performance counter):

#include <stdio.h>
#include <windows.h>

/* retorna "a - b" en segundos */
double performancecounter_diff(LARGE_INTEGER *a, LARGE_INTEGER *b)
{
  LARGE_INTEGER freq;
  QueryPerformanceFrequency(&freq);
  return (double)(a->QuadPart - b->QuadPart) / (double)freq.QuadPart;
}

int main(int argc, char *argv[])
{
  LARGE_INTEGER t_ini, t_fin;
  double secs;

  QueryPerformanceCounter(&t_ini);
  /* ...hacer algo... */
  QueryPerformanceCounter(&t_fin);

  secs = performancecounter_diff(&t_fin, &t_ini);
  printf("%.16g milliseconds\n", secs * 1000.0);
  return 0;
}

En este caso, imagine que QueryPerformanceCounter es como clock() y QueryPerformanceFrequency es como CLOCKS_PER_SEC. Es decir, la primera función nos da el valor del contador, y la segunda su frecuencia (en ciclos por segundo, hertz). Cabe aclarar que un LARGE_INTEGER es una forma de representar un entero de 64 bits por medio de una unión (union).

Como tarea al lector, si es que existe alguno, le queda hacer una versión "portable" (entre Windows y Linux) para medir el rendimiento (con unos cuantos #ifdef WIN32 y #endif sería suficiente).

18 de Marzo del 2008: acá transcribo una macro que me pasó el amigo Carlos Becker para medir el tiempo de una rutina en Linux mediante clock_gettime:

#define TIME_THIS(X)                                         \
  {                                                          \
    struct timespec ts1, ts2;                                \
    clock_gettime( CLOCK_REALTIME, &ts1 );                   \
    X;                                                       \
    clock_gettime( CLOCK_REALTIME, &ts2 );                   \
    printf( #X " demora: %f\n",                              \
      (float) ( 1.0*(1.0*ts2.tv_nsec - ts1.tv_nsec*1.0)*1e-9 \
      + 1.0*ts2.tv_sec - 1.0*ts1.tv_sec ) );                 \
  }

/* podemos usarla así */
{
  double x, y, z;
  x = 2.0;
  y = 4.0;
  TIME_THIS(z = sqrt(x*x + y*y));
}

Lo que da como resultado:

z = sqrt(x*x + y*y) demora: 0.015164

Conseguir un compilador

2008-02-17T00:00:00+00:00

Editado 21 de mayo 2011: Este post se encuentra aquí sólo a fines históricos, ahora usted puede usar el instalador automático de MinGW.

Editado 9 de septiembre 2010: Aunque este post contiene información útil de cómo instalar MinGW con gcc 3.4, tal vez prefiera antes probar este nuevo post sobre cómo descargar MinGW con gcc 4.5 de forma automática.

En este blog vamos a hablar sobre los lenguajes de programación C y C++, y cómo usar software GNU para hacer aplicaciones. También voy a tratar de investigar algo de ensamblador.

De todas formas, para evitar hacer un primer post completamente inútil "de presentación", voy a pasar a explicarles cómo pueden instalar un compilador gratuito en Windows desde cero, y hacer un pequeño programa "Hola Mundo" sin pensar mucho (eso sí, van a tener que leer un poco). El proceso para Linux es más sencillo, ya que el compilador suele venir instalado por defecto en la mayoría de las distribuciones.

Primero, algunas definiciones importantes:

MinGW: Un conjunto de programas y bibliotecas que permiten crear aplicaciones para Windows.
GCC: El compilador. Transforma código escrito en C/C++ a un archivo ejecutable (.exe). En realidad hace miles de maravillas más, pero por ahora nos vamos a quedar con esta definición.
MSYS: Es un conjunto mínimo de programas para poder ejecutar scripts "a la" Unix. Además incluye una terminal que emula un pequeño entorno GNU/Linux.
Emacs: La madre de los editores de texto. Alguna vez dije que era una porquería o muy complicado, y que conviene usar editores como el RHIDE o Setedit. Bueno, la cosa es que con "un poco" de práctica uno comprende el poder de esta herramienta.
make: Un programa que puede compilar muchos archivos y linkearlos en un ejecutable de forma automatizada (siempre y cuando le escribamos un archivo con las órdenes adecuadas). Generalmente los programadores están acostumbrados a utilizar un IDE (como el DevC++) que maneje el proyecto, calcule las dependencias entre archivos, compile todo lo necesario, linkee, ejecute y depure. Si bien esto es cómodo, espero poder enseñarles a automatizar la compilación y liberarlos de un determinado IDE para compilar los programas.
cmd.exe: Es la línea de comandos de Windows. Si nunca lo utilizó, es hora que se ponga a usarlo. Para iniciar la línea de comandos debe ir al menú "Inicio/Ejecutar..." e introducir "cmd". ¿Cómo se usa? Bueno, empiece a buscar...

Ahora nos dedicaremos a instalar el MinGW, para eso debe comenzar a bajarse los siguientes archivos (si no sabe cómo descomprimir un archivo .tar.gz...):

mingw-runtime-3.13.tar.gz: Los archivos de cabecera y bibliotecas estándares (stdio.h, math.h, libc, libm, etc.)
w32api-3.10.tar.gz: Archivos de cabecera del API de Win32
gcc-core-3.4.5-20060117-1.tar.gz: El preprocesador de C y el compilador de C
gcc-g++-3.4.5-20060117-1.tar.gz: El compilador de C++ y los archivos de cabecera de C++
binutils-2.17.50-20060824-1.tar.gz: Varios programas utilitarios que sirve para diferentes propósitos (ej: quitar símbolos de depuración con strip, convertir direcciones a líneas de código fuente con addr2line, procesar la información de rendimiento con gprof, crear librerías con ar, compilar los archivos de recursos de Windows con windres, etc.).
mingw32-make-3.81-2.tar.gz: La utilidad make
gdb-5.2.1-1.exe: El depurador de código

Una vez que consiga todos estos archivos, debe crear una carpeta C:\MinGW (le recomiendo esa ubicación) y descomprimir todo ahí mismo. Para instalar el depurador (gdb) deberá ejecutar el instalador, seguir los pasos, y colocar como carpeta de instalación "C:\MinGW".

Una vez instalado todo, usted ya está en condiciones para compilar código en C o C++. Antes verifique que en dicha carpeta tiene una estructura de directorios como la siguiente:

C:\MinGW
  bin\
  doc\
  include\
  info\
  lib\
  libexec\
  man\
  mingw32\

Si así es, significa que todo salió bien (bueno, tampoco descomprimir unos archivos es algo tan complicado).

Para estar seguros que el compilador funcione, vamos a crear el programa de prueba por excelencia, el "Hola Mundo". Abra el bloc de notas (Inicio/Ejecutar/notepad) y escriba en un archivo el siguiente código:

#include <stdio.h>

int main(int argc, char *argv[])
{
  printf("Hola Mundo\n");
  return 0;
}

Guarde el archivo como "C:\MinGW\hola.c". Ahora abra la línea de comandos cmd.exe, y ahí mismo ejecute los siguientes comandos:

cd C:\MinGW
set PATH=C:\MinGW\bin;%PATH%
gcc hola.c

Verá que el archivo "a.exe" se crea en el directorio C:\MinGW. Si ejecuta el programa a.exe visualizará en la salida de la consola el mensaje más estúpido jamás escrito: "Hola Mundo"

C:\MinGW>a.exe
Hola Mundo

A continuación le paso a explicar qué hicimos en esta ráfaga de pasos:

"cd C:\MinGW" es para ubicarnos en el directorio donde se encuentra el archivo o proyecto que queremos compilar (si no sabía esto, es porque todavía no estuvo buscando cómo usar cmd.exe...).
"set PATH=C:\MinGW\bin;%PATH%" es un conjunto de varias cosas: "PATH" es una variable de entorno que indica cuáles son los directorios donde podemos encontrar archivos ejecutables (archivos ejecutables como gcc.exe, cpp.exe, etc.); "set" es un comando del shell para cambiar el valor de una variable de entorno; y "%PATH%" devuelve el valor de dicha variable de entorno. Por lo tanto, lo único que estamos haciendo aquí es agregar una nueva ruta (C:\MinGW\bin) a PATH para que el shell encuentre los archivos ejecutables que a nosotros nos interesa (el preprocesador, compilador, etc.). Si desea ver dónde busca el shell los archivos ejecutables actualmente, puede usar el siguiente comando: "echo %PATH%"
"gcc hola.c" compila el programa "hola.c" y deja el resultado (linkea o linkedita) en un archivo llamado "a.exe" (o "a.out" en Linux). En otros posts veremos cómo podemos especificar un nombre distinto a este archivo de salida.

De todo lo visto, lo más molesto es la configuración de la variable de entorno, es decir, si pensamos compilar varias veces, cada vez que abramos un shell (cmd.exe) deberemos hacer un "set PATH=C:\MinGW\bin;%PATH%". Para evitar este paso tenemos dos opciones:

Si tiene accesos de Administrador, puede hacer click derecho sobre "Mi PC", "Propiedades", "Opciones Avanzadas", "Variables de Entorno" y modificar la variable PATH agregándole el valor "C:\MinGW\bin" (recuerde no tocar las demás rutas, además de agregar un ";" para separar las distintas rutas entre sí).
En otro caso, puede crearse un archivo de comandos por lotes mi-mingw.bat para iniciar el shell adecuadamente con el PATH ya configurado. Por ejemplo, un mi-mingw.bat posible podría ser:
```
set PATH=C:\MinGW\bin;%PATH%
start cmd.exe
```
Este archivo podemos dejarlo en el Escritorio y cada vez que tengamos ganas de compilar, con un simple doble click ya podemos empezar. Inclusive, en vez de iniciar "start cmd.exe" podríamos iniciar algún IDE o editor de texto como Emacs. Pero eso para otro post.

Bueno, por hoy me cansé. Cualquier problema o pregunta que tengan, los comentarios están abiertos (y bien moderados :)