Archive | programación RSS feed for this section

Un sistema universal de timestamps

Será que ya existe en internet algo parecido a un servicio que permita dejar registro de que, al momento de crear ese registro, uno está en posesión de tal o cual documento?

Caso de uso:

Juanito debe entregar un ensayo a su profesor de economía a mas tardar el lunes. El internet de Juanito esta caido y Juanito está enfermo y no podrá ir a la universidad el lunes. Juanito verá a su profesor el miercoles siguiente y podra entregarle el ensayo ese día en una llave USB, pero debe demostrar que lo que está entregando el miercoles ya estaba terminado el domingo. La fecha del archivo en el disco no es suficiente, ya que es facil de manipular. Hay una solucion sencilla: Juanito le envia el lunes al asistente del profesor, por medio de un mensaje de texto, un hash del contenido del archivo. El miercoles, el profesor puede comparar lo que juanito entrega con el hash que envió el lunes, lo que prueba que el archivo que está entregando es el mismo que ya Juanito había terminado ese día.

En resumen, si A necesita dejar registro de que esta en posesion de un cierto contenido, basta con que un garante verifique y registre el hecho y el momento en que lo hace ( en el ejemplo anterior, el garante es el asistente del profesor). No es necesario que el garante guarde el contenido completo, ni siquiera que lo conozca. Basta con que guarde el hash del contenido, el cual puede ser usado cuando un tercero necesite verificar que ese contenido ya existía como mínimo desde el momento en que la entrada en registro fue creada. Adicionalmente, se puede garantizar la identidad de la persona que crea el registro, por medio de llave publica/privada, para verificar que el contenido existia y estaba en posesión de esa persona. Alguna organización lo suficientemente confiable debería crear un sistema que permita guardar ese tipo de registros, muy sencillo de implementar ya que no se necesita conservar el contenido de los documentos en cuestión (lo cual es responsabilidad del dueño del contenido, obviamente si el contenido se pierde, el registro no sirve para nada).

Creo que podrían existir muchos usos. Por ejemplo, si alguien crea una imagen y la publica en internet, podría primero crear un registro en ese sistema, para probar, como minimo, que a tal fecha, el ya estaba en posesión de esa imagen, lo que podría ser util si alguien decide “robarse” la autoría.

Ya existe algo así o algo que cumpla la misma función?

TweetMix

Hagamos un recuento desordenado de TweetMix. La idea se me ocurrió hace un par de semanas: coger un “chat-bot“, alimentarlo con los tweets de un usuario y ponerlo a decir bobadas. El chat-bot que usé fue escrito en perl y funciona al estilo de mega-hal, un viejo chat-bot con el que Alejo, Javier y yo jugabamos hace ya mas de diez años, cuando el internet todavía tenía gracia. Si quieren documentarse al respecto pueden buscar por cadenas de Markov. Hice una primera implementación en alrededor de una hora, usando bash, el API sin autenticación de twitter y unas cuantas herramientas de linea de comando de unix (curl, recode, cut, etc). La idea resulto buena y al cabo de un par de horas ya cerca de 150 personas le estaban sacando incongruencias a sus cerebros artificiales.

Twitter solo permite un numero limitado de hits por hora, lo que se convirtió en el primer obstaculo para que más gente usara el sitio. Muy rápido, la aplicación estaba llegando al limite en cada intervalo, así que tuve que apagarla. Decidí hacer una implementación que superara esta limitación para de paso jugar con las técnicas asociadas. Escribí entonces una nueva implementacion en lisp, usando una librería de oauth. En pocas palabras, esto permite acceder a twitter a nombre de cada usuario, multiplicando así el limite de hits por hora por el número de usuarios. Como no hay nada complicado en el programa, en unos dias de trabajo muy esporadico saque una nueva version, que volvió a tener bastante exito.

El siguiente obstaculo fue hacer el programa suficientemente robusto para soportar la alta demanda. El problema aqui era que obtener los datos de twitter y transformarlos y procesarlos es un proceso que toma tiempo y que se realiza en un proceso aparte, un llamado a perl. Esto hacia que el servidor web de lisp despachara demasiados hilos, lo que estaba terminando mal. Aplicamos entonces dos ideas. La primera fue idea de fidel: en vez de generar una frase por cada request, generar bastantes de un solo golpe e irlos consumiendo poco a poco. Así disminuimos drasticamente el número de procesos a lanzar por cada carga de la página. Comenzamos a usar redis para guardar los mixs en vez de tenerlos en el espacio de memoria del servidor web. La segunda idea fue extraer del servidor web el proceso de obtención y procesamiento de los tweets de cada usuario. Asi, cuando un usuario nuevo llega, el servidor web pone en una cola el nombre del usuario y uno (o varios) proceso aparte va tratando los diferentes nombres de la cola. Aprovechamos el redis para implementar la cola de demandas. De esa manera mantenemos bajo control el número de procesos y liberamos al servidor web de los problemas asociados con ese tratamiento. El código de tratamiento de tweets lo re-escribió Fidel en Perl. Algo que hay que notar es que los llamados a twitter fallan muy muy frecuentemente. La alta frecuencia de este tipo de problemas (los errores al llamar a un servicio exterior) es una de las dificultades particulares que enfrenta el programador en la red.

En paralelo, Juan Diego hizo un excelente diseño que es el que usamos actualmente.

Luego de un estallido de popularidad inicial, las visitas han bajado bastante, pero el uso sigue siendo importante. A la gente le gusta. Creo que puede volverse mas popular aún.

Viendo por encima, es un programa muy muy sencillo, pero que de cierta manera ilustra bien el tipo de estrategia que se puede usar en sitios de alto tráfico. Cosas cheveres que se descubrieron: redis y oauth. Igualmente he podido jugar con los amazon web-services, que me parecen bastante prácticos y muy bien implementados, pero ligeramente caros (sobre todo el costo en ancho de banda de S3).

Ventanas, Dialogos, Botones

El siguiente caso ilustra bien las diferencias de éstilo que veo entre los mundos java y .Net.

En la librería para aplicaciones gráficas de .Net, un programa puede abrir cualquier Ventana en modo Dialogo. Todos los Botones tienen asociado un atributo llamado DialogResult. Cuando este atributo tiene un valor en un botón que es oprimido, la Ventana que contiene el botón, si está en modo Dialogo, se cierra y retorna el valor asociado al botón.

Para un programador acostumbrado al estilo predominante en el mundo Java, esta manera de implementar ventanas de dialogo parece poco elegante por las siguientes razones:

  • Una Ventana de Dialogo es solo un caso particular del concepto abstracto de Ventana. De ninguna manera el comportamiento propio de ese caso particular debe incluirse en la definición  del caso general. Lo adecuado sería definir un tipo particular de Ventana que se haga cargo de esa funcionalidad especial.
  • Peor aun, el comportamiento de un caso particular de Ventana no tiene por que hacerse visible en el tipo Botón. Un botón es teoricamente un concepto independiente al de Ventana y aún más independiente del muy particular concepto de Ventana de Dialogo.

En resumen, hay cosas que no están en su lugar. Para el programador de Java, al esquema usado por .Net le hacen falta un par de clases para conservar la limpieza conceptual de cada clase.

C# acepta contaminar las clases Ventana y Botón con el fin de ofrecer la funcionalidad de una ventana de dialogo. A cambio, no necesita agregar nuevas clases, con lo cual logra mantener una estructura de clases sencilla. En contraste, en el mundo de Java se privilegia la pureza de cada clase individual sobre la simplicidad de la estructura de clases.

Pero la diferencia fundamental en mi opinión es que, en el espiritú de java, la funcionalidad de ventana de dialogo no merece ninguna consideración particular al diseñar las clases mas abstractas de una librería. En el espiritú, mucho mas pragmático, de c#, el hecho mas importante es que un diálogo es el caso más frecuente de uso de una ventana, lo cual lo hace merecer el tratamiento privilegiado.

Crítica de los IDEs (segunda parte)

Inspirado por un buen comentario de Manuel Cerón, estuvé pensando un rato sobre las verdaderas razones por las cuales usar eclipse no me llega a parecer del todo placentero. El primer comentario de Manuel es bastante acertado: el tiempo de arranque de eclipse es irrelevante dado que arrancar eclipse es algo que se hace muy raramente. En mi caso, por ejemplo, usualmente lanzo eclipse el lunes en la mañana y lo vuelvo a cerrar el viernes en la noche. Al trabajar en java en eclipse, uno hace todo a partir de eclipse, todo el tiempo, por lo cual tiene sentido que eclipse permanezca abierto todo el tiempo, dominando toda la pantalla.

Creo que este último punto esta en la base de mi principal problema con eclipse (y en general los IDEs): para cumplir su promesa de facilitar la tarea de escribir codigo, eclipse exige una especie de entrega total. Parafraseando al Duce Mussolini, Todo en eclipse, nada por fuera de eclipse. Eclipse se hace cargo de todos los detalles peludos del asunto, a cambio de que uno renuncia a la posibilidad de meterle mano en la mitad a la cadena de herramientas y pasos involucrados. Por la misma razón, es dificil introducir una herramienta externa al manejo de un proyecto sin introducir perturbaciones que eclipse es incapaz de tratar correctamente.

Manuel señala correctamente que el refactoring es solo una de las facilidades de edición que ofrece eclipse, al lado de otras estilo auto-expansión del código o el navegar a la definición de una función desde una referencia a ella (esto ultimo lo ofrece emacs en C desde tiempos inmemoriales). En mi opinión las funciones de refactoring son tal vez las funciones de edición mas sofisticadas de eclipse y se me ocurre que es posible que para Python (el lenguaje de preferencia de Manuel) sean menos avanzadas que para java. Esto me conduce a pensar en otro punto, de bastante menor importancia y por el cual no se puede culpar a eclipse, y es el hecho de que en general me parece que los paquetes oficiales son de muchisima mas calidad que los no-tan-oficiales. Por ejemplo, el soporte a CVS es brutalmente bueno, mientras que para GIT no existe nada siquiera aceptable.

Crítica de los IDEs

Durante los últimos dos años he usado eclipse constantemente en mi trabajo. Aca van un par de reflexiones sobre esta herramienta de desarrollo y en general sobre todas las herramientas de ese estilo (conocidas como IDEs, por las siglas en inglés de Ambiente de Desarrollo Integrado).

Poco ligero: Eclipse no es una herramienta ligera. Lanzarla, aun en un computador reciente, toma un tiempo considerable. Mas vale tener un equipo con bastante memoria.

Facilidad de uso: Los entusiastas de las interfaces de usuario gráficas defienden las IDEs por su supuesta facilidad de uso. A mi en cambio me parece que eclipse es todo menos facil de usar.

La programación es un proceso relativamente complejo que involucra diversas actividades (edición, compilación, debugging,…). Cada una de estas actividades involucra diferentes pequeñas acciones y una gran cantidad de parametros. En suma, se trata de una enorme cantidad de elementos que el programador debe conocer. En eclipse, todos estos elementos inundan la pantalla al tiempo, logrando más confundir que simplificar la tarea global.

Refactoring: Por otro lado, las herramientas para hacer refactoring de eclipse me parecen muy utiles. Eclipse “entiende” el código que se esta editando y permite automatizar cosas como convertir un pedazo de código al interior de un método en un método separado, o actualizar todas las referencias a una clase a la que se le cambió el nombre.

Ventanas rotas

La teoría de las ventanas rotas sostiene que mantener la pulcritud de un vecindario ayuda a prevenir el vandalismo y otras formas de mal comportamiento. La idea es que una persona se sentirá mas culpable de romper una ventana de un edificio en perfecto estado que de romper una ventana en un edificio que ya tiene varias ventanas rotas. De esto se desprende entonces que para mantener un  vecindario en buen estado hay que reparar rapidamente los pequeños daños que aparecen constantemente, por mínimos que parezcan.

He notado que lo mismo es cierto con el código fuente de un programa, es importante mantener pulcro el código aún en sus pequeños detalles (por ejemplo la indentación, etc) para evitar su degeneración en una masa de código dificil de mantener.

‘Tinkering’, bricolaje, cacharreo

Los usuarios de computador necesitan conocer cada vez menos la manera como un computador funciona. Si las tripas de la máquina se vuelven cada día más invisible, esto se debe a que el usuario puede ahora controlar el computador usando interfaces gráficas avanzadas. Estas interfaces permiten controlar el computador usando imagenes que representan objetos fisicos (botones, ventanas, etc).

Comparemos esto con lo que había hace un par de decadas. En ese entonces, el usuario controlaba el computador escribiendo comandos que la máquina ejecutaba. Pienso por ejemplo en el Commodore 64 en el cual para cargar y ejecutar el primer programa de un diskette había que escribir:


load "*", 8, 1

… algo que parecía (y parece) brujería.

En los primeros PCs, que usaban el sistema operativo DOS, los usuarios tambien tenían que escribir comandos. También había que entender, más que ahora, detalles sobre los archivos y los directorios.

Aunque uno puede encontrar primitivas esas interfaces, algo bueno que tenían era que exponían el computador como lo que es: una máquina programable. El commodore 64 por ejemplo venía con un interprete de basic a disposición del usuario apenas éste prendía el computador. A punta de jugar con los diferentes comandos que aparecían en el manual, un niño podía comenzar a intentar cambiar una o dos cosas y luego a leer mas a fondo los manuales para entender como hacer cosas mas avanzadas. Creo que gracias a eso, miles de niños y jovenes aprendieron los rudimentos de la programación. Todo a punta de “cacharrear” la maquina, urgando aquí y alla. Eran máquinas que no intentaban esconder gran cosa, todo lo opuesto a, digamos, el iPhone.

La claridad que tenía la gente del computador como una máquina programable se veía reflejada también en los libros. Algo chevere por ejemplo erán los libros que contenian juegos en basic para que los niños los copiaran en sus commodores 64. Creo que ya no existe nada parecido. Ahora la noción de programador y usuario están claramente separadas.

El mundo del “cacharreo” informatico hoy en día se ha desplazado (como todo) de los computadores personales a la web. Debe haber mucha gente que a aprendido a programar siguiendo el siguiente camino: copiar un manojo de HTML para crear una página web. Cambiar una o dos cosas. Aprender un poco mas de HTML y finalmente aprender PHP para poder generar páginas dinámicas.

P.S.: Acabo de leer este excelente artículo de Cory Doctorow sobre el iPad. Es relacionado con los temas que toca este post.

Powered by WordPress. Designed by Woo Themes