Canonical Voices

Posts tagged with 'python'

facundo

PyCon Argentina 2016


El fin de semana pasado fue la octava edición de la conferencia nacional de Python en Argentina. Se realizó en Bahía Blanca, tres días de talleres y charlas.

Yo dí una charla, "Bindings, mutable default arguments, y otros quilom... detalles", y asistí a otras; las que más me gustaron fueron "Poniéndonos un poco más serios con Kivy" por Sofía Martin y alguien más que no recuerdo, "Compartiendo memoria eficientemente con proxies" por Claudio Freire, "Argentina en Python: comunidad, sueños, viajes y aprendizaje" por Humitos, "MicroPython en EDU-CIAA" por Martín Ribelotta, "Redes neuronales con Python utilizando Keras" por Fisa, "Deep learning: aprendiendo con la escafandra" por Javi Mansilla, e "Introducción a programación paralela con PyOpenCL" por Celia Cintas.

Mi charla, renovada

Las keynotes estuvieron muy bien, también. Fernando Schapachnik, de la Fundación Sadosky nos habló del problema de género en las comunidades informáticas (con datos, análisis, y una arenga política al final que estuvo bárbara). Ángel Medinilla nos dío una charla-show-standup sobre metodologías ágiles (excelente presentación). Y la última fue de Victoria Martínez de la Cruz, contando las ventajas y desventajas de trabajar de forma remota (algo que se está imponiendo más y más en las comunidades de software y que está lleno de mitos, así que era muy necesaria).

La organización del evento también estuvo impecable. Se nota que laburaron un montón y salió todo muy bien.

Los asistentes a punto de escuchar una plenaria

Más allá del costado técnico, y de lo que sucede en estos eventos de charlas que se generan, reencuentros, etc, tanto en pasillos como luego de la conferencia en bares o por ahí, quiero destacar el lado "humano"que tuvo esta conferencia.

No sólo las keynotes hablaron de las personas o sus grupos de trabajo, sino que también tuvimos charlas que hicieron lagrimear a varios, como la de Humitos que mencioné arriba o la de Roberto Alsina ("Cómo desarrollar software libre (o no) y no morir en el intento (o no)", que no pude ver pero me contaron). Pero había algo más en el ambiente. Gente comentando lo copada que son organizadores y asistentes en este evento, que cómo te ayudan con todo, que se preocupan, etc. Había muy buena onda por todos lados.

Relajando un poco, en el almuerzo del primer día

Trabajando en uno de los espacios abiertos que había

Hubo una anécdota interesante, también. Resulta que una señora vio en un kiosco a unos asistentes a la conferencia que tenían algo de Python encima. Entonces fue a la escuela de su hijo mayor, de 13 años, lo sacó antes de hora y volvieron a la zona del kiosco (que obviamente, era muy cerca del edificio de la conferencia). Justo pasábamos otros chicos y yo, vieron un pin de Python que llevo en la mochila, y nos preguntaron qué onda. Les contamos de la conferencia, Diego M. les regaló el librito del evento, y listo.

Nosotros pensábamos que terminaba ahí. Nada más lejos.

Al rato volvemos al edificio donde se desarrollaba el evento y vemos que sube a la zona de la conferencia la madre y los dos niños. El pibe de 13 se colgó todo el día yendo de charla en charla, mientras la mamá le hacía el aguante en una zona con sillones. No sólo eso, sino que fueron el sábado y el domingo a la conferencia, y se pasaron todo el finde allí. Notable.

Todas las manos todas

Para cerrar les dejo las fotos que saqué, más esta búsqueda de tuiter que está buena.

Read more
facundo


El evento estuvo dividido principalmente en tres partes, tutoriales para principiantes, conferencia propiamente dicha, y los sprints.

A los tutoriales (Beginners day, y Django girls), que duraban un día, no fui.  La conferencia fue de lunes a viernes. Y los sprints fueron sábado y domingo.  Del primer día de conferencia ya les conté, y el domingo estuve viajando. El resto, se los cuento acá :)


Charlas interesantes

Recopilación de lo que más me gustó de la conferencia... ojo, en algunos casos incluyo links a los videos o presentaciones mismas, en otros no porque me dió paja buscarla, pero tienen que estar :)

Por lejos, la mejor Keynote fue la de Jameson Rollins, "LIGO: The Dawn of Gravitational Wave Astronomy", aunque también estuvo buena la de Naomi Ceder, "Come for the Language, Stay for the Community". Tercera podríamos poner "Scientist meets web dev: how Python became the language of data", por Gaël Varoquaux. El resto me aburrió un poco, o no me interesó tanto.

LIGO is a...

Otras charlas que me gustaron fueron "High Performance Networking in Python" de Yury Selivanov, "Build your first OpenStack application with OpenStack PythonSDK" por Victoria Martinez de la Cruz, "Implementación de un Identificador de Sonido en Python" por Cameron Macleod, "FAT Python: a new static optimizer for Python 3.6" de Victor Stinner, "CFFI: calling C from Python" de Armin Rigo, "The Gilectomy" de Larry Hastings, "A Gentle Introduction to Neural Networks (with Python)" de Tariq Rashid, y "Music transcription with Python" de Anna Wszeborowska.

De esta última charla me quedé con el proyecto a futuro (ya lo anoté, está en la posición 1783461° entre otros proyectos) de mostrar en tiempo real, usando Bokeh, la info que levanta y las transformaciones que va haciendo.

Imagen típica de Bilbao

También quiero resaltar dos lightning talks: a Armin Rigo mostrando un "Reverse debugging for Python", y una de alguien que no me acuerdo mostrando "A better Python REPL".


Mis presentaciones

Ya les hablé de la charla que había dado el lunes, pero aprovecho y les dejo el video de la misma.

El martes dí Entendiendo Unicode, en castellano. Fue la 12° vez que la doy, y me podrán decir "dejá de robar con la misma charla"... qué quieren que les diga, el público se renueva. Yo también a veces pienso si no será demasiado, ¡pero a la gente le gusta y le sirve! Una decena de personas me saludaron y me comentaron lo buena y lo útil que fue la charla. Así que nada, la seguiré ofreciendo en próximas conferencias, :). El video, acá.

Espacio común de trabajo

Además de esas dos presentaciones "largas", dí dos lightning talks. La primera sobre fades; no es la primera vez que la doy, pero la había renovado y traducido al inglés, y estuvo muy bien. La segunda fue sobre Python Argentina. La hice el mismo viernes, a los apurones, pero a la gente le gustó mucho (me sorprendió la cantidad de veces que se rieron en esos cinco minutos (cinco minutos que tuve que pelear, como ven en el video, porque me querían dar dos, luego la confusión de que yo iba a hablar de una PyCon).


Cierre

El sábado, estuve sprinteando, trabajando con fades, más que nada ofreciendo ayuda a gente que quería usarlo o que querían enterarse más sobre el proyecto. Incluso se acercó alguien con un detalle, lo charlamos, lo solucionamos y hasta hice un pull request.

Pintxo

Ese sábado era mi última noche en Bilbao. Medio coordinamos con Juan Luis y fuimos a cenar pinchos con otras personas, luego por una cerveza. Y cuando estaba cerrando la noche, tipo once y media, me comentaron de una zona en la ciudad donde hay toda una movida heavy y punk.

No me la podía perder.

Así que nos fuimos cinco personas hasta allí, saltamos por tres o cuatro bares, tomando algo en cada uno, escuchando muy buena música, terminando en un antro de mala muerte, jugando metegol, pasando música que elegíamos nosotros, y disfrutando mucho.

En un bar punkie

A eso de las dos y media dí por concluido el paseo, porque a las cuatro me pasaba a buscar el taxi, así que con Oriol (uno de los chicos) nos tomamos un taxi, llegué a la habitación, terminé de armar todo, me pegué una ducha, dejé las llaves en la mesa de la cocina y arranqué las 23 horas de viaje que me iban a reecontrar con mi familia :)

Todas las fotos de la conferencia y Bilbao, acá.

Read more
facundo

Europython 2016, Bilbao


Aeropuertos

Estuve cinco horas en el aeropuerto de Río de Janeiro. La comida más elaborada que encontré en las dos terminales fueron sánguches de Subway y panchos. No, gracias.

El aeropuerto de Lisboa, por otro lado, era inmenso y tenía mil locales de comida. Eso sí, ni un cartel de "Bienvenido a Portugal" o similar, que busqué para mandarle foto a los peques...

El único aeropuerto con wifi libre era Aeroparque, en Argentina. El de Río y Lisboa tenían redes que podías usar si tenías contratos con empresas de ahí. En el de Bilbao también pude conseguir internet, luego de registrarme en una página que le fallaba el certificado SSL :/; pero bueno, me sirvió para avisarle a Moni que había llegado bien.


Bilbao

Luego de llegar a donde me hospedé, me pegué un baño y salí a pegar una vuelta (eran las siete y media de la tarde, así que tenía todavía más de dos horas de luz). Algo que me llamó la atención es que la gente, en los barcitos, agarran su cerveza o vino y salen a tomarlo a la calle (el clima estaba hermoso), así que veías un montón de gente super empilchada, con sus copas de tinto o blanco, sentados en los muchos banquitos que hay por todos lados...

Yo me metí un un bar que pintaba lindo, me tomé un par de cervezas con un par de pinchos, y luego arranqué la vuelta. No me fui a dormir demasiado tarde (antes de las doce y media), y habiendo dormido un poco en los dos vuelos cortos, y casi cinco horas en el vuelo largo, no esperaba dormir tanto: me levanté a la una y pico de la tarde!! Parece que el truco de no poner despertador, un oscuro casi absoluto, y no estar pendiente de niños, le aportaron mucho a lo cansadísimo que había llegado al fin de semana...

Parte del Guggenheim a la izquierda, el Puppy a la derecha

Así que me levanté, desayuné y salí a pasear. Me tomé el metro y me fuí para el casco viejo, hice un par de recorridos, saqué un par de fotos, y un par de horas después encaré para uno de los edificios de la conferencia donde se hacía el Django Girls, a saludar conocidos.

Al rato me fui para el edificio principal de la conferencia, donde desde media tarde ya uno se podía registrar, así hacía el trámite el domingo, y de paso encontraba bien el edificio, sabía por donde entrar, etc.

Ahí me encontré con gente que no conocía personalmente pero sí de redes sociales virtuales, estuvimos charlando un rato y después con Juan Luis Cano, Yamila Moreno y otra gente fuimos caminando hasta un funicular, con el que subimos una montaña para mirar la ciudad de arriba.

Desde lo alto

Después nos fuimos a cenar con otra gente a un restaurant bastante piola, comimos rico. Y ya se hicieron las doce, así que volví a donde me hospedé, revisé un rato la charla del lunes, y a dormir!


Primer día de conferencia

Es el día que más charlas tenía marcada. Hubo una plenaria apenas interesante sobre la base de "podés ganar plata haciendo lo que quieras, no tengas miedo de probar", y luego me fuí a una charla de Efficient Django, de la cual me anoté algunos puntos a investigar. Después fui a una charla que mostraba como realmente funciona mezclar AsyncIO y Cython, logrando código asincrónico rapidísimo, y después me tocó a mí.

Yo dí It's not magic: descriptors exposed, la que preparamos con Joac y dimos en la PyCon de Mendoza, pero en inglés. Es una charla difícil, pero creo que la gente se va con info nueva. Hubieron varias preguntas, y luego se me acercaron en los pasillos para seguir charlando del tema, y también me saludaron un par de veces para decirme que la charla les había gustado, así que estoy contento con como salió.

A la tarde estuvo más tranquilo. Una charla que me gustó bastante fue la The Report of Twisted's Death, dada por Amber Brown, una Twisted core developer (y también release manager) que contó en qué estaban, los planes con respecto a asyncio, qué pasaba con Tornado, etc.

An open space in the conference

También me enganché con unos acertijos que te daban en una empresa, algo estilo el pythonchallenge, donde resolver un problema te da la info para encontrar el próximo, y así. La realidad es que era medio buggy, en el segundo acertijo al flaco le marqué dos bugs, y en el último caso le dije que no se podía resolver, y lo hostigué hasta que me pasó la solución y le mostré como no había forma de llegar, :). Así que me gané el premio (una boludez, un hub usb), más que nada por mostrarles a ellos dónde tenían el problema :p.

Como frutilla del postre de la tarde, nos regalaron a todos los asistentes una micro:bit!!! Si no la conocen, una micro:bit es una pequeñísimo hardware que corre Python, que la BBC le regaló a todos los estudiantes de 7 años en el Reino Unido para que jueguen y aprendan. Ahora tengo que ver qué cosas se puede hacer para ponernos con Felipe :D (aunque creo que es un poco más para el año que viene...).

Luego vinieron las lightning talks, y ya se terminó el día!

Read more
facundo

Europython, otra vez


La semana que viene se hace la mayor conferencia de Python de Europa, la Europython. Esta vez es en Bilbao.

Es larga. El domingo hay un día de tutoriales y cursos para principiantes. La conferencia en sí es de lunes a viernes. Y sábado y domingo de la otra semana hay sprints. Pueden ver el schedule online.

alt

Lo que más me entusiasma de esta edición de la conferencia es que voy a ir, :). No es la primera vez que voy, sin embargo; vuelvo luego de once (sí, 11) años de ausencia!!

No sé si me sorprende más eso o que mi blog ya es tan viejo que tengo registro de eso que pasó hace tanto: en estos cuatro posts.

Ahora que lo pienso, hace *años* que tampoco voy a una PyCon US (la default, digamos)...

La frutilla del postre es que esta vez voy a presentar dos charlas, en dos idiomas. En castellano va mi repetidísima "Entendiendo Unicode" (el público se renueva, me dicen algunos; dejá de robar, me dicen otros). Y en inglés la versión anglosajona de la charla que preparamos con joac para la PyCon pasada: "No es magia: Descriptores al desnudo".

Ya les iré reportando como va todo :)

Read more
niemeyer

Over the last several months there has been noticeable and growing pain associated with the evolving integration tests around snapd, and given the project goal of being a cross-distribution platform, we are very keen on solving this problem appropriately so that stability is guaranteed everywhere.

With that mindset a more focused effort was made over the last few weeks to produce a tool that can get the project out of those problems, and onto a runway of more pleasant stability. Despite the short amount of time, I’m very happy about the Spread project which resulted from this effort.

Spread is not Jenkins or Travis, and is not a language or library either. Spread is a tool that will very conveniently ship your code to one or more systems, in parallel, and then offer the right set of options so you can run whatever you need to run to make sure the logic is working, and drive it all from the local system. That implies you can run Spread inside Travis, Jenkins, or your terminal, in a similar way to how your unit tests work.

Here is a short list of interesting facts about Spread:

  • Full-system tests with on demand machine allocation.
  • Multi-backend with Linode and LXD (for local runs) out of the box for now.
  • Multi-language since it can run arbitrary remote code.
  • Agent-less and driven via embedded ssh (kudos to Go team).
  • Convenient harness with project+backend+suite+test prepare and restore scripts.
  • Variants feature for test duplication without copy & paste.
  • Great debugging support – add -debug and stop with a shell inside every failure.
  • Reuse of servers – server allocation is fast, but not allocating is faster.
  • Reasonable test outputs with the shell’s +x mode on failures.
  • … and so forth.

This is all well documented, so I’ll just provide one example here to offer a real taste of how the system feels like.

This is spread.yaml, put in the project root to define the basics:

project: spread

backends:
    lxd:
        systems:
            - ubuntu-16.04
            - ubuntu-14.04

path: /home/test

prepare: |
    echo Entering project...
restore: |
    echo Leaving project...

suites:
    tests/: 
        summary: Integration tests
        prepare: |
            echo Entering suite...
        restore: |
            echo Leaving suite...

The suite name is also the path under which the tests are found.

Then, this is tests/hello/task.yaml:

summary: Greet the world
prepare: |
    echo "Entering task..."
restore: |
    echo "Leaving task..."
environment:
    FOO/a: one
    FOO/b: two
execute: |
    echo "Hello world!"
    [ $FOO = one ] || exit 1

The outcome should be almost obvious (intended feature :-). The one curious detail here is the FOO/a and FOO/b environment variables. This is how to introduce variants, which means this one test will in fact become two: first with FOO=one, and then with FOO=two. Now consider that such environment variables can be defined at any level – project, backend, suite, and task – and imagine how easy it is to test small variations without any copy & paste. After cascading takes place (project→backend→suite→task) all environment variables using a given variant key will be present at once on the same execution.

Now let’s try to run this configuration, including the -debug flag so we get a shell on the failures. Note how with a single test we get four different jobs, two variants over two systems, with the variant b failing as instructed:

$ spread -debug

2016/06/11 19:09:27 Allocating lxd:ubuntu-14.04...
2016/06/11 19:09:27 Allocating lxd:ubuntu-16.04...
2016/06/11 19:09:41 Waiting for LXD container to have an address...
2016/06/11 19:09:43 Waiting for LXD container to have an address...
2016/06/11 19:09:44 Allocated lxd:ubuntu-14.04.
2016/06/11 19:09:44 Connecting to lxd:ubuntu-14.04...
2016/06/11 19:09:48 Allocated lxd:ubuntu-16.04.
2016/06/11 19:09:48 Connecting to lxd:ubuntu-16.04...
2016/06/11 19:09:52 Connected to lxd:ubuntu-14.04.
2016/06/11 19:09:52 Sending project data to lxd:ubuntu-14.04...
2016/06/11 19:09:53 Connected to lxd:ubuntu-16.04.
2016/06/11 19:09:53 Sending project data to lxd:ubuntu-16.04...

2016/06/11 19:09:54 Error executing lxd:ubuntu-14.04:tests/hello:b :
-----
+ echo Hello world!
Hello world!
+ [ two = one ]
+ exit 1
-----

2016/06/11 19:09:54 Starting shell to debug...

lxd:ubuntu-14.04 ~/tests/hello# echo $FOO
two
lxd:ubuntu-14.04 ~/tests/hello# cat /etc/os-release | grep ^PRETTY
PRETTY_NAME="Ubuntu 14.04.4 LTS"
lxd:ubuntu-14.04 ~/tests/hello# exit
exit

2016/06/11 19:09:55 Error executing lxd:ubuntu-16.04:tests/hello:b :
-----
+ echo Hello world!
Hello world!
+ [ two = one ]
+ exit 1
-----

2016/06/11 19:09:55 Starting shell to debug...

lxd:ubuntu-16.04 ~/tests/hello# echo $FOO
two
lxd:ubuntu-16.04 ~/tests/hello# cat /etc/os-release | grep ^PRETTY
PRETTY_NAME="Ubuntu 16.04 LTS"
lxd:ubuntu-16.04 ~/tests/hello# exit
exit


2016/06/11 19:10:33 Discarding lxd:ubuntu-14.04 (spread-129)...
2016/06/11 19:11:04 Discarding lxd:ubuntu-16.04 (spread-130)...
2016/06/11 19:11:05 Successful tasks
2016/06/11 19:11:05 Aborted tasks: 0
2016/06/11 19:11:05 Failed tasks: 2
    - lxd:ubuntu-14.04:tests/hello:b
    - lxd:ubuntu-16.04:tests/hello:b
error: unsuccessful run

This demonstrates many of the stated goals (parallelism, clarity, convenience, debugging, …) while running on a local system. Running on a remote system is just as easy by using an appropriate backend. The snapd project on GitHub, for example, is hooked up on Travis to run Spread and then ship its tests over to Linode. Here is a real run output with the initial tests being ported, and a basic smoke test.

If you like what you see, by all means please go ahead and make good use of it.

We’re all for more stability and sanity everywhere.

@gniemeyer

Read more
facundo

Ordenando fotos


Hace un par de semanas sucediose el PyCamp. En este tipo de eventos, como en tantos otros, o paseos, o reuniones, o lo que sea, pasa que uno lleva "la cámara", pero no la usa todo el tiempo.

Con "la cámara" me refiero al dispositivo para sacar fotos de mejor calidad que uno tiene. Puede ser una reflex toda pipona, o una point and shoot berretona, o algo intermedio (o "bridge") como la que tengo yo (una Canon G15).

Canon G15

Y uno no la usa todo el tiempo por dos razones. La primera es que en general, a menos que sea una point and shoot finiiiiita, molesta un poco llevarla: te ocupa al menos una mano, o rellena bastante un bolsillo, o hay que llevarla al cuello, o hay que llevar todo un bolso al hombro.

La segunda razón es que como las cámaras en los teléfonos avanzaron bastante, uno siempre termina sacando fotos al voleo más con el celular que con otra cosa, y deja para momentos "más cuidados" el usar "la cámara".

Y me pasa todo el tiempo. Ejemplo típico del del PyCamp: tengo la cámara en la mochila, donde la guardé luego de sacar un par de fotos donde estábamos trabajando, pero luego fui a otro lado a preguntarle algo a alguien, y tuve ganas de sacar una determinada foto, y en el momento lo resolví con el teléfono. No iba a volver a buscar la cámara grande. O la sacaba con el teléfono, o no la sacaba.

Entonces, esta combinación de factores hizo que, en los últimos tiempos, termine con una serie de fotos de la cámara grande, más una serie de fotos del teléfono. Separadas.

Yo miro/edito las fotos con distintas herramientas. Pero en general, las veo ordenadas por el nombre del archivo. Entonces, tener dos series de fotos separadas me jodía bastante.

Es por eso que me armé un pequeño script que agarra todas las fotos de un directorio y las renombra en función de la fecha/hora que tiene guardada la foto, quedando ambas series efectivamente mezcladas de forma cronológica al ordenarlas por el nombre del archivo.

Un par de detalles con respecto al script.

  • Todavía está en desarrollo, pero está bastante estable y las últimas veces que lo usé anduvo 100% ok
  • Asume que las fotos de "la cámara" tienen el formato IMG99999.JPG, siendo los 99999 cinco dígitos cualesquiera. Si este no es tu caso, vas a tener que pedirme una mejora, o toquetear vos misma/o el código.
  • Tenés que tener fades instalado, para que te maneje automágicamente las dependencias (acá tenés una explicación al respecto). Si no querés instalar fades, arreglate.

Enjoy.

Read more
facundo

PyCamp 2016


Durante este finde largo de semana santa hicimos la edición 2016 del PyCamp, el que para mí es el mejor evento del año.

Se realizó nuevamente en La Serranita, un lugar muy lindo y muy cómodo, el Complejo Soles Blancos. A diferencia del año pasado, que fue en Agosto, esta vez a la noche sólo estuvo bastante fresco, :). Las tardes eran con un lindo calorcito, y las noches y madrugadas estaban fresconas, ideal para pasear por la calle o dormir!

Como la vez pasada, hice Buenos Aires - Córdoba (Capital) en micro, y de ahí a La Serranita en auto (a la vuelta lo mismo). Es más, el trayecto de ida lo manejé yo (porque Pancho estaba rotazo), y la vuelta la hizo él, con lo que pude disfrutar más del paisaje.

Alta vista

Como todos los PyCamps, este se dividió mucho entre lo que es Python propiamente dicho, y lo que son otras actividades. Arranquemos con lo que es programación propiamente dicho.

El proyecto más largo en el que participé fue un Tower Defense: el típico jueguito donde uno ubica torres que atacan un flujo de enemigos que se vienen encima, y en función de la habilidad de colocar qué torres y dónde, uno se defiende mejor o peor. La idea era no sólo diseñar y armar el juego, sino también crear una inteligencia artificial que aprendiera a ubicar las torres.

En esto se anotaron casi todos, así que fue con lo primero que arrancamos. Lo más interesante fue la organización. En seguida separamos lo que es "core" de la "ai", y un grupo se quedó arriba y otro nos fuimos para la sala de abajo. No sé bien qué hicieron los de AI, arriba, pero abajo armamos entre todos la estructura básica del core, nos separamos en pequeños grupos, y atacamos todo el código en paralelo, charlando las interfaces/APIs a medida que íbamos agregando o solucionando cosas.

Fue genial. El primer día ya teníamos como un 80% de lo que logramos finalmente, y luego seguimos trabajando. El producto fue un core a todo lujo, con gráficos y todo (usamos pyglet), más una inteligencia artificial que aprendía eficientemente a ubicar las torres. Impecable.

Screenshot del TD

De los proyectos que llevaba yo, en el que más se enganchó la gente fue fades. Como con Nico tenemos los issues bien claritos y clasificados, los chicos encontraban enseguida algo para hacer. Metimos varios fixes y cerramos muchos issues, se avanzó bastante. También se anotaron varios para trabajar en la web de PyAr, se avanzó un poco, sobre problemas de formateo y links rotos (porque no existen, pero también porque apuntan mal internamente en el wiki). No hicimos tanto, quedó pendiente para seguir en otro momento. También otro grupo (principalmente Matu Varela, Mati Barrientos y Toni) estuvieron con la integración del sitio de PyAr y unos bots de Telegram, que originalmente estaban planeados para desparramar info, pero sobre los cuales luego armaron esquemas de moderación de noticias, eventos y trabajos postulados.

Con otros proyectos estuve también bastante tiempo, pero con menos gente. Para Linkode estuvimos charlando mucho con Mati Barrientos y Pablo Celayes, sobre los próximos planes a nivel de interfaz. Decidimos ir a algo como una "single page application" pero que apenas es tal, porque la interfaz de linkode es muy sencilla. Así y todo, la idea es que el "cliente web" use la API de linkode como cualquier otro cliente. Más allá de toda la charla y la decisión de cómo seguir para adelante, Matías va a estar liderando todo el lado "javascript" de linkode, metiendo código él y revisando/empujando el de otros.

Gente trabajando

Para cerrar todo lo hecho, y el PyCamp en sí, hicimos un video! Jose Luis Zanotti tiene pendiente de editarlo y armarlo, así mostramos todo lo que hicimos en un par de días...

Y por otro lado, hubieron varias actividades no relacionadas directamente con programar en Python.

El más centralizadamente coordinado fue un torneo de Tron, que ganó Jose Luis Zanotti Ya habíamos hecho algo parecido en el PyCamp de La Falda, hace varios años, y es notable como uno se engancha mirando a las personas que compiten y cómo juegan. También hubieron clases de sable, una tarde, y noches de juegos de mesa. Yo jugué dos veces al Resistance, un juego donde (aunque tiene soporte de fichas y tarjetitas) lo importante es la interacción entre las personas y como todos se tratan de convencer entre todos de que no son nazis.

La estrella de las actividades de "no programación" fue la reunión de PyAr (gracias Ariel por armar la minuta). Estuvo buenísima, por cuanto y cómo participaron todos. Charlamos de la próxima PyCon, de cómo venía el tema de la creación de la Asociación Civil, y también del PyCamp actual, y cosas que deberíamos mantener o mejorar. Luego de la reunión, un asadazo, que lo preparó (muy bien, como siempre), el anfitrión del complejo, Leandro.

En la reunión

Todas las fotos que saqué yo, acá.

Read more
Robin Winslow

It’s becoming more and more important for websites to carefully consider how their resources are cached in users’ browsers. Get the caching wrong, and you either end up with a woefully slow experience for the user, or a very strange looking website as users are left with stale CSS files and images.

Or often both.

For our China site, we’ve decided that the HTML pages should be cached for 5 minutes, and the CSS and JavaScript can be cached for a year – as every time we update them we change the URL.

Caching headers in Django

Telling the browser how long to cache a resource is done with one of two headers:

  • Cache-Control: In HTTP/1.1, this can set the maximum age before a resource should be re-downloaded.
  • Expires: In the older HTTP/1.0 standard, this sets the date and time that a resource becomes outdated and should be refreshed.

To control these headers in Django is less simple than you might think. If you’re happy to use the cache framework then it will take care of these headers for you, but as we have a separate Squid cache in front of our application, this was a more heavyweight solution than we needed.

Modifying HTML responses using View classes

In our case, all of our HTML pages are served with an extended version of the TemplateView class:

To add headers, we need to modify the HTTPResponse, which we can intercept by extending the render_to_response method.

Django also provides patch_response_headers a handy helper function to generate our caching headers for us and attach them to the response:

And now we can see our extra caching headers in the HTTP response:

Browsers and proxies will now cache the HTML pages for 5 minutes.

Controlling caching for static files

Django recommends serving static files separately from the rest of your application.

However, for simplicity and dev-prod parity we’ve been using DJ-Static to serve static files with the Django WSGI app, as introduced by Kenneth Reitz. This was also, at the time we implemented it, the method recommended by Heroku for managing static files in Django.

However, as it turns out DJ-Static doesn’t offer any control over caching headers. And Heroku now recommend using WhiteNoise instead.

Serving static files with WhiteNoise is pretty simple (as it was with DJ-Static):

WhiteNoise will add a Cache-Control header, although it doesn’t support set the older Expires header. By default, the Cache-Control header is initially set to no caching:

We wanted our static files to be cached for a year, so we set the WHITENOISE_MAX_AGE setting in settings.py:

This will set the max-age in the Cache-Control header to achieve the browser caching we’re looking for:

Now we have control

Leveraging browser caching is an invaluable tool in performance, and so understanding how we can control the user’s cache with Django is very helpful.

Hopefully I’ve demonstrated some ways that this can be achieved, which we’ve just implemented on cn.ubuntu.com.

Also published on my blog.

Read more
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
Robin Winslow

Last weekend I went to my first Pycon, my second conference in a fortnight.

The conference runs from Friday to Monday, with 3 days of talks followed by one day of “sprints”, which is basically a hack day.

PyCon has a code of conduct to discourage any form of othering:

Happily, PyCon UK is a diverse community who maintain a reputation as a friendly, welcoming and dynamic group.

We trust that attendees will treat each other in a way that reflects the widely held view that diversity and friendliness are strengths of our community to be celebrated and fostered.

And for me, the conference lived up to this, with a very friendly feel, and a lot of diversity in its attendants. The friendly and informal atmosphere was impressive for such a large event with more than 450 people.

Unfortunately, the Monday sprint day was cut short by the discovery of an unexploded bomb.

Many keynotes, without much Python

There were a lot of “keynote” talks, with 2 on Friday, and one each on Saturday and Sunday. And interestingly none of them were really about Python, instead covering future technology, space travel and the psychology of power and impostor syndrome.

But of course there were plenty of Python talks throughout the rest of the day – you can read about them on my other post. And I think it was a good decision to have more abstract keynotes. It shows that the Python community really is more of a general community than just a special interest group.

Van Lindberg on data economics, Marx and the Internet of Things

In the opening keynote on Friday morning, the PSF chairman showed that total computing power is almost doubling every year, and that by 2020, the total processing power in portable devices will exceed that in PCs and servers.

He then used the fact that data can’t travel faster than 11.8 inches per nanosecond to argue that we will see a fundamental shift in the economics of data processing.

The big-data models of today’s tech giants will be challenged as it starts to be quicker and make more economic sense to process data at source, rather than transfer it to distant servers to be processed. Centralised servers will be relegated to mere aggregators of pre-processed data.

He likened this to Marx seizing the means of production in a movement which will empower users, as our portable Things start to hold the real information, and choose who to share it with.

I really hope he’s right, and that the centralised data companies are doomed to fail to be replaced by the Internet of Autonomous Things, because the world of centralised data is not an equal world.

Does Python have a future on small processors? Isn’t it too inefficient?

In a world where all the interesting software is running on light-weight portable devices, processing efficiency becomes important once again. Van used this to argue that efforts to run Python effectively on low-powered devices, like MicroPython, will be essential for Python as a language to survive.

Daniele Procida: All I really want is power

The second keynote was just after lunch on Friday, Daniele Procida, organiser of DjangoCon Europe openly admitted that what he really wanted out of life was power. He put forward the somewhat controversial idea that power and usefulness are the same thing, and that ideas without power are useless.

He made the very good point that power only comes to those who ask for it, or fight for it. And that if we want power not to be abused, we really need to talk about it a whole lot more, even though it makes people uncomfortable (try asking someone their salary). We should acknowledge who has the power, and what power we have, and watch where the power goes.

He suggested that, while in politics or industry, power is very much a rivalled good, in open source it is entirely an unrivalled good. The way you grab power in the open source community is by doing good for the community, by helping out. And so by weilding power you are actually increasing power for those around you.

I don’t agree with him on this final point. I think power can be and is hoarded and abused in the open source community as well. A lot of people use their power in the community to edge out others, or make others feel small, or to soak up influence through talks and presentations and then exert their will over the will of others. I am certainly somewhat guilty of this. Which is why we should definitely watch the power, especially our own power, to see what effect it’s having.

The takeaway maxim from this for me is that we should always make every effort to share power, as opposed to jealously guarding it. It’s not that sharing power in the open source community is inevitable or necessarily comes naturally, but at least in the open source community sharing power genuinely can help you gain respect, where I fear the same isn’t so true of politics or industry.

Dr Simon Sheridan: Landing on a comet: From planning to reality

Simon Sheridan was an incredibly most humble and unassuming man, given his towering achievements. He is a world-class space scientist who was part of the European Space Agency team who helped to land Rosetta on comet 67P.

Most of what he mentioned was basically covered in the news, but it was wonderful to hear it from his perspective.

Naomi Ceder: Confessions of a True Impostor

When, a short way into her Sunday morning keynote, Naomi Ceder asked the room:

How many of you would say that you have in some way or another suffered from imposter syndrome along with me?

Almost everybody put their hands up. This is why I think this was such an important talk.

She didn’t talk about this per se, but contributing to the open source community is hard. No-one talks about it much, but I certainly feel there’s a lot of pressure. Because of its very nature, your contributions will be open, to be seen by anyone, to be criticised by anyone. And let’s face it, your contributions are never going to be perfect. And the rules of the game aren’t written down anywhere, so the chance of being ridiculed seem pretty high. Open source may be a benevolent idea, but it’s damned scary to take part in.

I believe this is why less than 2% of open source contributors are female, compared with more like 25-30% women in software development in general. And, as with impostor syndrome, the same trend is true of other marginalised groups. It’s not surprising to me that people who are used to being criticised and discriminated against wouldn’t subject themselves to that willingly.

And, as Naomi’s question showed, it is not just marginalised people who feel this pressure, it’s all of us. And it’s a problem. As we know, confidence is no indicator of actual ability, meaning that many many talented people may be too scared to contribute to open source.

As Naomi pointed out, impostor syndrome is a socially created condition – when people are expected to do badly, they do badly. In fact I completely agree with her suggestion that the existing Wikipedia definition of impostor syndrome (at the time of writing) could be more sensitively phrased to define it as a “social condition” rather than a “psychological phenomenon”, as well as avoiding singling out women.

While Naomi chose to focus in her talk on how we personally can try to mitigate feelings of being an impostor, I think the really important message here is one for the community. It’s not our fault that open source is scary, that’s just the nature of openness. But we have to make it more welcoming. The success of the open source movement really does depend on it being diverse and accepting.

What I think is really interesting is that stereotype threat can be mitigated by reminding people of their values, of what’s important to them. And this is what I hope will save open source. The more we express our principles and passion for open source, the more we express our values, the easier it is to counter negative feelings, to be welcoming, to stop feeling like impostors.

A great conference

Overall, the conference was exhausting, but I’m very grateful that I got to attend. It was inspiring and informative, and a great example of how to maintain a great community.

If you want you can now go and read about the other talks.

(Also published on robinwinslow.co.uk)

Read more
Robin Winslow

The weekend before last, I went to PyCon UK 2015.

I already wrote about the keynotes, which were more abstract. Here I’m going to talk about the other talks I saw, which were generally more technical or at least had more to do with Python.

Summary

The talks I saw covered a whole range of topics – from testing through documentation and ways to achieve simplicity to leadership. Here are some key take-aways:

The talks

Following are slightly more in-depth summaries of the talks I thought were interesting.

Friday

Leadership of Technical Teams – Owen Campbell

There were two key points I took away from this talk. The first was Owen’s suggestion that leaders should take every opportunity to practice leading. Find opportunities in your personal life to lead teams of all sorts.

The second point was more complex. He suggested that all leaders exist on two spectra:

  • Amount of control: hand-off to dictatorial
  • Knowledge of the field: novice to expert

The less you know about a field the more hands-off you should be. And conversely, if you’re the only one who knows what you’re talking about, you should probably be more of a dictator.

Although he cautioned that people tend to mis-estimate their ability, and particularly when it comes to process (e.g. agile), people think they know more than they do. No-one is really an expert on process.

He suggested that leading technical teams is particularly challenging because you slide up and down the knowledge scale on a minute-to-minute basis sometimes, so you have to learn to be authoritative one moment and then permissive the next, as appropriate.

Document all the things – Kristian Glass

Kristian spoke about the importance, and difficulty, of good documentation.
Here are some particular points he made:

  • Document why a step is necessary, as well as what it is
  • Remember that error messages are documentation
  • Try pair documentation – novice sitting with expert
  • Checklists are great
  • Stop answering questions face-to-face. Always write it down instead.
  • Github pages are better than wikis (PRs, better tracking)

One of Kristian’s main points was that it goes against the grain to write documentation, ‘cos the person with the knowledge can’t see why it’s important, and the novice can’t write the documentation.

He suggested pair documentation as a solution, which sounds like a good idea, but I was also wondering if a StackOverflow model might work, where users submit questions, and the team treat them like bugs – need to stay on top of answering them. This answer base would then become the documentation.

Saturday

Asking About Gender – the Whats, Whys and Hows – Claire Gowler

Claire spoke about how so many online forms expect people to be either simply “male” or “female”, when the truth can be much more complicated.

My main takeaway from this was the basic point that forms very often ask for much more information than they need, and make too many assumptions about their users. When it comes to asking someone’s name, try radically reducing the complexity by just having one text field called “name”. Or better yet, don’t even ask their name if you don’t need it.

I think this feeds into the whole field of simplicity very nicely. A very many apps try to do much more than they need to, and ask for much more information than they need. Thinking about how little you know about your user can help you realise what you actually don’t need to know about your user.

Finding more bugs with less work – David R. MacIver

David MacIver is the author of the Hypothesis testing library.

Hypothesis is a Python library for creating unit tests which are simpler to write and more powerful when run, finding edge cases in your code you wouldn’t have thought to look for. It is stable, powerful and easy to add to any existing test suite.

When we write tests normally, we choose the input cases, and we normally do this and we often end up being really kind to our tests. E.g.:

What Hypothesis does it help us test with a much wider and more challenging range of values. E.g.:

There are many cases where Hypothesis won’t be much use, but it’s certainly good to have in your toolkit.

Sunday

Simplicity Is A Feature – Cory Benfield

Cory presented simplicity as the opposite of complexity – that is, the fewer options something gives you, the more simple and straightforward it is.

“Simplicity is about defaults”

To present as simple an interface as possible, the important thing is to have many sensible defaults as possible, so the user has to make hardly any choices.

Cory was heavily involved in the Python Requests library, and presented it as an example of how to achieve apparent simplicity in a complex tool.

“Simple things should be simple, complex things should be possible”

He suggested thinking of an “onion model”, where your application has layers, so everything is customisable at one of the layers, but the outermost layer is as simple as possible. He suggested that 3 layers is a good number:

  • Layer 1: Low-level – everything is customisable, even things that are just for weird edge-cases.
  • Layer 2: Features – a nicer, but still customisable interface for all the core features.
  • Layer 3: Simplicity – hardly any mandatory options, sensible defaults
    • People should always find this first
    • Support 80% of users 80% of the time
    • In the face of ambiguity do the right thing

He also mentioned that he likes README driven development, which seems like is an interesting approach.

How (not) to argue – a recipe for more productive tech conversations – Harry Percival

I think this one could be particularly useful for me.

Harry spoke about how many people (including him) have a very strong need to be right. Especially men. Especially those who went to boarding school. And software development tends to be full of these people.

Collaboration is particularly important in open source, and strongly disagreeing with people rarely leads to consensus, in fact it’s more likely to achieve the opposite. So it’s important that we learn how to get along.

He suggests various strategies to try out, for getting along with people better:

  • Try simply giving in, do it someone else’s way once in a while (hard to do graciously)
  • Socratic dialogue: Ask someone to explain their solution to you in simple terms
  • Dogfooding – try out your idea before arguing for its strength
  • Bide your time: Wait for the moment to see how it goes
  • Expose yourself to other social situations, where arguments are less acceptable

All of this comes down to stepping back, waiting and exercising humility. All of which are easier said than done, but all of which are very valuable if I could only manage it.

FIDO – The dog ate my password – Alex Willmer

After covering fairly common ground of how and why passwords suck, Alex introduced the FIDO alliance.

The FIDO alliance’s goal is to standardise authentication methods and hopefully replace passwords. They have created two standards for device-based authentication to try to replace passwords:

  • UAF: First-factor passwordless biometric authentication
  • U2F: Second-factor device authentication

Browsers are just starting to support U2F, whereas support for UAF is farther off. Keep an eye out.

Data Visualisation with Python and Javascript – crafting a data-visualisation for the web – Kyran Dale

Kyran spoke about visualising data, and demoed using Scrapy and Pandas to retrieve the Nobel laureatte data from Wikipedia, using Flask to serve it as a RESTful API, and then using D3 to create an interactive browser-based visualisation.

(Also published on robinwinslow.co.uk)

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
Barry Warsaw

Background

Snappy Ubuntu Core is a new edition of the Ubuntu you know and love, with some interesting new features, including atomic, transactional updates, and a much more lightweight application deployment story than traditional Debian/Ubuntu packaging.  Much of this work grew out of our development of a mobile/touch based version of Ubuntu for phones and tablets, but now Ubuntu Core is available for clouds and devices.

I find the transactional nature of upgrades to be very interesting.  While you still get a perfectly normal Ubuntu system, your root file system is read-only, so traditional apt-get based upgrades don't work.  Instead, your system version is image based; today you are running image 231 and tomorrow a new image is released to get you to 232.  When you upgrade to the new image, you get all the system changes.  We support both full and delta upgrades (the latter which reduces bandwidth), and even phased updates so that we can roll out new upgrades and quickly pull them from the server side if we notice a problem.  Snappy devices even support rolling back upgrades on a single device, by using a dual-partition root file system.  Phones generally don't support this due to lack of available space on the device.

Of course, the other part really interesting thing about Snappy is the lightweight, flexible approach to deploying applications.  I still remember my early days learning how to package software for Debian and Ubuntu, and now that I'm both an Ubuntu Core Developer and Debian Developer, I understand pretty well how to properly package things.  There's still plenty of black art involved, even for relatively easy upstream packages such as distutils/setuptools-based Python package available on the Cheeseshop (er, PyPI).  The Snappy approach on Ubuntu Core is much more lightweight and easy, and it doesn't require the magical approval of the archive elves, or the vagaries of PPAs, to make your applications quickly available to all your users.  There's even a robust online store for publishing your apps.

There's lots more about Snappy apps and Ubuntu Core that I won't cover here, so I encourage you to follow the links for more information.  You might also want to stop now and take the tour of Ubuntu Core (hey, I'm a poet and I didn't even realize it).

In this post, I want to talk about building and deploying snappy Python applications.  Python itself is not an officially supported development framework, but we have a secret weapon.  The system image client upgrader -- i.e. the component on the devices that checks for, verifies, downloads, and applies atomic updates -- is written in Python 3.  So the core system provides us with a full-featured Python 3 environment we can utilize.

The question that came to mind is this: given a command-line application available on PyPI, how easy is it to turn into a snap and install it on an Ubuntu Core system?  With some caveats I'll explore later, it's actually pretty easy!

Basic approach

The basic idea is this: let's take a package on PyPI, which may have additional dependencies also on PyPI, download them locally, and build them into a snap that we can install on an Ubuntu Core system.

The first question is, how do we build a local version of a fully-contained Python application?  My initial thought was to build a virtual environment using virtualenv or pyvenv, and then somehow turn that virtual environment into a snap.  This turns out to be difficult in practice because virtual environments aren't really designed for this.  They have issues with being relocated for example, and they can contain a lot of extraneous stuff that's great for development (virtual environment's actual purpose ) but unnecessary baggage for our use case.

My second thought involved turning a Python application into a single file executable, and from there it would be fairly easy to snappify.  Python has a long tradition of such tools, many with varying degrees of cross platform portability and standalone-ishness.  After looking again at some oldies but goodies (e.g. cx_freeze) and some new offerings, I decided to start with pex.

pex is a nice tool developed by Brian Wickman and the Twitter folks which they use to deploy Python applications to their production environment.  pex takes advantage of modern Python's support for zip imports, and a clever trick of zip files.

Python supports direct imports (of pure Python modules) from zip files, and the python executable's -m option works even when the module is inside a zip file.  Further, the presence of a __main__.py file within a package can be used as shorthand for executing the package, e.g. python -m myapp will run myapp/__main__.py if it exists.

Zip files are interesting because their index is at the end of the file.  This allows you to put whatever you want at the front of the file and it will still be considered a zip file.  pex exploits this by putting a shebang in the first line of the file, e.g. #!/usr/bin/python3 and thus the entire zip file becomes a single file executable of Python code.

There are of course, plenty of caveats.  Probably the main one is that Python cannot import extension modules directly from the zip, because the dlopen() function call only takes a file system path.  pex handles this by marking the resulting file as not zip safe, so the zip is written out to a temporary directory first.

The other issue of course, is that the zip file must contain all the dependencies not present in the base Python.  pex is actually fairly smart here, in that it will chase dependencies, much like pip and it will include those dependencies in the zip file.  You can also specify any missed dependencies explicitly on the pex command line.

Once we have the pex file, we need to add the required snappy metadata and configuration files, and run the snappy command to generate the .snap file, which can then be installed into Ubuntu Core.  Since we can extract almost all of the minimal required snappy metadata from the Python package metadata, we only need just a little input from the user, and the rest of work can be automated.

We're also going to avail ourselves of a convenient cheat.  Because Python 3 and its standard library are already part of Ubuntu Core on a snappy device, we don't need to worry about any of those dependencies.  We're only going to support Python 3, so we get its full stdlib for free.  If we needed access to Python 2, or any external libraries or add-ons that can't be made part of the zip file, we would need to create a snappy framework for that, and then utilize that framework for our snappy app.  That's outside the scope of this article though.

Requirements

To build Python snaps, you'll need to have a few things installed.  If you're using Ubuntu 15.04, just apt-get install the appropriate packages.  Otherwise, you can get any additional Python requirements by building a virtual environment and installing tools like pex and wheel into their, then invoking pex from that virtual environment.  But let's assume you have the Vivid Vervet (Ubuntu 15.04); here are the packages you need:
  •  python3
  •  python-pex-cli
  •  python3-wheel
  •  snappy-tools
  •  git
You'll also want a local git clone of https://gitlab.com/warsaw/pysnap.git which provides a convenient script called snap.py for automating the building of Python snaps.  We'll refer to this script extensively in the discussion below.

For extra credit, you might want to get a copy of Python 3.5 (unreleased as of this writing).  I'll show you how to do some interesting debugging with Python 3.5 later on.

From PyPI to snap in one easy step

Let's start with a simple example: world is a very simple script that can provide forward and reverse mappings of ISO 3166 two letter country codes (at least as of before ISO once again paywalled the database).  So if you get an email from guido@example.py you can find out where the BDFL has his secret lair:

$ world py
py originates from PARAGUAY

world is a pure-Python package with both a library and a command line interface. To get started with the snap.py script mentioned above, you need to create a minimal .ini file, such as:

[project]
name: world

[pex]
verbose: true

Let's call this file world.ini.  (In fact, you'll find this very file under the examples directory in the snap git repository.)  What do the various sections and variables control?
  •  name is the name of the project on PyPI.  It's used to look up metadata about the project on PyPI via PyPI's JSON API.
  •  verbose variable just defines whether to pass -v to the underlying pex command.
Now, to create the snap, just run:

$ ./snap.py examples/world.ini

You'll see a few progress messages and a warning which you can ignore.  Then out spits a file called world_3.1.1_all.snap.  Because this is pure Python, it's architecture independent.  That's a good thing because the snap will run on any device, such as a local amd64 kvm instance, or an ARM-based Ubuntu Core-compatible Lava Lamp.

Armed with this new snap, we can just install it on our device (in this case, a local kvm instance) and then run it:

$ snappy-remote --url=ssh://localhost:8022 install world_3.1.1_all.snap
$ ssh -p 8022 ubuntu@localhost
ubuntu@localhost:~$ world.world py
py originates from PARAGUAY

From git repository to snap in one easy step

Let's look at another example, this time using a stupid project that contains an extension module. This aptly named package just prints a yes for every -y argument, and no for every -n argument.

The difference here is that stupid isn't on PyPI; it's only available via git.  The snap.py helper is smart enough to know how to build snaps from git repositories.  Here's what the stupid.ini file looks like:

[project]
name: stupid
origin: git https://gitlab.com/warsaw/stupid.git

[pex]
verbose: yes

Notice that there's a [project]origin variable.  This just says that the origin of the package isn't PyPI, but instead a git repository, and then the public repo url is given.  The first word is just an arbitrary protocol tag; we could eventually extend this to handle other version control systems or origin types.  For now, only git is supported.

To build this snap:

$ ./snap.py examples/stupid.ini

This clones the repository into a temporary directory, builds the Python package into a wheel, and stores that wheel in a local directory.  pex has the ability to build its pex file from local wheels without hitting PyPI, which we use here.  Out spits a file called stupid_1.1a1_all.snap, which we can install in the kvm instance using the snappy-remote command as above, and then run it after ssh'ing in:

ubuntu@localhost:~$ stupid.stupid -ynnyn
yes
no
no
yes
no

Watch out though, because this snap is really not architecture-independent. It contains an extension module which is compiled on the host platform, so it is not portable to different architectures.  It works on my local kvm instance, but sadly not on my Lava Lamp.

Entry points

pex currently requires you to explicitly name the entry point of your Python application.  This is the function which serves as your main and it's what runs by default when the pex zip file is executed.

Usually, a Python package will define its entry point in its setup.py file, like so:

setup(
    ...
    entry_points={
        'console_scripts': ['stupid = stupid.__main__:main'],
        },
    ...
    )

And if you have a copy of the package, you can run a command to generate the various package metadata files:

$ python3 setup.py egg_info

If you look in the resulting stupid.egg_info/entry_points.txt file, you see the entry point clearly defined there.  Ideally, either pex or snap.py would just figure this out explicitly.  As it turns out, there's already a feature request open on pex for this, but in the meantime, how can we auto-detect the entry point?

For the stupid example, it's pretty easy.  Once we've cloned its git repository, we just run the egg_info command and read the entry_points.txt file.  Later, we can build the project's binary wheel from the same git clone.

It's a bit more problematic with world though because the package isn't downloaded from PyPI until pex runs, but the pex command line requires that you specify the entry point before the download occurs.

We can handle this by supporting an entry_point variable in the snap's .ini file.  For example, here's the world.ini file with an explicit entry point setting:

[project]
name: world
entry_point: worldlib.__main__:main

[pex]
verbose: true

What if we still wanted to auto-detect the entry point?  We could of course, download the world package in snap.py and run the egg-info command over that.  But pex also wants to download world and we don't want to have to download it twice.  Maybe we could download it in snap.py and then build a local wheel file for pex to consume.

As it turns out there's an easier way.

Unfortunately, package egg-info metadata is not availble on PyPI, although arguably it should be.  Fortunately, Vinay Sajip runs an external service that does make the metadata available, such as the metadata for world.

snap.py makes the entry_point variable optional, and if it's missing, it will grab the package metadata from a link like that given above.  An error will be thrown if the file can't be found, in which case, for now, you'd just add the [project]entry_point variable to the .ini file.

A little more snap.py detail

The snap.py script is more or less a pure convenience wrapper around several independent tools.  pex of course for creating the single executable zip file, but also the snappy command for building the .snap file.  It also utilizes python3 setup.py egg_info where possible to extract metadata and construct the snappy facade needed for the snappy build command.  Less typing for you!  In the case of a snap built from a git repository, it also performs the git cloning, and the python3 setup.py bdist_wheel command to create the wheel file that pex will consume.

There's one other important thing snap.py does: it fixes the resulting pex file's shebang line.  Because we're running these snaps on an Ubuntu Core system, we know that Python 3 will be available in /usr/bin/python3.  We want the pex file's shebang line to be exactly this.  While pex supports a --python option to specify the interpreter, it doesn't take the value literally.  Instead, it takes the last path component and passes it to /usr/bin/env so you end up with a shebang line like:

#!/usr/bin/env python3

That might work, but we don't want the pex file to be subject to the uncertainties of the $PATH environment variable.

One of the things that snap.py does is repack the pex file.  Remember, it's just a zip file with some magic at the top (that magic is the shebang), so we just read the file that pex spits out, and rewrite it with the shebang we want.  Eventually, pex itself will handle this and we won't need to do that anymore.

Debugging

While I was working out the code and techniques for this blog post, I ran into an interesting problem.  The world script would crash with some odd tracebacks.  I don't have the details anymore and they'd be superfluous, but suffice to say that the tracebacks really didn't help in figuring out the problem.  It would work in a local virtual environment build of world using either the (pip installed) PyPI package or run from the upstream git repository, but once the snap was installed in my kvm instance, it would traceback.  I didn't know if this was a bug in world, in the snap I built, or in the Ubuntu Core environment.  How could I figure that out?

Of course, the go to tool for debugging any Python problem is pdb.  I'll just assume you already know this.  If not, stop everything and go learn how to use the debugger.

Okay, but how was I going to get a pdb breakpoint into my snap?  This is where Python 3.5 comes in!

PEP 441, which has already been accepted and implemented in what will be Python 3.5, aims to improve support for zip applications.  Apropos this blog post, the new zipapp module can be used to zip up a directory into single executable file, with an argument to specify the shebang line, and a few other options.  It's related to what pex does, but without all the PyPI interactions and dependency chasing.  Here's how we can use it to debug a pex file.

Let's ignore snappy for the moment and just create a pex of the world application:

$ pex -r world -o world.pex -e worldlib.__main__:main
Now let's say we want to set a pdb breakpoint in the main() function so that we can debug the program, even when it's a single executable file.  We start by unzipping the pex:
$ mkdir world
$ cd world
$ unzip ../world.pex
If you poke around, you'll notice a __main__.py file in the current directory.  This is pex's own main entry point.  There are also two hidden directories, .bootstrap and .deps.  The former is more pex scaffolding, but inside the latter you'll see the unpacked wheel directories for world and its single dependency.

Drilling down a little farther, you'll see that inside the world wheel is the full source code for world itself.  Set a break point by visiting .deps/world-3.1.1-py2.py3-none-any.whl/worldlib/__main__.py in your editor.  Find the main() function and put this right after the def line:

import pdb; pdb.set_trace()

Save your changes and exit your editor.

At this point, you'll want to have Python 3.5 installed or available.  Let's assume that by the time you read this, Python 3.5 has been released and is the default Python 3 on your system.  If not, you can always download a pre-release of the source code, or just build Python 3.5 from its Mercurial repository.  I'll wait while you do this...

...and we're back!  Okay, now armed with Python 3.5, and still inside the world subdirectory you created above, just do this:

$ python3.5 -m zipapp . -p /usr/bin/python3 -o ../world.dbg

Now, before you can run ../world.dbg and watch the break point do its thing, you need to delete pex's own local cache, otherwise pex will execute the world dependency out of its cache, which won't have the break point set. This is a wart that might be worth reporting and fixing in pex itself.  For now:

$ rm -rf ~/.pex
$ ../world.dbg

And now you should be dropped into pdb almost immediately.

If you wanted to build this debugging pex into a snap, just use the snappy build command directly.  You'll need to add the minimal metadata yourself (since currently snap.py doesn't preserve it).  See the Snappy developer documentation for more details.

Summary and Caveats


There's a lot of interesting technology here; pex for building single file executables of Python applications, and Snappy Ubuntu Core for atomic, transactional system updates and lightweight application deployment to the cloud and things.  These allow you to get started doing some basic deployments of Python applications.  No doubt there are lots of loose ends to clean up, and caveats to be aware of.  Here are some known ones:

  • All of the above only works with Python 3.  I think that's a feature, but you might disagree. ;)   This works on Ubuntu Core for free because Python 3 is an essential piece of the base image.  Working out how to deploy Python 2 as a Snappy framework would be an interesting exercise.
  • When we build a snap from a git repository for an application that isn't on PyPI, I don't currently have a way to also grab some dependencies from PyPI.  The stupid example shown here doesn't have any additional dependencies so it wasn't a problem.  Fixing this should be a fairly simple matter of engineering on the snap.py wrapper (pull requests welcome!)
  • We don't really have a great story for cross-compilation of extension modules. Solving this is probably a fairly complex initiative involving the distros, setuptools and other packaging tools, and upstream Python.  For now, your best bet might be to actually build the snap on the actual target hardware.
  • Importing extension modules requires a file system cache because of limitations in the dlopen() API.  There have been rumors of extensions to glibc which would provide a dlopen()-from-memory type of API which could solve this, or upstream Python's zip support may want to grow native support for caching.
Even with these caveats, it's pretty easy to turn a Python application into a Snappy Ubuntu Core application, publish it to the world, and profit!  So what are you waiting for?  Snap to it!

Read more