4.27.2011

Ejercicio para gente que no desarrolla

Este es un ejercicio para que lo realicen a modo de prueba la gente relacionada con el desarrollo de software pero que no desarrollen. No te llevará ni un minuto. Asegúrate que estás solo y sin distracciones.

Pasos:

1.- plantea una suma de dos números de 10 cifras, en una hoja de papel, como lo hacíamos cuando estábamos en el colegio

2.- hazla con tranquilidad, cronometrándote. Cuando termines, anota el tiempo

Te planteo ahora dos retos:

Reto 1: Ahora plantea otra suma, pero entre columna y columna que sumas, cuenta de 1 a 5. Cronometrate y compara con el tiempo anterior

Reto 2: Plantea ahora dos sumas de números de 10 cifras. Haz las dos sumas, pero salta de una suma a otra cada 2 columnas. Al igual que antes cronometrate.

Reto Bonus: Planteate otra suma y dile a alguien que cada dos números te haga una pregunta simple, por ejemplo, tu numbre, apellido, calle donde vives o número de DNI.

Y este post no tiene nada que ver con las sumas :)

4.08.2011

whitebrd.me - detalles técnicos

El pasado fin de semana (primero de abril del 2011 por si lees esto en un futuro lejano) organizamos alltogethernow, un encuentro de un fin de semana para hacer una aplicación en 48 horas. La aplicación que hicimos nosotros (@flopezluis y yo)fue whitebrd.me, una pizarra compartida en tiempo real. Voy a dar una pinceladas de los detalles técnicos y un pequeño post-morten después de 1 semana funcionando.

Para empezar optamos por usar toda la tecnología del servidor asíncrona. Pensarás que lo hicimos porque es lo que mola, ahora lo asíncrono está en todos lados, si no tienes algo asíncrono no puedes montar algo como dios manda... si toda la gente que se le llena la boca con "asíncrono" hubiese leído la famosa (en mi época) "beej's socket guide"... :).

El caso es que tornado, un pequeño framework web creado por friendfeed (después comprada por facebook) y ahora matenido por facebook, hizo las veces de servidor web y redis como sistema de persistencia. La elección de redis fue por dos razónes. La primera por hypearnos a más no poder y la segunda es que permite escribir muy rápido, tiene funcionalidad de publisher/sibscriber y un sistema de VM que encaja muy bien (luego veremos cómo). Para rematar usamos nginx como frontend. Se puede ser más asíncrono? :)

La razón para usar asíncrono realmente es muy sencilla: es una aplicación con MUY poca carga de CPU y mucha E/S, así que el paradigma encaja perfectamente.

En la parte de cliente usamos websockets para enviar todos los comandos y canvas para dibujar. Es una tecnología novedosa, así que sabíamos que muchos navegadores no lo soportarían (FF4 lo tiene desactivado por defecto, primer #FAIL).

Manos a la obra, nos pusimos y en 48 horas teníamos el código en cuestión. Más que comentar el código, prefiero centrarme en las cosas que han pasado en estos días y algunas conclusiones técnicas que he sacado.

- El segundo día a la gente de github les dio por poner un enlace en su blog. No sé cual será el tráfico de ese blog, pero en el nuestro generó 4.5Gb de tráfico en 12 horas. Iluso de mi, no había activado la memoria virtual en redis, de forma que redis no podía tirar a disco las pizarras ya no usadas (se almacenan todos los comandos que genera una pizarra), así que empezó a "swapear" como un demonio. Suerte que teníamos el deploy automático, así que la activé rápido y medio solucionado. Finalmente la clave que almacenaba esa pizarra terminó con más de 20mb de datos. He tenido que eliminarla porque el VPS de 256mb no da para mucho más :). La CPU de la máquina no pasó de un 8%.

- tornado funciona excepcionalmente bien, además de ser un framework muy interesante para cosas "sencillas" (no tiene ORM por ejemplo) es realmente rápido. Además el nucleo es fácil de entender y está bien documentado. Podríamos haber optado por twisted, gevent o algún otro sistema asíncrono en python.

- tratamos de usar el mecanismo pub/sub de redis, pero la librería asíncrona cliente redis para python es completamente inestable, así que terminamos por implementar lo misma funcionalidad en una pequeña clase . Moraleja: a veces la solución más simple es la mejor.

- no conocía redis, pero es realmente un descubrimiento. Funciona muy bien: el setup es muy rápido, prácticamente configuración 0, la integración con los tipos de python buena y además rápida. El model de memoria virtual encaja muy bien ya que si es necesaria más memoria las claves que no se usan las vuelca a disco, de forma que todas las pizarras que ya no se usan no están malgastando los 256mb memoria.

Ahora mismo hay más de 1000 pizarras creadas y la mayoría de ellas tienen dibujos de aparatos reproductores masculinos :)