Canonical Voices

Posts tagged with 'python'

facundo


Hace un par de semanas finalmente salió el trámite de la Inspección General de Justicia sin nada para revisar o modificar... ¡está formada legalmente la Asociación Civil Python Argentina!

Estatuto todo sellado

Ahora estamos trabajando a full para sacar el CUIT en la AFIP, lo que nos va a permitir abrir una cuenta en el banco. De esta manera los chicos que están organizando la PyCon ya van a poder darle luz verde a los sponsors para que pongan plata.

Más allá de ayudar organizativamente en la PyCon y en otros eventos, son cuatro las cosas que queremos empujar el primer par de años:

  • Becas de viaje: porque creemos que hay mucho valor en que la gente se conozca, así que trataremos de ayudar a que la gente pueda viajar a eventos que se organicen en el país
  • Traducciones en eventos: si van a venir disertantes grosos que no hablen castellano, hacer lo posible para que la mayoría pueda entenderlos
  • Descuentos en cursos: estamos barajando un par de modalidades
  • Sitio web de PyAr y otra infraestructura: tenemos que dar un salto en seriedad a la hora de mantener los distintos servicios que da el grupo

Para eso (y para los costos operativos) básicamente vamos a necesitar dinero :) La Asociación se va a financiar de dos maneras, principalmente...

Una es por aporte de los socios. La idea es que los socios, que se beneficiarían directa e indirectamente por la Asociación Civil, pongan un manguito por mes para ayudar a hacer cosas.

El otro mecanismo es por aporte directo de empresas (de las cuales esperamos un manguito más grande, posiblemente anual).

Ya les contaremos bien cuales serán los mecanismos, montos, y eso. ¡Estén atentos!

Read more
facundo


Al final salió una idea que venía dándome vuelta en la cabeza desde principios del año pasado, y que tardó sus meses en concretarse: voy a estar dando un Seminario de Introducción a Python junto a una empresa, con el objetivo de bajar el costo del curso a los asistentes (lo cubre en parte la empresa), y de esta manera poder hacer algo más largo y más masivo.

La empresa con la cual voy a hacer este Seminario es Onapsis, bastante cercana a la comunidad de Python Argentina, ya que hace mucho que es sponsor de eventos, pone los famosos "pybus" para ir a las PyCones, hosteó un meetup, etc, etc.

El Seminario es abierto al público en general, y será de 16 horas en total, cuatro sábados de Julio, durante la mañana, en CABA.

El costo es súper accesible, $600, ya que parte lo cubre Onapsis, y la idea es hacerlo barato para que pueda venir la mayor cantidad de gente posible.  Así y todo los cupos son limitados (la oficina tiene un límite), por lo que cuanto antes consigan reserva la posición, mejor.

Al final del Seminario entregaré un certificado de asistencia y la totalidad del curso en formato electrónico.

Para realizar la reserva deben enviarme un mail así les confirmo disponibilidad y les paso los datos necesarios para realizar el pago (que podrá ser por depósito, transferencia bancaria, tarjeta de crédito, débito, etc.).

Acá están todos los detalles del curso.

Read more
facundo

Salió fades 6


Salió la última versión de fades, el sistema que maneja automáticamente los virtualenvs en los casos que uno normalmente encuentra al escribir scripts y programas pequeños, e incluso ayuda a administrar proyectos grandes.

Esta es una de las versiones que más cambios metimos! Estos son solo algunos de los puntos de la lista de cambios:

- Instala no solamente desde PyPI sino también de repositorios remotos (GitHub, Bitbucket, Launchpad, etc) y directorios locales

    fades -d git+https://github.com/yandex/gixy.git@v0.1.3

    fades -d file://$PATH_TO_PROJECT

- Creamos un video para mostrar las características de fades más relevantes

- Selecciona el mejor virtualenv de los almacenados en casos de coincidencia múltiple

- Agregamos una opción --clean-unused-venvs para borrar todos los virtualenvs que no fueron usados en los últimos días

    fades --clean-unused-venvs=30

- Agregamos un --pip-options para pasarle los parámetros que sean necesarios a la ejecución subyacente de pip

    fades -d requests --pip-options="--no-cache-dir"

La lista completa de cambios está en el release formal, esta es la documentación entera, y acá tienen como instalarlo y disfrutarlo.

Read more
facundo

PyCamp 2017, en Baradero


¡Otra vez un PyCamp relativamente cerca de casa! Eso me permitió ir en auto. Bah, fuimos en auto, Diego, Nico, Edu y yo. Salimos tempranito y a eso de las nueve ya estábamos ahí.

Las primeras dos horas las pasamos armando toda la infraestructura: fue colgar la bandera, poner las Antenas Sable Láser, configurar la red con el router nuevo, preparar los badges y otros pequeños souvenirs, hacer mate, etc, etc.

A las once y media arrancamos la gran charla introductoria, que era muy necesaria porque este Pycamp era el primero para un montón de los asistentes. Y a continuación de la misma presentamos todos los proyectos que llevamos y votamos más o menos en cuales nos gustaría participar.

Luego el primer almuerzo, y ya arrancamos el PyCamp a todo motor.

Algunos trabajando, otros en un curso superbásico inicial

Trabajando a la sombrita

Yo participé en varios proyectos, pero el fuerte del tiempo lo puse en estos tres:

  • Linkode: aprovechando que estábamos cara a cara, estuvimos pensando con Mati Barriento mucho en un cambio muy grande que estamos haciendo, lo que nos llevó a un refactor de la base de datos, con migración de información que la hicimos el último día en producción. Mucho laburo puesto en esto, que nos dejó un modelo más simple y el código listo para la próxima gran mejora, que es la renovación de como manejamos el lado del cliente.
  • Fades: Gilgamezh y yo laburamos bastante también acá. Él estuvo principalmente con el video instructivo que armamos el año pasado y necesitaba mucha edición, y con mucha ayuda de Marian lograron un resultado bárbaro, que pueden ver acá. En el proyecto en sí yo metí dos fixes pequeñitos, y estuve ayudando y haciendo reviews a dos branches de Juan y Facundo (otro, no yo).
  • Recordium: acá no hicimos mucho, pero conté de qué iba el proyecto y ahí surgieron varias pequeñas mejoras para hacer, incluso para la GUI final a la que apuntar. Y también tocamos un tema de seguridad, donde Matías nos contó qué detalle habría que mejorar para que no nos puedan "inyectar" mensajes.

Laburanding

Charlando diseño y aprendiendo malabares

Pero aparte de los proyectos en sí, también tuvimos un campeonato de ping pong (pasé la primera ronda, pero luego perdí un partido de la segunda ronda y quedé afuera), pileta (me metí y todo), hicimos la foto grupal de siempre, un partidito de futbol (sobre pasto, ¡en patas!), un asado, la típica reunión de PyAr integrada al Pycamp, y mucha, mucha charla con diferentes grupos, viendo qué hacían, tratando de tirar alguna idea o aplicar alguna experiencia.

La grupal

Como actividades fuera del predio, tuvimos un paseo guiado una mañana (con guia y todo, que nos contó muchísimo del pasado y presente de Baradero y alrededores), y un festival de jazz una noche (muy lindo, y la gente de donde nos hospedábamos se copó y nos armó una vianda así los que íbamos al festival cenábamos allá).

El último día también hicimos (como queremos que se haga costumbre) un video donde todos los que empujamos algún proyecto pasamos y contamos qué se hizo. Está muy bueno a nivel resumen para los que estuvimos ahí y como registro para los que no pudieron ir (y que quede a futuro). Mil gracias a José Luis que siempre se copa con la edición del video final.

Caminando por Baradero

Festival de Jazz

Un punto aparte para lo que fue el "lugar" del PyCamp. Mucho verde a metros nomás de donde estábamos trabajando, que era un salón grandote donde entrábamos relativamente cómodos (aunque en el día a día siempre había grupos laburando en lo que era el comedor y/o al aire libre). Las habitaciones estaban bien (considerando que eran grupales) y los baños limpios. La comida bárbara, incluyendo el asado, y un lujo todas las preparaciones especiales para gente vegetariana, con dietas raras, alergias, etc (les estuve preguntando a varios y todos comentaron que estuvo perfecto). Hasta la internet, anduvo...

En fin, pasó otro PyCamp. Yo siempre digo que es el mejor evento del año, y este no fue la excepción. Es más, esta edición, la 10°, fue uno de los mejores PyCamps!

Clases de espadas

El parque y la pileta

PD: charlando sobre que era la décima edición, nos anotamos cuales habían sido hasta ahora, lo dejo acá como registro...

    2008  Los Cocos, Córdoba
    2009  Los Cocos, Córdoba
    2010  Verónica, Buenos Aires
    2011  La Falda, Córdoba
    2012  Verónica, Buenos Aires
    2013  Villa Giardino, Córdoba
    2014  Villa Giardino, Córdoba
    2015  La Serranita, Córdoba
    2016  La Serranita, Córdoba
    2017  Baradero, Buenos Aires

PD2: fotos! las mías y las que sacó Yami (casi fotógrafa oficial del evento).

Read more
facundo

Regalo de fin de año: Recordium


En estas últimas semanas terminé de poner a punto un proyectito que había empezado durante el año. Aunque le faltan algunos detalles, ya es funcional y útil.

Se llama Recordium. Es una aplicación sencillita que ayuda al vos-fuera-de-tu-compu a recordarle cosas a tu futuro vos-en-la-compu.

Recordium

La idea es que ejecutás Recordium en tu computadora, y se pone ahí como un iconito pequeñito.

Después, en cualquier momento, estando en la calle, cortando el pasto, en la cola de la panadería, etc, cuando te acordás de algo que tenés que hacer, le mandás un texto o audio de Telegram a tu Bot de Recordium.

Cuando volvés a tu computadora (donde tomás las acciones correspondientes sobre eso que te habías acordado), el iconito de Recordium va a estar iluminado, te va a decir que tenés un mensaje nuevo (o más), y ahí podés leer/escuchar lo que te habías acordado en otro momento.

¿Se podría hacer algo similar utilizando herramientas más complejas? Sí. ¿O algún servicio de Google? También, pero no quiero meterle más yo a Google. Igual, lo más importante de Recordium es que me sirvió de proyecto juguete para (al mismo tiempo que lograba una funcionalidad que yo quería) tener algo hecho en Python 3 y PyQt 5.

Read more
facundo

Incubadora de eventos


Una de los roles claves de la Asociación Civil de Python Argentina (en adelante "AC") debería ser que la gente se junte y comparta conocimiento. En consonancia con esto, estuve armando la siguiente idea para ayudar a que se generen eventos y reuniones.

Hay distintas formas en la cual la AC puede ayudar a los organizadores de un evento, entre ellas:

  • Ayuda logística: transmitir experiencia, ayudar a resolver inconvenientes que se produzcan en la operatoria del día a día
  • Ayuda financiera: como es normal que algunos sponsors se comprometan a aportar dinero, pero luego ese aporte se demora (por el sponsor en sí, o trámites de todo tipo, especialmente internacionales), la AC puede adelantarle dinero al organizador, el cual ingresará a la AC luego cuando el sponsor efectivice.
  • Ayuda económica: Partiendo de la idea base de que el evento salga hecho, o incluso genere dinero para la AC, hay dos puntos en que se puede ayudar económicamente: siendo sponsors de un evento muy chico (ej: pagando unas pizzas para un sprint), pero me parece más importante poder ser una red de contención, en el caso de que por fallos en la planificación conjunta se pierde algo de dinero: que la pérdida la cubra la AC y no la persona que organizó.
  • Ayuda institucional: Por un lado es útil tener una entidad legal para poder presentarse a más sponsors, o al estado, dando más seriedad al evento, y además es imprescindible que los sponsorships o donaciones para el evento se hagan a una entidad ya formada, y no a individuos; esto le saca un quilombo personal al organizador, y permite pagos internacionales.

Para poder ejecutar estas ayudas, los organizadores del evento y la AC tienen que colaborar, seguir ciertos pasos y reglas. ¿Quizás incluso firmar algún contrato?

Describo la metodología a grandes rasgos en los siguientes puntos. Pero esto hay que pensarlo, refinarlo, y escribirlo bien en detalle, para lograr dos cosas:

  • que el organizador u organizadores entienda bien como la AC va a jugar en esto
  • que la AC corra la menor cantidad de riesgos innecesarios posibles

Entonces, la idea es tener un presupuesto base, un template de lo que sería el presupuesto final del evento, con todo lo que podamos pensar y se nos pueda ocurrir de eventos anteriores. Se recorre el mismo con el organizador, en una primera instancia, y se elije lo que el organizador "quiere hacer"; luego el organizador mismo tiene que poner un estimado de costo a cada ítem, y separar los ítems en tres secciones (o quizás sólo dos para eventos chicos):

  • de mínima: sin esto el evento no sale
  • intermedio: con esto el evento está lindo
  • de máxima: si se logra esto es un golazo

En función de todo lo elegido, hay que planificar los sponsorships necesarios, en base a niveles: definirlos, incluyendo el costo y las retribuciones. Es imprescindible que la AC de "el visto bueno" sobre esta planificación, y que luego realice un "seguimiento en el tiempo" de la evolución de la ejecución del presupuesto. Acá la AC también puede jugar un rol centralizador, básicamente armando un folleto de "hay un nuevo evento, ¿querés ser sponsor?" y mandándolo a todos las empresas, instituciones, o lo que sea que tengamos en carpeta.

También en esta interacción AC/organizador se pueden pedir más cosas, o hacerlas obligatorias, ejemplo (¡hay que pensar más!):

  • que el evento tenga un código de conducta; incluso la AC puede proveerlo, junto con un pequeño texto de "qué hacer si se recibe una denuncia"
  • que el sitio web del evento sea "exportable a estático", así la AC lo guarda y sirve a futuro; también la AC podría dar un sitio web base, y hostearlo.

Por último, un detalle: estaría bueno que la AC también cumpla el rol de "paraguas legal" (básicamente, lo que arriba describo como "ayuda institucional") para ayudar a otros grupos relacionados con el software y/o cultura libre, para que puedan ellos hacer sus eventos.

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