Canonical Voices

What Bitácora de Vuelo talks about

Posts tagged with 'python'

facundo


(there is an English version of this post, here)

Python tiene una biblioteca estándar muy extensa ("viene con las pilas incluídas"), pero es frecuente la necesidad de usar otros módulos que están afuera de la misma, casi siempre desde el Índice de Paquetes de Python (PyPI).

La manera original de instalar esos módulos es a "nivel de sistema" (sudo pip install foobar), en el sistema operativo de forma general, habilitándolos para ser utilizados por cualquier programa que se ejecute.

Más allá de necesitar permisos de root o administrador para instalar las dependencias de esta manera, el primer problema con el que nos encontramos es el de conflictos: el caso típico de dos programas que necesitan la misma dependencia pero en versiones distintas, lo cual no puede lograrse al instalar las dependencias en forma global.

Por eso es que es tan normal en el mundo de Python usar "entornos virtuales". Se crea un entorno virtual para cada programa, se instala las dependencias necesarias para cada programa en cada entorno virtual, y como lo que instalamos en ese entorno es sólo accesible desde dentro del entorno, no hay más conflictos.

En este punto, sin embargo, aparece el problema de la administración de los entornos virtuales: crearlos, instalarles cosas, activarlos para usarlos con cada programa y desactivarlos luego, recordar los nombres de cada entorno para cada programa, etc.

Para automatizar esto nació fades.

fades les permite utilizar todo el poder de los entornos virtuales sin tener que preocuparse por ellos.

¿Quieren ejecutar un script que necesita la dependencia foobar?

    fades -d foobar script.py

¿Quieren un intérprete interactivo teniendo foobar instalado como dependencia?

    fades -d foobar

¿Necesitan ejecutar el script pero con varias dependencias, alguna en una versión específica?

    fades -d foo -d bar -d baz==1.1 script.py

¿Tienen todas las dependencias en un archivo de requerimientos?

    fades -r requirements.txt script.py

Esto es sólo lo más sencillo que podés hacer con fades. Los entornos virtuales son una herramienta poderosísima, y automatizar y simplificar su uso hace que fades tenga bastantes opciones, algunas que usarán todos los días, y otras que les van a resultar muy útiles en casos puntuales.

Empiecen a usar fades de a poco (acá tienen toda la documentación) y van a encontrar que van a tener resuelto el tema de la administración de dependencias en programas y scripts, usando entornos virtuales pero sin la complejidad de tener que hacerlo directamente y a mano.

Read more
facundo


¿Qué es?

La CDPedia es la Wikipedia Offline. O sea, la Wikipedia, lo más fiel posible a su formato y contenido original, pero armada (construida, compactada) de una manera que no se necesita nada de Internet para acceder a toda la info de la misma.

Se llama CDPedia porque la idea original era meterla en un CD. Hoy por hoy generamos cuatro imágenes en cada liberación de CDPedia: un CD, un DVD, y dos archivos comprimidos (uno mediano y otro grande) que se pueden poner en un pendrive o en cualquier disco rígido.

La CDPedia es multiplataforma: el mismo CD, DVD o archivo comprimido se puede usar en Linux, Windows, o Mac, sin necesitar nada instalado previamente por fuera de lo que cada sistema trae normalmente.

CDPedia


¿Cómo se usa? ¿Cómo se ve?

Para usarla, lo primero es descargarla. Pueden acceder a la página del proyecto y ahí encontrarán info acerca de las cuatro versiones que tenemos actualmente, con el detalle de cuantas páginas y cuantas imágenes tiene cada una. Para bajarlo, necesitan un cliente de Torrent; para Linux a mí me gusta mucho el Deluge, que también puede usarse en Windows y Mac; otro cliente recomendado para las tres plataformas es qBittorrent.

Si descargan la versión CD o DVD, lo primero que tienen que hacer es grabarlo a un disco virgen, para lo cual necesitan una grabadora y un software para grabar. Si usan Windows y no tienen ninguno instalado, les recomiendo InfraRecorder que es software libre y muy fácil de usar. Pongan el disco generado en el equipo y ejecuten la CDPedia.

Si descargan las versión tarball, directamente descompriman los archivos en el disco rígido. Entren a la carpeta descomprimida y ejecuten la CDPedia.

¿Cómo se ejecuta la CDPedia? Bueno, depende de cada sistema. En Windows con hacer doble click en cdpedia.exe, alcanza. En Linux o Mac, si tienen bien configurado el navegador de archivos, debería funcionar haciendo doble click en cdpedia.py, pero siempre pueden recurrir a abrir una terminal, ir hasta el directorio en cuestión, y hacer ./cdpedia.py.

En cualquier caso al ejecutar ese archivo se va a levantar el Server de CDPedia, y al mismo tiempo se abrirá un navegador apuntando a ese Server local. Luego, es sólo usarla, ya que se explora y utiliza de la misma manera que la Wikipedia Online (con la excepción obvia que la CDPedia es de lectura solamente: no permite editar el contenido como sí lo hace la Wikipedia).

(a este y otros screenshots, hagan click para verlos más grandes)

Cómo se ve la CDPedia

Una decisión estratégica de la CDPedia es tomar el HTML generado por los servers de Wikipedia y usarlos casi directamente (les recortamos unos headers, optimizamos algunas cositas). Exploramos en algún momento tomar la info de la base de datos directamente, pero no logramos generar una página web igual a la de Wikipedia online.

Y eso es una fortaleza de la CDPedia: por la manera en que armamos las páginas, la forma de ver y usar las páginas, de explorar y acceder a la información, es igual a la Wikipedia online, de manera que el usuario no tiene un costo cognitivo en pasar de la versión online a offline. Es más, también se puede considerar a la CDPedia como el paso previo de consumo de contenido a la Wikipedia: una persona se puede acostumbrar a explorar las páginas, leer, cruzar y criticar la información, etc, y recién cuando tiene todo armado va a la Wikipedia Online y al resto de Internet para completar su investigación.

Más allá de la página a nivel contenido, lo que sí modificamos mucho es la barra de la izquierda. No tiene la original de Wikipedia, porque no tiene sentido al ser todo offline, así que reemplazamos los botones y enlaces por otros: hay un botón para ver una página al azar, un campo de texto de búsqueda, el logo de CDPedia, el logo de PyAr, enlace a una página de ayuda, etc...

Algo que también modificamos bastante es como señalizamos los enlaces en la página misma, en el contenido de Wikipedia. Hay principalmente tres tipos, distinguibles en cómo decoramos el texto convertido en enlace:

  • Azul: un link normal, apunta a otra página de Wikipedia que se incluyó dentro de CDPedia.
  • Rojo, subrayado con guiones: un enlace a otra página de Wikipedia pero que no fue incluida en CDPedia por razones de espacio.
  • Azul, subrayado con guiones: un link que los sacaría de CDPedia, ya que apunta a recursos online (útiles solamente si tenés Internet, claramente).

Muestra de enlaces

Otra sección que modificamos es el pie de cada página: ponemos un enlace a la misma página pero online, en Wikipedia misma, por si el usuario necesita la información actualizada. También aquí incluimos el contenido original, ponemos algún disclaimer extra, mencionamos que CDPedia es un proyecto de Python Argentina (y apuntamos al tutorial de Python que está incluido en la CDPedia).

Cabe mencionar que la CDPedia funciona también en Modo Servidor. De esta manera, se puede instalar la CDPedia en el servidor de una escuela, y que todas las computadoras del establecimiento puedan usar la información desde allí. Así logramos el efecto deseado de que los chicos puedan tener acceso al contenido de Wikipedia sin realmente tener Internet, pero sin la complicación o el incordio de tener que instalar CDPedia en cada una de las computadoras. Acá hay más instrucciones para configurarla de este modo.


¿Qué contenido tiene?

El contenido de la CDPedia está fuertemente determinado por dos características intrínsecas del proyecto: la CDPedia es estática y fácilmente distribuible en un disco o pendrive.

Digo que la CDPedia es estática porque una vez armada, no se actualiza. Es por eso una especie de "fotografía de un momento de Wikipedia" que, por definición, siempre va a estar desactualizada.

Cuando se comienza a generar una nueva versión de la CDPedia, se baja la versión más actualizada de todo el contenido de Wikipedia y se empieza a procesar. Este procesamiento puede llevar varias semanas, incluso unos meses. Entonces, cuando se libera una nueva versión de CDPedia, no incluye todos los cambios que se generaron en Wikipedia misma desde que se empezó a procesar.

Es por esto que se trata de liberar una versión de CDPedia al menos una vez por año, para que contenga la información lo más actualizada posible.

Ejemplo de un artículo

También digo que la CDPedia se puede distribuir fácilmente: sólo hace falta quemar un CD o DVD, o incluso pasarse los archivos mediante un pendrive. En casi todas las versiones (menos la más grande), por una cuestión de formato, no entra todo el contenido de la Wikipedia. Por ejemplo, para la versión 0.8.3, tenemos lo siguiente:

  • CD (693 MB): 54 mil páginas y 5% de las imágenes
  • Tarball medio (3.6 GB): 400 mil páginas y 20% de las imágenes
  • DVD (4.3 GB): Todas las páginas y 8% de las imágenes
  • Tarball grande (8.7 GB): Todas las páginas y todas las imágenes

Entonces, a menos que estemos armando el tarball grande, es evidente que tenemos que decidir cuáles páginas e imágenes van a entrar, y cuáles van a quedar afuera.

Esa decisión se toma ordenando todas las páginas por un determinado puntaje (que explico abajo), y se eligen las primeras N páginas (para el ejemplo anterior, las primeras 54 mil para el CD, las primeras 400 mil para el tarball medio, etc). Esas páginas tienen a su vez imágenes, que naturalmente también quedan ordenadas por el puntaje de las páginas: se toma un primer porcentaje de imágenes que se incluyen al 100%, otro porcentaje de imágenes que se escalan al 75%, otro porcentaje de imágenes que se escalan al 50%, y el resto no se incluye.

Analizando las páginas

Como vieron, un tema clave en la selección es darle un puntaje a las páginas. Este puntaje está formado (hoy por hoy) en base a dos factores: levemente por el largo de la página (una página larga tiene más puntaje que una corta), y fuertemente por lo que llamamos "peishranc", que es la cantidad de otras páginas que enlazan a la que estamos evaluando. Entonces, si a una página se la menciona en otras mil páginas es mucho más importante que una página que casi no se la menciona en el resto de la Wikipedia.

Otro gran detalle en lo que es "contenido" es qué hacemos para mitigar el problema de la vandalización. O sea, cómo evitamos en lo posible incluir páginas que fueron vandalizadas. Cuando comienza el proceso de generar una nueva versión de la CDPedia, como les comentaba antes, bajamos todas las páginas de Wikipedia, ¡pero no siempre bajamos la última versión! Lo que hacemos es revisar cuándo fue modificada y por quién: si fue modificada por un usuario normal, perfecto; pero si fue modificada por un usuario anónimo (como sucede en la mayoría de las vandalizaciones) nos fijamos cuando fue modificada: si fue hace más de varios días, la incluimos (asumimos que la gente de Wikipedia ya tuvo tiempo de verificar el cambio), pero si es muy reciente evitamos la última versión de la página, y agarramos la versión anterior (y aplicamos nuevamente todos estos mismos controles).


¿Cómo surgió el proyecto?

Cuenta la leyenda que el proyecto arrancó en el sprint posterior al primer PyDay de Santa Fé, en Junio del 2006, con la idea base de poder distribuir la Wikipedia a aquellos lugares que no tenían o tienen acceso a Internet (en particular teníamos en mente a escuelas de frontera o de ciudades chicas, bibliotecas de barrio, centros culturales de pueblos pequeños, etc.).

El proyecto continuó, y aunque no siempre le pudimos dedicar tiempo, tampoco nos alejamos nunca demasiado. Las mejoras en el proyecto fueron muy por ráfagas. Quiero destacar que fuimos muchos los que colaboramos con el proyecto, a lo largo de los años, ¡casi 30 personas!

Se trabajó mucho en este proyecto durante los PyCamps (los dos en Los Cocos, el de Verónica, y el de La Falda), donde muchas personas le dedicaron un buen tiempo, y también se realizó bastante durante otras reuniones, especialmente durante el 2010 y 2011.

Trabajando en un PyCamp

A modo de ejemplo, dos sprints: uno fue en un incipiente hacklab, donde se experimentó mucho sobre el índice para las búsquedas, y también durante la fundación de Wikimedia Argentina, donde se presentó por primera vez el proyecto y se realizó un gran avance en la primera parte del procesamiento de datos.

En años más cercanos yo traté de involucrar colaboradores en algunos sprints efímeros que armé, con poca suerte. Lamentablemente en el último tiempo fui principalmente sólo yo el que empujó el proyecto (lo cual es una autocrítica, más que un autoreconocimiento).

Una gran característica de la CDPedia, indiscutiblemente el proyecto más grande y más largo de Python Argentina, es que siempre se mantuvo orientado a los mismos objetivos: tener una Wikipedia offline con fines sociales (distribuir en escuelas sin conexión a Internet, que el conocimiento sea libre, etcétera), que sea divertido de hacer (es decir, hacerlo en Python), y mantenerlo libre (no sólo el producto final, que recomendamos copiarlo y repartirlo, sino el código en sí).


¿Se logró cumplir el objetivo social?

Como decía arriba, uno de los objetivos de la CDPedia es difundir el conocimiento, lograr que gente que no tenga acceso a Internet igual pueda acceder a la información de la Wikipedia, que es tan valiosa. Siendo PyAr una comunidad relativamente pequeña, era difícil escalar a tener un impacto nacional en el común de la gente.

En su momento queríamos que se viralice persona a persona: que alguien la baje y haga un par de CDs y los reparta, que los que reciben cada CD hagan a su vez varias copias y las repartan a otras personas, a escuelas, bibliotecas de barrio, etc. Pero no tuvimos mucho éxito con esa movida.

Pero resulta que Martín Varsavsky se casó, y Jimmy Wales le regaló para el casamiento la posibilidad de que se distribuya una Wikipedia offline en Argentina. Preguntó cuáles habían, la CDPedia era la que mejor se ajustaba a lo que se necesitaba, y vino Jimmy a Buenos Aires, le mostramos la CDPedia, y luego hubo una reunión en Educ.ar para terminar de acordar esto (fueron Jimmy por Wikimedia, Enrique Chaparro por Wikimedia Argentina y Alecu por PyAr).

En gran parte porque Educ.ar quería meter la CDPedia en un disco de ellos (con carátula de ellos, algunas otras páginas, etc), se logró que dicha institución becara a dos chicos de PyAr, Diego Mascialino y Hernán Olivera, para trabajar part time en esto.

Así que agarraron la versión 0.6 que recién había salido (Alecu y yo nos habíamos apurado a cerrar muchos detalles para tener algo funcionando presentable a Jimmy Wales), y entraron a darle. Esto le dio bastante impulso al desarrollo del proyecto, sumado a que también aporté regularmente al proyecto, y a que luego de que se terminara la beca Diego siguió trabajando en CDPedia, y que se sumó como "laburante regular" Santiago Piccinini.

Con todo este trabajo, y un nuevo empujón en el PyCamp del 2011, pudimos terminar de cerrar la versión 0.7, que se entregó a Educ.ar y se distribuyó a todas las escuelas del pais.

Sin embargo el mayor hito a nivel de distribución masiva de la CDPedia es que en algún momento fue incluida en las notebooks que el Estado argentino distribuye a los chicos de escuelas de todo el país como parte del programa Conectar Igualdad. Y también se la muestran a alumnos y docentes en los talleres que hacen como parte del programa.


¿Se puede espiar abajo del capot?

¿Cómo se arma la CDPedia? ¿Cómo se logra cumplir todo lo que expliqué arriba?

Es bastante sencillo: hay que bajar el código con git desde la página del proyecto en github, y luego correr un script que hace todo solo: el cdpetron.

Este script tiene bastantes opciones (especialmente para no repetir partes del proceso: que no vuelva a listar todas las páginas, que no vuelva a bajarlas, que no limpie todo antes de comenzar, etc), pero lo básico es que se le especifica de dónde tomar el código, donde bajar y dejar páginas e imágenes, y en qué idioma trabajar.

Incluso hay una manera de correrlo en modo test, para que haga solo una parte del trabajo y poder arrancar pronto a probar cosas, ideal para mezclarlo con la opción de generar una sola de las versiones:

    $ utilities/cdpetron.py --test-mode --image-type=beta . /tmp/dumpcdpedia es

El comando anterior tarda relativamente poco (menos de cinco minutos en una máquina normal y con buena conexión a Internet) y nos deja todo el proceso realizado, pero con pocas páginas.

Ver lo que obtuvimos es sencillo, porque más allá de generarnos el tarball o el .iso correspondiente, podemos probar la CDPedia directamente del directorio donde realizamos el proceso, haciendo...

    ./cdpedia.py

...lo cual levantará el server y nos abrirá el browser, tal cual si lo hiciéramos de la versión final (pero con la ventaja que podemos pararlo, cambiar el código para probar el algo, levantarlo de nuevo, ver los resultados, etc.)

¿Y cómo es el proceso que realiza? Bueno, la estructura interna (y el proceso para obtenerla) de la CDPedia está muy influida por la necesidad de optimizar al máximo la compresión y el acceso a la información, de manera de poder meter en cada formato (CD, etc...) la mayor cantidad posible de artículos e imágenes.

Podemos delinear el proceso que se realiza en en el siguiente gráfico:

Proceso de la CDPedia

El primer paso es bajar de la Wikipedia misma todas las páginas (lo que realmente tiene dos sub-pasos, un listado general de todas las páginas que nos interesan, y luego efectivamente bajarlas). Esas páginas son pasadas por diferentes preprocesadores que hacen distintos trabajos. Algunas las filtran y eliminan páginas que no queremos, otras les asignan puntajes, otras las modifican mejorándolas para nuestro objetivo, otras extraen información que va a ser útil luego.

Al final de ese preprocesamiento tenemos dos grandes resultados intermedios: los HTMLs "útiles", más un montón de metadata. Aquí se abren tres grandes ramas de trabajo.

La primera es el manejo de las imágenes. Se buscan los enlaces en las páginas, se descargan todas las imágenes necesarias (que pueden no ser todas, dependiendo de la versión generada), se reducen las que corresponden (algunas se incluyen al 75% o 50% de su tamaño) y finalmente se arman los llamados "bloques de imágenes".

Por otro lado, con los resultados intermedios se generan los "bloques de artículos".

Y finalmente, se procesan todos los títulos de las páginas más algo de metadata y se hace pasar por un complejo algoritmo matemático que nos pre-arma la información para generar los "bloques del índice".

A esta altura tengo que explicar qué son estos "bloques" de imágenes, artículos o índice. Es una estructura no demasiado compleja pero muy bien pensada para el objetivo de la CDPedia que es funcionar sin usar demasiada memoria y poco espacio en disco. Básicamente tenemos bloques de información comprimidos de forma independiente: es un equilibrio entre comprimir todo por separado, o comprimir todo junto; logramos mejor ratio de compresión que comprimiendo la info por separada, y no tenemos que descomprimir algo demasiado grande al no estar todo junto. Para decidir qué bloque consultar hay un hasheo y selección, y luego dentro de cada bloque hay un índice binario de contenidos, pero no mucho más.

Finalmente, con estos bloques, más algunos recursos estáticos (imágenes, CSSs, algo de JSs, el tutorial de Python comprimido, etc.), más el código de Python propiamente dicho para servir la CDPedia, se arman los tarballs o .ISOs.


¿En qué situación está el proyecto actualmente?

El proyecto avanza, pero lento.

Hay varios bugs abiertos, incluso algunos que son críticos porque se muestran un par de cosas feas luego de un cambio de formato de las páginas de Wikipedia, pero yo personalmente no estoy haciendo foco ahí, sino que estoy empujando un par de cambios más grandes.

Uno de ellos es lograr la internacionalización de la CDPedia. Cuando esté terminado, se van a poder crear CDPedias no sólo a partir de la Wikipedia en español, sino también de la Wikipedia en otros idiomas: portugués, aymara, guaraní, alemán, ruso, etc...

El otro cambio es más bien la construcción de una infrastructura en particular. Mi idea es tener una generación continuas de CDPedias, que se arme la CDPedia en español, y automáticamente luego se arme la de otro idioma, y otro, y otro, y otro, y luego de varios meses, vuelva a arrancar con la de español.

Trabajando

Pero, como decía, hay mil cosas para hacer.

Unos chicos en un PyCamp hicieron una app para Android que, luego de copiar los datos a mano, correría la CDPedia en cualquier teléfono o tablet (yo traté recientemente de usarlo y tuve unos problemas y no lo pude hacer andar del todo).

Otro detalle que necesita trabajo es que el código en sí está bastante feo... mezcla inglés y castellano, no cumple PEP 8 ni PEP 257, tiene poco y nada de pruebas de unidad, etc.

Si tienen ganas de participar de cualquier manera, lo principal es que se pongan en contacto con el grupo en general, a través de la lista de correo o del foro asociado (son espejo uno del otro, usen el
que sientan más cómodo). Lo mismo si desean hacer cualquier consulta, o ponerse en contacto para cualquier inquietud.

CDPedia necesita amor. Programadores con ganas de trabajar y aprender, tiempo de programador para continuar llevando este proyecto tan interesante y valioso por buen camino.

Read more
facundo


¡¡Salió la versión 4 de fades!!

Mucho mucho laburo le pusimos con Nico a esta versión (y tuvimos bastante ayuda de otros colaboradores, en particular durante el último PyCamp).

¿Pero qué es fades? Es un sistema que maneja automáticamente los virtualenvs de sistemas Python en los casos que uno normalmente encuentra al escribir scripts y programas pequeños, e incluso ayuda a administrar proyectos grandes.

Crea automáticamente un nuevo virtualenv (o reusa uno creado previamente) instalando las dependencias necesarias, y ejecutando el script dentro de ese virtualenv.

Todo lo que se necesita hacer es ejecutar el script con fades (en lugar de Python) y también marcar las dependencias necesarias. Más detalles en la documentación misma.

fades

¿Qué hay de nuevo en esta release?

  • Nueva opción para usar iPython en el interprete interactivo: --ipython (gracias Ariel Rossanigo)
  • Ahora es posible ejecutar un programa dentro del virtualenv con -x (gracias Ricardo Kirkner). Por ejemplo es posible crear un proyecto de django sin tener django instalado en tu sistema usando: fades -d django -x manage startproject foo
  • Podés ejecutar fades como un módulo de python. Simplemente hay que ejecutar python3 -m fades (gracias Javi Mansilla)
  • Soportamos Python 3.3 para ejecutar fades
  • Si sos un usuario especial y no te alanzan las opciones que tenemos tenemos cosas para vos!  Podes pasarle opciones a virtualenv con --virtualenv-options, también a pip con --pip-options, e incluso es posible eliminar un virtualenv con --rm <uuid>
  • Tenemos un logo!! (el que se ve arriba, claro)
  • Los tests de fades se ejecutan con fades! No hay necesidad de instalar nada previamente
  • Se pueden crear virtualevs con --system-site-packages
  • Varios bug fixeados y otros nuevos ;)

Para instrucciones de cómo obtenerlo o instalarlo, miren en la página del proyecto o la de PyPI.

Por otro lado, con Nico habíamos decidido que era importante para fades que puede ser instalado con apt-get install en Debian y Ubuntu.

Entonces, me puse con eso, pedí en el laburo si algún Debian Developer quería darme una mano para meter fades en Debian, y se copó uno de los mejores: Barry Barsaw. Me estuvo ayudando un montón, contestándome preguntas simples y complicadas.

Nosotros ya teníamos un .deb, pero no del todo bien armado. Al final, terminé dando vuelta completamente todo pero quedó todo más simple, más limpio, y con mejor forma. El .deb que generamos es un lujo, y además fades terminó entrando en Debian, en unstable al principio y luego en testing, :D. Es mi primer programa que entra en Debian, y para mí es todo un orgullo :).

El camino natural es que entre en Xenial Xerus (Ubuntu 16.04), que es LTS, así que seguramente liberaremos la v5 la primer quincena de febrero.

Rock.

Read more
facundo

PyCon Ar 2015


La semana pasada se hizo la séptima conferencia nacional de Python en Argentina, la PyCon Ar 2015.

Fue en Mendoza. Un poco lejos para ir en auto o en micro, así que decidí en ir en avión. A nivel de costo era lo mismo, y la ganancia en tiempo era notable. Me permitió viajar el jueves, y volver el domingo, sin perder completamente ambos días o más.

Allá me quedé en un hostel, que siempre es más comunitario que un hotel, aunque menos privado. Pero bien. Fuí a Casa Pueblo Hostel, lindo y barato.

El evento se hizo en el Espacio Cultural Julio Le Parc, un lugar muy grande (que no estaba para nosotros sólos, obviamente). Tenía sus limitaciones (el viernes para el segundo track se hizo en un aula que siempre desbordaba) pero estuvo bien.

Algo para destacar es que teníamos el almuerzo resuelto (una vianda fría, abundante) muy al estilo de las PyCon yanquies. Y como allá, se almuerza en rondas en el piso, en el parque, en cualquier lado, porque se desborda cualquier capacidad de "asientos para comer". Me gusta lo de proveer la solución para el almuerzo, se resuelven un par de problemas de un mismo golpe: la gente no tiene que salir masivamente a buscar qué come y dónde, y de yapa no se demora en llegar al bloque de la tarde.

Dando la charla de Async en Py3

A nivel contenidos, la conferencia estuvo espectacular. Aproveché un montón de charlas: la de "Practical OpenCV" de Diego Ramirez estuvo interesante; "Encantando PythonES para masticar data" del gran Juanjo Ciarlante me enseñó un montón de cosas sobre map&reduce; la de "socket a asyncio en 45 minutos" de Marcos Dione me pareció super valiosa para dar en dos horas, le explicaría mucho a mucha gente; David Weil con "Es posible detectar las excepciones de un código Python" siempre con análisis interesantes super prácticos y de bajo nivel; Sofía Martin con "Tu primera aplicación con Kivy para móviles" mostrando lo fácil y directo que es hoy día hacer Python para Android; y "Cacheando fuera de Django" de Guillermo Narvaja, con tips e info basada en experiencia real.

Y estoy dejando afuera a las dos keynotes: Ashwini Oruganti hablando del futuro de Python y la PSF, y Simon Willison disertando sobre Microservicios. Bien, pero nada del otro mundo.

A nivel personal, dí dos charlas, una sólo y otra acompañado. Por un lado "Programación asincrónica en Python 3: el futuro ya llegó", que no era la primera vez que la daba y encima me quedé sin tiempo y faltó explicar muchos ejemplos. Pero a la gente le gustó (o al menos eso me fueron comentando). Y además dimos con Joac "No es magia: descriptores al desnudo", una charla sobre un tema tan complicado que creo que haberla dado en tiempo y mostrando todo lo que queríamos fue un éxito por si mismo. Y de nuevo, recibimos mucho feedback positivo.

Joac y myself dando la charla

El lado negativo de todo fue que fui a Mendoza, pero no paseé ni conocí nada. Ya volveré, claro que sí.

Read more
facundo


Antes de cerrar el año armé un nuevo curso de Python, no como parte de un grupo cerrado para una empresa o institución, sino abierto al público en general. Esta vez, intensivo (muchas horas en sólo tres clases).

Será un Curso Introductorio a Python, apuntado a aquellos que no saben nada de este lenguaje, o saben algo pero quieren profundizar o formalizar conocimientos, y también incluirá un popurrí de temas enfocados a devops... todos los desarrolladores terminamos siendo un poco sysadmines a veces y está bueno saber usar algunas herramientas.

El nivel es introductorio, lo que significa que se van a ver muchos conceptos del lenguaje de manera profunda, pero no se tocarán temas avanzados ni satélites a lo que es Python en sí, con la intención que el asistente gane sólidos conocimientos que luego le permitan explorar el resto a su gusto. Para aprovechar el curso en todo su potencial se necesita tener conocimientos previos de programación (pero no hace falta ser un programador avanzado). En detalle, el contenido del curso versará sobre los siguientes ítems:

  • Introducción: ¿Qué es Python?; Primeros pasos; Recursos
  • Tipos de Datos: Haciendo números, y más números; Cadenas de texto; Tuplas y listas; Conjuntos; Diccionarios
  • Controles de flujo: if/elif/else; loops while y for; Excepciones
  • Encapsulando código: Funciones; Clases; Módulos; Espacios de nombres
  • Otros temas: Archivos; Serialización; Trabajando en Red; Ejecución externa; Multithreading/multiprocessing

El formato del curso será presencial, en un ambiente "tipo aula" con pizarrón y proyector, pero no basado en filminas, sino totalmente dinámico y adaptativo. Se hace un foco especial en la interacción profesor-asistente, de forma de ir resolviendo las dudas de todos y lograr un aprendizaje más profundo en el mismo tiempo. En función de esto también se limita el cupo, con una cantidad máxima de asistentes de alrededor de siete personas.

Como parte del curso se entregará un certificado de asistencia al mismo. No se necesita asistir al curso con computadoras, pero pueden traer laptops/netbooks si lo desean (van a disponer de conexión a internet via wifi y conexión eléctrica).

El curso es de 18 horas en total, dividido en tres clases, los Miércoles 4, 11 y 18 de Noviembre. El horario será de 10 a 17, considerando una hora para almorzar. El almuerzo será provisto como parte del curso: la idea es ofrecer esto resuelto, así comemos algo liviano, descansamos un rato, y seguimos trabajando, porque si vamos a almorzar a otro lado no nos va a alcanzar el tiempo. El lugar de realización es Borges 2145, Olivos.

El costo total del curso (incluyendo el almuerzo) es de $2720; es necesario abonar al menos el 50% para reservar la posición (recuerden que, como indicaba arriba, hay un máximo de lugares disponibles), abonando el saldo restante el primer día de clases.

Para reservar me envían un mail para confirmar disponibilidad y ahí les paso los datos necesarios.

Read more
facundo


Como casi siempre a Córdoba, fuí y volví en micro (porque en el colectivo en general duermo pasablemente bien, entonces aprovecho la noche, y no pierdo medio día "para viajar"). Esta vez, por otro lado, fuí un día antes, porque tenía que hacer un trámite en Córdoba Capital, así que estuve el jueves hospedado en la casa de Nati y Matías, trabajando durante el día, jugando juegos de mesa durante la noche.

El viernes a la mañana hicimos el viaje hasta La Serranita con los chicos. Llegamos a media mañana, y ahí se dió la situación de siempre, que es muchas veces esperada: saludar y abrazar a viejos amigos que uno no puede ver tan seguido (y a cuatro o cinco nuevos que uno todavía no conoce :) ).

El grupo recién reunido, charlando sobre las propuestas

Como quedaron planeadas las actividades


El lugar estuvo muy bueno. Quizás me podría quejar que el salón principal era demasiado ajustado, y que las comidas eran en una hostería a cuatro cuadras de distancia, pero el resto estuvo más que bien. No sólo las instalaciones (habitaciones, parque, quincho, etc, etc), sino la atención humana. Un lujo.

Hasta buena internet tuvimos en este PyCamp, ya que estábamos en la red vecinal abierta que Nico Echaniz y amigos montaron en La Quintana y ciudades aledañas. Eso sí, notamos que cuando teníamos problemas con lo que era comunicaciones el tema estaba en el router que estábamos usando (y eso que terminamos poniendo uno muy bueno). Decidimos que había que invertir en hardware un poco más pro (no algo "de uso hogareño bueno" sino algo "profesional")... veremos cuanto cuesta, pero creo que vamos a gastar unos mangos ahí, ya que nos queda no sólo para el PyCamp sino para otros eventos.

Una terraza dos niveles más arriba que la sala de laburo

Pequeño parque en uno de los niveles

A nivel proyectos y Python: lo de siempre... se hacen mil cosas, desde laburar en proyectos estables hasta delirar con cosas nuevas, se mejoran cosas arrancadas de antes, se agregan funcionalidades, se empiezan proyectos que se terminan en esos cuatro días, se arrancan cosas que luego duran mucho tiempo, etc... pero lo más importante no pasa por ahí.

El núcleo del evento es humano. Charlar con gente que conocés de siempre, y podés delirar ideas, proyectos nuevos, o simplemente charlar. Y conocer gente nueva. Pibes que están haciendo cosas locas o no, con laburos copados o no, con vidas interesantes o no. Pero charlar, compartir tiempo, ver como las otras personas encaran un proyecto, qué aportan, como ayudarlos, como transmitirles experiencias.

El programar Python es casi una excusa para que todo lo otro suceda. Y digo "casi" porque sí, claro, lo que se programa y hace está buenísimo también :D

En el comedor, almorzando

En la sala principal de laburo (no era grande, pero no era la única)

En ese aspecto, yo estuve principalmente con dos proyectos. Por un lado filesync server, recientemente liberado open source, con un cambio muy grande que empecé el jueves mismo estando en la casa de Nati y continué intermitentemente durante los cuatro días de PyCamp.

El otro proyecto en el que invertí mucho tiempo es fades que desarrollo principalmente con Nico. Es que se enganchó mucha gente que le gustaba lo que fades ofrece, y aportaron un montón de ideas buenísimas. ¡Y no sólo ideas! También código, branches que mergeamos o que todavía tenemos que revisar. Ya iremos metiendo todo, y queremos hacer un release en las próximas semanas. Estén atentos, porque fades ahora hace cosas que te vuela la peluca :D

Pero no sólo trabajé en eso. También porté Tritcask a que trabaje simultaneamente con Python 2 y Python 3 (arranqué sólo con esto, pero el 70% del laburo lo hicimos juntos con SAn). Y estuvimos buscando cómo hacer para detectar cuanto de un subtítulo matchea con las voces de un video, de manera de poder determinar si está bien sincronizado o no. Y estuve haciendo algo de código asincrónico usando asyncio. Y estuve charlando con SAn, DiegoM, Bruno y Nico Echaniz sobre una especie de Repositorio Federado de Contenido Educativo. Y estuve ayudando a gente a trabajar en Python mismo durante un cortito Python Bug Day (Jairo solucionó un issue y medio!!).

Camino al río

Recorriendo la vera del río, saltando de piedra en piedra

El mejor asado de un PyCamp, ever

Y tomé sol. Y tuve en mis manos una espada de verdad por primera vez. Y caminé por el costado del río saltando de piedra en piedra. Y comí un asadazo (entre el centenar de kilos de comida que ingeríamos por día por persona). Y conocí La Serranita. Y charlé mil. Y usé un sistema de realidad virtual. Y jugué a muchos juegos de mesa.

Y abracé amigos.

Read more
facundo


La semana que viene (casi ahora ahorita) arranca una nueva edición del mejor evento de programación del mundo mundial.

Esta vez se hace en La Serranita, Córdoba.

Hay un montón de propuestas de varias personas, yo en particular propuse armar una especie de verificador de subtítulos (la idea es verificar si un subtítulo matchea con el video... o mejor dicho, con el audio... lo básico es encontrar si en el momento del subtítulo hay alguien hablando, con eso uno ya se asegura que el subtítulo está sincronizado), trabajar un poco en Encuentro y fades, y armar un Python Bug Day (para trabajar un rato en Python en sí, cerrar algún bug del lenguaje propiamente dicho... mucho código del lenguaje es en C, pero también hay mucho en Python mismo, y hay algunas cosas que son sencillas).

Aproveché y preparé/actualicé instrucciones de "cómo configurar/inicializar/arrancar con el proyecto" tanto para Encuentro como para fades. Para Python en sí no hace falta, ya que hay clarísimas instrucciones en la Python Developer's Guide :)

Ya les reportaré como fue todo :)

Read more
facundo


Estos últimos días se liberaron nuevas versiones de dos proyectos en los que estoy involucrado activamente.

A principio de mes lancé Encuentro 3.1 (como ya sabrán, este programa permite buscar, descargar y ver contenido del Canal Encuentro, Paka Paka, BACUA, Educ.ar y otros).

La versión 3.1 trae los siguientes cambios con respecto a la versión anterior:

  • Vuelve a funcionar luego de los cambios de backend de Encuentro y Conectate
  • Ahora con CTRL-F se va directamente al campo de filtro (gracias Emiliano)
  • Se rehizo el manejo de la lista de episodios: ahora verlos y filtrarlos es muchísimo más rápido
  • Mejoras en el empaquetado, debería funcionar para muchas (todas?) las versiones de Debian/Ubuntu (gracias Adrián Alves). 
  • Varias mejoras al encontrar nuevos episodios de los distintos backends, y correcciones en general. 

Más info y cómo descargarlo, instalarlo, etc, en la página oficial.

Por otro lado, ayer se lanzó fades 3 (un proyecto orientado a desarrolladores Python, en contraposición a Encuentro que está pensado para el usuario final), que desarrollamos principalmente Nico Demarchi y yo.

fades (en inglés: FAst DEpendencies for Scripts) es un sistema que maneja automáticamente los virtualenvs en los casos simples que uno normalmente encuentra al escribir scripts o programas pequeños.  Crea automáticamente un nuevo virtualenv (o reusa uno creado previamente) instalando las dependencias necesarias, y ejecutando el script dentro de ese virtualenv.

¿Qué hay de nuevo en esta release?

  • Podés usar diferentes versiones del intérprete: simplemente pasá --python=python2 o lo que te convenga.
  • Las dependencias pueden especificarse en la linea de comando: no hay necesidad de cambiar el script para una prueba rápida, simplemente especificá la dependencia necesaria con --dependency.
  • Modo interactivo: es la manera más rápida de probar una nueva biblioteca. Sólo hacé fades -d <dependencia> y te abrirá un intérprete interactivo dentro de un venv con esa dependencia.
  • Soporta tomar argumentos desde el shellbang. De esta manera podés crear un script y poner al principio del mismo algo como: #!/usr/bin/env fades -d <dependencia> --python=python2.7
  • Puede parsear requerimientos desde un archivo. No hay necesidad de ningún cambio si ya tenés un archivo requirements.txt: simplemente indicalo con --requirement.
  • Si no se especifica el repo, toma PyPI por defecto, lo que resulta en código más limpio y simple.
  • Tiene una base de datos integrada para conversiones típicas de nombres: de esta manera se puede marcar con fades un "import bs4" incluso si ese no es el nombre del paquete en PyPI.
  • Otros cambios y correcciones menores.

Toda la info, en la página de PyPI del proyecto.

Read more
facundo


Hace un tiempo les hablé de un árbol que hice para sacar prefijos de palabras.

En el laburo estoy estudiando la forma de hacer un autocompletador. Entonces, luego de leer cosas por ahí, decidí probar ese árbol que ya tenía hecho.

Nunca le había tirado tantos datos, pero la verdad es que salió andando de perlas.

Por otro lado, tenía un detalle que necesitaba solucionar: yo quería que la búsqueda de palabras soportara errores en la escritura. O sea, que si uno buscara "maise", encontrara "maizena".

Encontré un paper bastante loco, Efficient Error-tolerant Query Autocompletion, pero que mostraba la forma de soportar errores al buscar palabras completas, no prefijos. Igual, apliqué ideas de ahí, y en un par de días de laburo conseguí lo que quería. Pero, al cargar el millón y medio de registros que tengo que cargar, ¡explotaba por memoria!

Luego de algunas optimizaciones obvias, se me ocurrió lo de deduplicar los subtrees internos. ¿Qué es deduplicar? Deduplicar es la acción por la cual si tengo un objeto A, y luego tengo otro B, que resulta ser igual a A, puedo usar el A directamente en ambos casos, descartando B (libera memoria), y listo.

Deduplicar diccionarios no es un asunto trivial. Tiré el asunto en la lista de PyAr, y en pocas horas logré que todo funcione correctamente. Ahora no sólo no explota, sino que ocupa bastante poca memoria!

    Memory usage after loading the tree: rss: +586 MB  vms: +586 MB
    Time to load the tree: 327190.99 msec
    <WordTree at 3068071276 [tau=1]: 1478347 words 30015540 (2201293) nodes (unique)>

Millón y medio de palabras, 30 millones de nodos (de los cuales 2.2 millones son únicos), ocupando 590 MB de memoria. Nada mal, ¿no? Que tarde 5.5 minutos en armar toda la estructura es un problema, la semana que viene voy a mirar eso bien.

Todo el código, acá.

Read more
facundo


They say that metaclasses make your head explode. They also say that if you're not absolutely sure what are metaclasses, then you don't need them.

And there you go, happily coding through life, jumping and singing in the meadow, until suddenly you get into a dark forest and find the most feared enemy: you realize that some magic needs to be done.


The necessity

Why you may need metaclasses? Let's see this specific case, my particular (real life) experience.

It happened that at work I have a script that verifies the remote scopes service for the Ubuntu Phone, checking that all is nice and crispy.

The test itself is simple, I won't put it here because it's not the point, but it's isolated in a method named _check, that receives the scope name and returns True if all is fine.

So, the first script version did (removed comments and docstrings, for brevity):

    class SuperTestCase(unittest.TestCase):

        def test_all_scopes(self):
            for scope in self._all_scopes:
                resp = self._check(scope)
                self.assertTrue(resp)

The problem with this approach is that all the checks are inside the same test. If one check fails, the rest is not executed (because the test is interrupted there, and fails).

Here I found something very interesting, the (new in Python 3) subTest call:

    class SuperTestCase(unittest.TestCase):

        def test_all_scopes(self):
            for scope in self._all_scopes:
                with self.subTest(scope=scope):
                    resp = self._check(scope)
                    self.assertTrue(resp)

Now, each "sub test" internally is executed independently of the other. So, they all are executed (all checks are done) no matter if one or more fail.

Awesome, right? Well, no.

Why not? Because even if internally everything is handled as independent subtest, from the outside point of view it still is one single test.

This has several consequences. One of those is that the all-inside test takes too long, and you can't know what was going on (note that each of these checks hit the network!), as the test runner just show progress per test (not subtest).

The other inconvenient is that there is not a way to call the script to run only one of those subtests... I can tell it to execute only the all-inside test, but that would mean to execute all the subtests... which, again, takes a lot of time.

So, what I really needed? Something that allows me to express the assertion in one test, but that in reality it were several methods. So, I needed something that, from a single method, reproduce them so the class actually had several ones. This is, write code for a class that Python would find different. This is, metaclasses.


Metaclasses, but easy

Luckily, since a couple of years ago (or more), Python provides a simpler way to achieve the same that could be done with metaclasses. This is: class decorators.

Class decorators, very similar to method decorators, receive the class that is defined below itself, and its response is considered by Python the real definition of the class. If you don't have the concept, you may read a little here about decorators, and a more deep article about decorators and metaclasses here, but it's not mandatory.

So, I wrote the following class decorator (explained below):

    def test_multiplier(klass):
        """Multiply those multipliable tests."""
        for meth_name in (x for x in dir(klass) if x.startswith("test_")):
            meth = getattr(klass, meth_name)
            argspec = inspect.getfullargspec(meth)

            # only get those methods that are to be multiplied
            if len(argspec.args) == 2 and len(argspec.defaults) == 1:
                param_name = argspec.args[1]
                mult_values = argspec.defaults[0]

                # "move" the usefult method to something not automatically executable
                delattr(klass, meth_name)
                new_meth_name = "_multiplied_" + meth_name
                assert not hasattr(klass, new_meth_name)
                setattr(klass, new_meth_name, meth)
                new_meth = getattr(klass, new_meth_name)

                # for each of the given values, create a new method which will call the given method
                # with only a value at the time
                for multv in mult_values:
                    def f(self, multv=multv):
                        return new_meth(self, **{param_name: multv})

                    meth_mult_name = meth_name + "_" + multv.replace(" ", "_")[:30]
                    assert not hasattr(klass, meth_mult_name)
                    setattr(klass, meth_mult_name, f)

        return klass

The basics are: it receives a class, it returns a slightly modified class ;). For each of the methods that starts with "test_", I checked those that had two args (not only 'self'), and that the second argument were named.

So, it would actually get the method defined in the following structure and leave the rest alone:

    @test_multiplier
    class SuperTestCase(unittest.TestCase):

        def test_all_scopes(self, scope=_all_scopes):
            resp = self.checker.hit_search(scope, '')
            self.assertTrue(resp)

For that kind of method, the decorator will move it to something not named "test_*" (so we can call it but it won't be called by automatic test infrastructure), and then create, for each value in the "_scopes" there, a method (with a particular name which doesn't really matter, but needs to be different and is nice to be informative to the user) that calls the original method, passing "scope" with the particular value.

So, for example, let's say that _all_scopes is ['foo', 'bar']. Then, the decorator will rename test_all_scopes to _multiplied_test_all_scopes, and then create two new methods like this::

    def test_all_scopes_foo(self, multv='foo'):
        return self._multiplied_test_all_scopes(scope=multv)

    def test_all_scopes_foo(self, multv='bar'):
        return self._multiplied_test_all_scopes(scope=multv)

The final effect is that the test infrastructure (internally and externally) finds those two methods (not the original one), and calls them. Each one individually, informing progress individually, the user being able to execute them individually, etc.

So, at the end, all gain, no loss, and a fun little piece of Python code :)

Read more
facundo


Algunas, varias y sueltas.

A nivel de proyectos, le estuvimos metiendo bastante con Nico a fades. La verdad es que la versión 2 que sacamos la semana pasada está piolísima... si usás virtualenvs, no dejes de pegarle una mirada.

Otro proyecto con el que estuve es CDPedia... la parte de internacionalización está bastante potable, y eso también me llevó a renovar la página principal que te muestra cuando la abrís, así que puse a tirar una nueva versión de la de español, y luego seguirá una de portugués (¡cada imagen tarda como una semana!).

Hace un rato subí a la página de tutoriales de Python Argentina el Tutorial de Django en español (¡gracias Matías Bordese por el material!). Este tuto antes estaba en un dominio que ahora venció, y nos pareció interesante que esté todo en el mismo lugar, facilita que la gente lo encuentre.

Finalmente, empecé a organizar mi Segundo Curso Abierto de Python. Esta vez lo quiero hacer por la zona de Palermo, o alrededores (la vez pasada fue en microcentro). Todavía no tengo reservado un lugar, y menos fechas establecidas, pero el formato va a ser similar al anterior. Con respecto al sitio, si alguien conoce un buen lugar para alquilar "aulas", me avisa, :)

Read more
facundo

Logging levels


Cuando empecé con el concepto de loguear, me parecía demasiado tener niveles. Con el tiempo y la experiencia me di cuenta que son imprescindibles, :)

En la biblioteca estándar de Python hay un módulo logging que trae varios niveles prefijados. Son estos, con una pequeña anotación de cómo los uso, más un ejemplo de la vida real (tomados de mi programa de Encuentro o de fades).

- CRITICAL: creo que nunca lo usé :)

- ERROR: problemas de todo tipo; cosas que no deberían pasar, y si pasan son un inconveniente; muchas veces el programa no continúa, o continua de forma parcial o limitada, luego de este tipo de linea logueada. En este ejemplo logueo que no se pudo bajar la lista de los backends durante una actualización (también en este caso se le avisa al usuario mediante una ventanita, y el programa sigue, aunque la actualización no se concretó):

    try:
        _, backends_file = yield utils.download(BACKENDS_URL)
    except Exception, e:
        logger.error("Problem when downloading backends: %s", e)
        tell_user("Hubo un PROBLEMA al bajar la lista de backends:", e)
        return

- WARNING: para indicar que sucedió algo que en general no debería pasar; en general no son cosas malas, sino más bien anómalas, y no presentan una situación problemática. En el siguiente ejemplo estoy dejando registro que ignoro la opción 'quiet' que pasó el usuario (porque también pasó la opción 'verbose', que es más importante):

    if verbose and quiet:
        l.warning("Overriding 'quiet' option ('verbose' also requested)")

- INFO: información general del funcionamiento del programa, cosas que son imprescindibles saber y que siempre queremos que sean registradas; en general no involucran gran cantidad de lineas, pero permite seguir el flujo de ejecución del programa desde un nivel alto. Normalmente los programas que se entregan a los usuarios o corren en los servidores están configurados para realmente mandar a disco desde este nivel. En las siguientes dos lineas muestro lo primero que loguea Encuentro al arrancar: con qué versión de Python está siendo ejecutado y qué versión de sí mismo es:

    log.info("Running Python %s on %r", sys.version_info, sys.platform)
    log.info("Encuentro version: %r", version)

- DEBUG: toda la información necesaria para analizar en detalle la ejecución del programa. Puede involucrar grandes cantidades de información, y hasta ser un problema con respecto al uso de disco o afectar la performance, pero en general no se corren los programas en este nivel, sólo durante el desarrollo o en casos de tratar de analizar un problema específico. No es raro, por ejemplo, pedirle al usuario que ejecute el programa con un parámetro especial que configura los logs en este nivel y que trate de reproducir el problema que tuvo, para luego hacer un análisis forense de la situación. En el siguiente ejemplo estoy dejando constancia que fades tuvo que instalar pip a mano en el virtualenv:

    logger.debug("Installing PIP manually in the virtualenv")

Me ha pasado en sistemas muy complejos de necesitar un nivel más abajo que DEBUG para loguear toda aquella información que podría llegar a ser útil para un análisis del comportamiento del programa, pero que normalmente sería un exceso de datos (lo cual complica desde la lectura de los registros hasta el mismo manejo de los archivos). Entonces, usábamos un nivel TRACE, que casi nunca se prendía, para este propósito.

La macana es que el módulo de logging no tiene un nivel TRACE, pero lo creábamos a mano:

    TRACE = 5
    logging.addLevelName('TRACE', TRACE)

Fíjense el 5 ese: es que DEBUG es 10, entonces queda "más abajo". Claro, para que funcione todo, teníamos que usar un Logger custom:

    class Logger(logging.Logger):
        """Logger that support our custom levels."""

        def trace(self, msg, *args, **kwargs):
            """log at TRACE level"""
            if self.isEnabledFor(TRACE):
                self._log(TRACE, msg, args, **kwargs)

Para más información sobre la infrastructura de logging de Python y consejos generales sobre qué, cómo, o cuándo dejar registro de lo que sucede, pueden ver mi charla sobre el tema (estos sons los slides, y en algún momento se publicará acá el video de esta misma charla que dí en la PyCon de Rafaela).

Read more
facundo

PyCon 2014 en Rafaela


Acaba de pasar la sexta PyCon Argentina. Como dice el título, se hizo en Rafaela, provincia de Santa Fe.

Fuimos con Nico Demarchi en auto, salimos el miércoles a la tarde y llegamos una y monedas de la mañana, volvimos el domingo durante el día, arrancando a media mañana. Creo que es el límite de lo que haría en auto... más distancia ya iría en micro o avión.

Yo tenía que llegar el miércoles a la noche porque el jueves abría el día de talleres con Introducción a Python (modo charla extendida, ya que tenía dos horas). El jueves dí dos charlas más: Cómo debuguear en Python, y Cómo los logs me salvaron el alma.Y para cerrar (justo antes de los sorteos y foto grupal), le conté a la gente un poco cómo íbamos con el proyecto de armar la Asociación Civil de PyAr.

Mis charlas salieron bien, aunque la de debugging no me gustó del todo como la había dado (pero luego recibí buen feedback). Para el taller de Intro a Python usé por primera vez a Pysenteishon, un software muy copado y piola para ir pasando los slides desde el teléfono (¡gracias Emiliano por hacerlo!). Y para las charlas del jueves estuve por primera vez descalzo dando la presentación (era algo que quería probar desde hace rato, y aproveché que el escenario del auditorio tenía piso de madera).

Dando la charla en patas

También fuí a muchas charlas, había muchas cosas copadas para ver, y creo que me salté uno o dos timeslots nada más en toda la conferencia. Las keynotes estuvieron bien, pero no me entusiasmaron particularmente. Y todo lo fue lugar y organización estuvo genial, la verdad que se pasaron. Lo mismo con la gente con la que me (re)encontré: es un placer ser parte de una comunidad así.

Yo llevé la cámara... pero la verdad es que colgué sacando fotos. Pero la grosa de Yami sacó un montón, están todas acá. Y una de las últimas que sacó es justamente la grupal, esta que muestro acá:

Foto grupal

Y como siempre que uno no viaja durmiendo o solo, está el efecto de "PyCon extendida". Es que uno viene charlando de mil cosas, de lo más variado, pero también de proyectos, ideas, etc. Con Nico nos venía rondando en la cabeza una idea para facilitar el uso de dependencias en programas Python, estuvimos charlando con gente en la conferencia, nos dieron feedback, la idea fue mutando... y en el viaje de vuelta se nos terminó de ocurrir algo piola, que no debería ser demasiado loco de implementar; ya les traeré la novedad.

¡Pero no sólo un proyecto me traje! (como si tuviera pocos y/o mucho tiempo libre, ¿no?). Tengo ganas de hacer una "maquinita de timelapse" con una Raspi (una cajita que uno puede colgar en cualquier lado y dejarla ahí algunas horas o un par de días y arme un video de esos donde se ve todo rápido, por ejemplo este). El otro proyecto es armar una valija o caja robusta con todo lo necesario en un PyCamp (router, computadora para caché de repositorios, energía, y varios etcéteras), de manera de tener todo listo y de fácil armado, onda llegás y enchufás. Ya veremos cómo se van desarrollando ambos proyectos...

Read more
facundo

Satélites argentinos


Estos días fue lanzado exitosamente el tercer nanosatélite argentino, "Tita" (llamado así en honor a Tita Merello).

Se llaman "nanosatélites" porque, justamente, son mucho más chicos (y baratos) que los satélites "tradicionales". En particular, Tita pesa unos 25 kilos, está equipado con tres antenas y lleva una cámara para tomar fotos y videos en alta definición.

El satélite Tita, siendo instalado en el lanzador

Lo desarrolló la empresa argentina Satellogic, pero no lo lanzamos nosotros al espacio (todavía no tenemos esa capacidad), sino que fue lanzado desde la ciudad rusa de Yasny. Su objetivo es tomar imágenes durante tres años, en colaboración con otros nanosatélites, los ya lanzados Capitán Beto (llamado así obviamente en referencia a la canción de Spinetta) y Manolito (por el personaje de Mafalda), y a otros 15 satélites que Satellogic planea lanzar durante el próximo año.

Pero Tita es diferente a los dos anteriores, que pesaban alrededor de dos kilos. También es un prototipo, y usa las mismas estrategias de diseño y fabricación con componentes de uso comercial (resortes de ferretería, electrónica de teléfonos celulares y computadoras personales), pero este permite tomar imágenes y videos de dos metros de resolución. Esencialmente, la gente de Satellogic está haciendo lo mismo que hace un satélite convencional, pero a un precio entre cien y mil veces menor.

En este video bastante interesante podemos ver a Lino Barañao (Ministro de Ciencia y Tecnología) y Emiliano Kargieman (CEO de Satellogic), contándonos un poco todo esto (y de paso se ven pasos de la construcción, y las oficinas, ¡donde se ve bastante gente de PyAr trabajando!).



Como detalle final, les dejo este audio de Adrián Paenza hablando sobre los satélites (en general) en el programa La Mañana de Victor Hugo Morales.

Read more
facundo


Entre los viajes y las vacaciones, estos meses terminé viendo un montonazo de películas. Encima, no aparecieron muchas peliculas copadas para anotar a futuro.

Por otro lado, no estuve viendo muchas series. Con Moni estamos viendo Battlestar Galactica, y yo tengo varias a punto de arrancar (Black Mirror, Almost Human, Through The Wormhole S03).

Pero, a nivel de películas, sí recuperé bastante terreno, :)

  • Chronicle: -0. Muy bien desarrollado el tema de cómo llevar adelante, explorar, y en algún punto sobrellevar, un superpoder adquirido. El resto de la película no vale.
  • Contagion: -0. Muestra de forma interesante (y ajustado a la realidad, me parece) el proceso social ante una epidemia, y las actuaciones están bien, pero le falta como película, como historia contada, como relato.
  • Dream house: +0. Predecible, predecible, predeci..WHAT? Un giro loco, la historia está buena, las actuaciones también; quiere ser un toque de terror pero blah.
  • El hombre de al lado: -0. Tiene partes interesantes, y Daniel Araoz está genial, pero la historia no llega a evitar el naufragio.
  • Elefante blanco: +0. Una realidad que uno (yo) no conoce; bien crudo como acostumbra Trapero. Darín está bien como siempre. Podría estar mejor la historia.
  • Ender's game: +1. Es una buena adaptación del libro, y la película está buenísima. Sí, el libro está mejor, tiene toda una parte que en la peli ni aparece, y es mucho más profundo... pero todo eso no hace que la peli en sí deje de estar buena.
  • Habitación en Roma: +1. Una película hermosa, cruda, y maravillosa, sobre el "enamoramiento".
  • Haywire: -0. Una película de acción que tiene algunos buenos actores un poco desaprovechados, tiene partes buenas, pero meh, es una más sin nada que la haga valer específicamente.
  • Killer Elite: -0. Al final no es más que una historia (que sí está buena) donde muchos machotes están todo el tiempo midiendo a ver quien tiene la pistola más larga.
  • Margin call: +1. Impecablemente contado la interna humana de un descarrilamiento financiero. Me gusta mucho el punto de vista del trabajador interno de la empresa, me pareció muy veraz. Muy buenas actuaciones.
  • Men in black III: +0. Divertida. Más de lo mismo pero con lo interesante de los saltos temporales y mostrar como era MIB en el pasado :)
  • Mission: Impossible - Ghost protocol: +0. No deja de ser la misma película fantasiosa de siempre, pero esta vez me divertí bastante al verla.
  • Monsters University: +1. Tan buena como la primera, aunque totalmente distinta.
  • No strings attached: -0. Natalie Portman no la llega a rescatar; el tema es trillado, no le dan un giro interesante, y Kutcher, como siempre, resta.
  • Paul: +0. Comedia liviana, nada espectacular, para reirse un rato y disfrutar todas las referencias extraterrestroides.
  • The Avengers: +0. Un poco demasiado violenta, pero en el límite (me hacía acordar a Transformers). Me divirtió. Me gustó los (escasos) planteos filosóficos que tiene, aunque al final siempre el mensaje de "menos mal que tenemos superheroes que nos van a salvar cuando todo esté mal", con el que estoy totalmente opuesto.
  • The King's speech: +1. Fantástica película, con actuaciones soberbias, y una historia muy interesante sobre superación personal.
  • The Ledge: +1. La historia interesante, las actuaciones bien. Muy buenos contrapuntos sobre "la religión". Emotiva. Patrick Wilson mejor de lo que esperaba, y Terrence Howard, como siempre, muy muy bien.
  • The divide: +1. Muy bien hecha. Muestra tan bien las miserias humanas que, aunque no soy impresionable y me banco (casi) cualquier cosa, no la voy a volver a ver.
  • The hobbit: The desolation of Smaug: +1. Segunda parte de la trilogía, sigue estando muy buena. Sorprendente la voz de Smaug (el dragón), ¡es Sherlock! http://www.imdb.com/name/nm1212722/
  • The thing: +1. Es vieja, pero los efectos no están tan mal. Y parece que tiene un montón de lugares comunes... hasta que uno entiende que en esa época no eran comunes! ;)


Las anotadas nuevas:


Finalmente, el conteo de pendientes por fecha:

(Sep-2008)    6
(Ene-2009)   18  12   1   1
(May-2009)   11  10   5
(Oct-2009)   16  15  14
(Mar-2010)   18  18  18  16   4
(Sep-2010)   18  18  18  18  18   9   2   1
(Dic-2010)   13  13  13  12  12  12   5   1
(Abr-2011)   23  23  23  23  23  23  22  17   4
(Ago-2011)       12  12  11  11  11  11  11  11   4
(Ene-2012)           21  21  18  17  17  17  17  11
(Jul-2012)               15  15  15  15  15  15  14
(Nov-2012)                   12  12  11  11  11  11
(Feb-2013)                       19  19  16  15  14
(Jun-2013)                           19  18  16  15
(Sep-2013)                               18  18  18
(Dic-2013)                                   14  14
(Abr-2014)                                        9
Total:      123 121 125 117 113 118 121 125 121 110

Read more
facundo

PyCamp 2014


Se fue otro PyCamp. Como siempre, genial. Lo charlaba con Moni, es notable como el formato del evento no decae año a año, ¡siguen siendo bárbaros!

Eso sí, voy a tratar de innovar en lo que es la descripción del mismo, escaparme de hacer una cronología, y orientar más el relato a las situaciones.


Llegando y saliendo

Los viajes bien. Como el año pasado, me quedé hasta "cerrar el evento", y también como el año pasado, luego de vaciar el lugar, entregar la llave y eso, nos quedamos algunos tomando unas cervezas en el bar del lugar, hasta que íbamos partiendo en función del horario de bondi de cada uno.

La diferencia estuvo en la llegada, ya que este año no tuvimos al Joven Ocupado en la Accesibilidad y Conectividad (JOAC), así que tuvimos que armar toda la infraestructura de red sin saber demasiado. Viajé con Nico Demarchi, así que al llegar nos pusimos con eso... y aunque no es rocket science, tampoco es trivial, y estuvimos como tres horas para dejar todo lindo!

Una Antena Sable Laser


Proyectos

El proyecto mío en el que más trabajé fue Encuentro, en parte en esta biblioteca para parsear SWFs que vengo necesitando, pero también porque para este proyecto se anotaron varias personas... ¡y metieron un montón de laburo! Tres branches de Mica Bressan, dos de Nico y uno de Emiliano Dalla Verde Marcozzi, y creo que hay otro más dando vuelta por ahí.

También trabajé en un proyecto nuevo, que arrancó en este PyCamp. Es WeFree, un proyecto para almacenar colaborativamente claves de redes, de manera de hacer que tu computadora o teléfono se conecte automáticamente en todos los lados posibles. Participé todo el primer día, en el diseño general y luego armé la interfaz gráfica para la compu (no toda, pero sí la base, dejando algo usable).

Algo en lo que también trabajé desde cero, pero que no sé si se puede calificar como proyecto, fue algo así como la "búsqueda del testrunner perfecto", que describí en este post. Con la ayuda de Martín Gaitán atacamos como base a nose, y le fuimos agregando plugins y probándolos. El experimento fue un éxito, logramos todo lo que queríamos, ya voy a poner un post acá explicando bien el detalle.

Hubo un proyecto que llevé pero en el que yo no trabajé, que fue Linkode, pero Seba Alvarez estuvo haciendo cosas copadas con la interfaz, me tiene que mandar el código.

Finalmente, arranqué ayudando a un par de chicos a migrar código a Python 3, pero no hicimos mucho de eso (aunque aprendimos algunos detalles interesantes).

Laburando en Encuentro con Nico, Mica y Emi (que sacó la foto)


Las noches

Sólo tres, porque el último día uno viaja, pero las aprovechamos a full :)... la gente se va a dormir sorprendentemente tarde luego de lo arduo que son los días. Bah, más sorprendente es que muchos al otro día nos levantamos temprano :p

La primer noche jugué a un juego que no conocía, el Munchkin, ¡y gané!. Está bueno el juego, pero es uno de esos que tenés que leer mil cartitas, entonces las primeras diez veces que jugás se hace un poco lento.

El sábado fue la reunión de PyAr, y después charlé con gente y programé algo, no jugué a nada.

La tercer noche fue doble... Munchkin primero (ganó Matías), y luego jugamos al Carrera de Mente. Hacía como 15 años que no jugaba un Carrera de Mente, no me acordaba que fuese tan divertido! Nos reimos mucho.

Carrera de Mente


Notas de color

Este año Alecu no pudo venir... y Diego Sarmentero se le ocurrió la idea de nombrarlo Lider Inspiracional, y mandó a imprimir dos cuadros, uno para tenerlo durante el día, y otro para tenerlo luego de las cenas.

A nivel de "actividades al aire libre", este año volvimos a repetir la caminata del año pasado hasta el río (fuimos un grupito de unos 10), y también hice paddle con Hugo Ruscitti, Emilio Ramirez y Hernán Lozano. ¡Jugamos un montón! Bah, menos de dos horas, pero nos arreglamos para meter dos partidos (cinco sets rápidos).

También hicimos una key signing party, y Juanjo Ciarlante nos charló un poco de seguridad y buenas costumbres.

Todos


Conclusión

Bien simple, lo afirmo una vez más: ¡PyCamp es el mejor evento del año! (todas las fotos acá).

Read more
facundo

Corriendo tests


En la vida del programador hay una tarea que lleva bastante tiempo, y es la de correr tests, ya sean "unit tests" (pruebas unitarias) o "integration tests" (pruebas donde se hacen interactuar subsistemas entre sí).

Es cierto, no todos los proyectos tienen tests, pero deberían. ¡Y son un vicio! Una vez que los probaste, querés pruebas en todos los proyectos. Pero claro, a los tests hay que correrlos, y hay muchas maneras de hacerlo.

La verdad es que la estructura de los tests es siempre la misma (o casi siempre), obviamente hablando de proyectos en Python, pero la forma de correrlos, y especialmente la forma de presentar los resultados, varía mucho de un corredor de tests a otros.

A lo largo de años he probado distintos, y debo decir que ninguno cumple 100% con lo que a mi me gustaría tener en el test runner ideal. Por otro lado, seguramente alguno (como nosetests, por ejemplo), cumpla gran porcentaje de lo que quiero, es cuestión de lograr lo que falta.

Acá está la listita de las cosas que cumpliría mi test runner soñado. Propuse un proyecto en el PyCamp de este mes para laburar en esto (obviamente no escribir algo desde cero, sino lograr el objetivo con el menor esfuerzo posible).

Le puse un número a cada ítem para que sea más fácil referenciar en cualquier discusión:

01. Debería soportar que le pase un directorio (default a '.') y que descubra todo ahí y para abajo:

        $ <testrunner> project/tests/
        $ <testrunner>

02. Debería soportar que le pase un archivo, y que corra sólo los tests de ese archivo:

        $ <testrunner> project/tests/test_stuff.py

03. Debería soportar que le pase "paths de import de Python", y que corra sólo tests de ese paquete, módulo, clase, o lo que corresponda:

        $ <testrunner> project.tests
        $ <testrunner> project.tests.test_stuff
        $ <testrunner> project.tests.test_stuff.StuffTestCase
        $ <testrunner> project.tests.test_stuff.StuffTestCase.test_feature

04. Debería poder pasarle una regex para que corra sólo lo que re.search() encuentra en el path completo del método:

        $ <testrunner> project/tests/ --search feature
            correría:
                test_feature
                test_feature_1
                test_feature_2
            no correría:
                test_crash

        $ <testrunner> project/tests/ --search feature$
            correría:
                test_feature
            no correría:
                test_feature_1
                test_feature_2
                test_crash

05. Debería poder decirle que pare de correr los tests al encontrar el primer error o falla.

06. Debería poder indicarle que mida los tiempos de cada test (y al final que presente un reporte con los N tests que más tardaron).

07. Debería mostrar los resultados usando los nombres de paquete/módulo/clase/método, en una jerarquía de árbol o en la misma linea:

        $ <testrunner> project/tests/test_stuff.py
        project.tests.test_stuff
          StuffTestCase
            test_feature_1                        OK
            test_feature_2                      FAIL
          OtherStuffTestCase
            test_feature_A                        OK

        $ <testrunner> project/tests/test_stuff.py
        OK    project.tests.test_stuff.StuffTestCase.test_feature_1
        FAIL  project.tests.test_stuff.StuffTestCase.test_feature_2
        OK    project.tests.test_stuff.OtherStuffTestCase.test_feature_A

    De cualquier manera, esto no afecta el órden de ejecución de las pruebas (secuencial, aleatoria, etc), sólo es cómo mostrar los resultados.

08. Los OKs deberían ser verdes; ERRORs y FAILs deberían ser rojos.

09. Los OKs/FAILs/ERRORs para cada prueba, en el listado, deberían estar alineados verticalmente.

10. No debería capturar stdout/stderr.

11. En el reporte final (luego del listado que va mostrando al ejecutar todo), debería mostrar el path completo del test que falla (o de los tests que fallan), junto con el (los) errores, de manera que si uno copia y pega ese path, sirva para correr ese único test.

Read more
facundo

Ya tenemos Encuentro 1.1


Como estoy seguro que ya sabrán de memoria, ;), Encuentro es un simple programa que permite buscar, descargar y ver contenido del Canal Encuentro, Paka Paka, BACUA, Educ.ar y otros.

Acabo de liberar la versión 1.1, que principalmente vuelve a permitir que el programa se autentique luego de unos cambios en el backend de Conectate, pero también tiene muchos bugs solucionados a nivel de manejar errores en las descargas, y también mejoras en la interfaz.

¡Es fácil probarlo! Tenemos instaladores para Debian/Ubuntu, para Windows, en Arch sólo hacen yaourt -S encuentro, e incluso, desde cualquier lado, pueden instalarlo desde PyPI (sudo easy_install encuentro) o directamente usando el tarball.

Todos los detalles, como siempre, en la página oficial. ¡Que lo disfruten!

Read more
facundo


Hola!!

Charlando en el viaje a/desde la PyCon de Rosario, surgió la idea de armar un Circo Errante (flying circus, la referencia es obvia) con el objetivo de acercar PyAr a las Universidades de una forma distinta a las actuales.

Hoy por hoy, el principal contacto de PyAr con las Universidades es de gente que arma PyDays en ese ámbito. Esto, normalmente, sucede en las Universidades con carreras afines a la programación. Y el contenido y dinámica de estos PyDays están pensados en función de ese público.

La idea es cambiar eso. Y llegar desde PyAr a Universidades con las cuales normalmente no tenemos mucho contacto. Ejemplo de esto son las carreras de derecho, sociología, matemática, psicología, astronomía, ingenierías no informáticas, etc. Estas son carreras en las que los profesionales podrían hacer un buen uso de Python como herramienta, donde no les interesa tanto  el razonamiento "quiero hacer un programa que haga algo", sino más bien "necesito hacer algo y un programa podría ser una herramienta, aparte del excel y la calculadora que es lo que estoy usando ahora".

Más en detalle, lo que se nos ocurrió es armar una especie de presentación basada en ejemplos de distintas especialidades. O sea, cómo usar Python para solucionar tal problema en astronomía, cómo usarlo para encontrar tal resultado en sociología, o cómo aprovecharlo para mejorar un análisis en ingeniería en alimentos. Una presentación semigenérica, de 30-40 minutos, que sea como la punta de lanza: si les gusta la idea luego se puede mostrar Python más formalmente; en el peor de los casos se quedarán sólo con conocer la herramienta y tener idea de qué se trata, que no está tan mal.  Obviamente, la idea es armar una presentación que todos podamos usar, no que cada uno arme la suya.

Para organizar esto, armé una página en el wiki con (por ahora) tres secciones: una de ejemplos, para ir juntando ejemplos piolas en los cuales basar la presentación, una de ideas para folletería/merchandising (ver más abajo) y otra de gente interesada en dar estas charlas y la "zona de cobertura".

Luego, habría que ir buscando contactos en las Universidades, para poder charlar con alguien que nos dé un aula con un proyector y que organice internamente para que vaya gente a la presentación.

Con respecto a la folletería/merchandising, tenemos que pensar en algo para llevar a estas reuniones: algo que les muestre el uso de la herramienta más allá del lenguaje (ejemplo: no mostrar como se escribe un for, sino lo fácil que es hacer una normalización de un conjunto de datos). Algo que se lleven los asistentes con ellos, para poder verlo más tarde, y tener el contacto con PyAr para poder venir por más info.

¿Qué les parece?

Read more
facundo


Aparecieron muy cerca en el tiempo dos necesidades muy parecidas: hacer certificados de asistencia para PyCon Argentina 2013, y hacer los certificados para mi curso de Python.

Así nació certg, un generador de certificados, que a la vez es simple, versátil, y útil. El proceso para usarlo es simple:

  1. Armás un .SVG (con Inkscape, por ejemplo), poniendole todo el arte que quieras para que el certificado quede lindo. Pero no lo hacés específico a nadie, sino que dejás escrito variables que se van a reemplazar, como {{nombre}} o {{direccion}} o lo que te guste
  2. Armás un archivo de configuración, donde ponés el nombre del .SVG que creaste, qué variable de las que elegiste es única (se usa luego), y luego una lista de grupos de variables, donde a partir de cada grupo se va a generar un certificado.
  3. Ejecutás el programita en Python, pasándole la configuración que armaste. El programita va a leer el .SVG, y por cada grupo en la config, reemplazar esos valores, y generar un certificado (en PDF) usando el nombre unívoco que indicaste.

La verdad, quedó piola: no es dificil de usar, y es lo suficientemente flexible para las distintas necesidades que tuve. Este es como quedó mi certificado de la PyCon:

Fuí a la PyCon!
El proyecto, con ejemplos y todo, acá.

Read more