Manuel Kaufmann (Humitos): Entrevista Argentina en Python - PyDay Asunción

Durante el PyDayAsunción, Pablo Santa Cruz (programador en Roshka, uno de los Sponsors del PyDay Asunción) me hizo una entrevista para conversar un poco sobre la movida de Python en Argentina, el proyecto Argentina en Python y también cómo alentar a las empresas a qué migren a Python en sus dessarrollos.

Aquí la entrevista:

Podés encontrar el programa completo (donde salió publicada esta entrevista) en Mangocast, aquí.

¡Muchas gracias Pablo por la buena onda!

Manuel Kaufmann (Humitos): Manuel Kaufmann y Python en Argentina

Nota

Esta es una traducción realizada por Martín Chait del post "Manuel Kaufmann and Python in Argentina" by Mary Ann Sushinsky.

Lunes, 16 de Marzo de 2015-04-13 Manuel Kaufmann y Python en Argentina

Varios post recientes del blog se han centrado en actividades relacionadas con Python y financiadas por la PSF (Python Software Foundation) en África y el Medio Oriente. Pero la comunidad Python es verdaderamente global, y ha sido emocionante ser testigo de su crecimiento continuo. Nuevos grupos de personas se están introduciendo a Python y la programación con tanta frecuencia que es difícil mantenerse al día con las noticias. No sólo eso, sino que el alcance y el impacto duradero del trabajo hecho por Pythonistas con una asistencia financiera muy modesta de la PSF es asombrosa.

Un ejemplo es el trabajo reciente en Suramérica de Manuel Kaufmann. El proyecto de Manuel es promover el uso de Python para “resolver problemas cotidianos en usuarios comunes”. Su elección de Python como el mejor lenguaje para lograr este fin se debe a su compromiso con "la filosofía del Software Libre", en particular, la colaboración y no la competencia, así como la capacidad de Python “para desarrollar un software potente y complejo de una manera fácil".

Con este fin, hace un año, Manuel comenzó su propio proyecto, gastando su propio dinero y brindando su propio tiempo, viajando a diferentes ciudades de América del Sur en su auto (de nuevo, su propio auto), la organización de meet-ups, tutoriales, sprints, y otros eventos para difundir la palabra sobre Python y su potencial para resolver problemas cotidianos (ver Argentina en Python).

Esto sin duda llamó la atención de la PSF, por lo que en enero de 2015, el PSF le otorgó un subsidio de USD 3.000. Con este premio, Manuel ha sido capaz de continuar su trabajo, realizando eventos que han establecido nuevos grupos y que en la actualidad se están expandiendo más allá. Este efecto de una pequeña inversión, es algo que el PSF ha visto una y otra vez.

El 17 de Enero en Resistencia, Chaco, Argentina fue el escenario de su primer Sprint de Python. Fue un event de perfil bajo, que tuvo lugar en un pub/restaurante “con buen acceso a Internet”. Había aproximadamente 20 asistentes (entre ellos 4 mujeres jóvenes), que en su mayoría eran principiantes. Tras una introducción general, se dividieron en 2 grupos de trabajo, con Manuel conduciendo el grupo de los principiantes (véase Resistencia, Chaco Sprint), guiándolos a través de algunos materiales introductorios y tutoriales (por ejemplo, Aprendiendo Python desde el wiki de PyAr).

foto-grupal-sprint-chaco.thumbnail.jpg

Foto grupal con todos los asistentes

Como puede suceder, con el impulso adquirido, el Sprint fue seguida de una Meetup el 30 de Enero para consolidar las ganancias y empezar a construir una comunidad local. El grupo de 15 personas pasó el tiempo explorando las capacidades de Python, Brython , Javascript, Django, PHP, OpenStreet Maps, y más, en relación con los proyectos necesarios, y una nueva comunidad Python nació (ver Meetup en Resistencia, Chaco).

El próximo evento en Argentina, fue la primera reunión de Python en la provincia de Formosa, se llevó a cabo el 14 de Febrero que según Manuel, fue un gran éxito, al que asistieron alrededor de 50 personas. El día fue estructurado para tener más tiempo para la discusión libre, lo que permitió una mayor interacción e intercambio de ideas. En la opinión de Manuel, esta estructura realmente ayudó a forjar y fortalecer la comunidad. El enfoque explícito en aplicaciones del mundo real, con la discusión de una aplicación de software Python/Django desarrollado para, y actualmente en uso, en la Oficina de Información Turística de Formosa, fue especialmente convincente y de gran interés para los asistentes. Ver PyDay Formosa y para las fotos, ver PyDay fotos .

Parece como si estos éxitos son sólo el comienzo: Manuel tiene muchos más eventos programados :

  • 28 Marzo - PyDay en Asunción (Gran Asunción, Paraguay y PyDay Asunción); Manuel informa que la inscripción para este evento ya ha superado las 100 personas después de sólo 3 días de apertura. Además, los organizadores del evento están trabajando para establecer una comunidad permanente "Python Paraguay"
  • 7 de Mayo - PyDay en Apóstoles, Misiones
  • 20 a 22 Mayo - Track educativo para estudiantes secundarios en SciPy LA 2015, Posadas, Misiones, Argentina (SciPy LA y Track Teen SciPyLA 2015)
  • 30 de Mayo - PyDay en Encarnación, Itapúa, Paraguay

Pueden leer más y seguir el proyecto de Manuel en los enlaces proporcionados y en Twitter. Además, estén atentos a este blog, porque tengo la intención de cubrir más de su emocionante viaje a través de Python, de código abierto, y del empoderamiento de código a muchos más sudamericanos.

Me encantaría leer comentarios de los lectores. Por favor envíe sus comentarios, observaciones, o las ideas de blog a mí en msushi@gnosis.cx

Mariano Draghi (cHagHi): Tina Turner

Tina Turner nació en 1939. Hoy tiene 75 años. Cuando en 2009 grabó esto, tenía 70.

70 años, ¿entendés?

Te puede gustar o no su música, pero en un mundo donde tantas "divas" que con la mitad de la edad de Tina pretenden huir del tiempo a base de cirugías y maquillaje, y que su única capacidad especial es poder armar escándalos en el programa de chimentos de turno, no podés dejar de admirar a Tina Turner por su autenticidad, profesionalismo, talento y sus casi 50 años de carrera artística.

Facundo Batista: Cambiando un poco la estrategia


Me está costando ponerme a escribir algo en el blog. Más que nada porque no tengo mucho tiempo libre, y cuando lo tengo (y no lo aprovecho con la familia), me alejo un poco de la compu y veo series o pelis, o en la compu estoy sólo programando.

Tampoco tengo nada puntual que escribir, entonces me da fiaca hacer una recopilación de cosas, o detalles que sucedieron, etc.

Pero para ver si logramos vencer esta "inercia a arrancar", vamos a probar un nuevo esquema.  El otro día estaba escuchando una entrevista a Dolina, en el programa de Alivertii "Decime quien sos vos", y me enteré que a él le resulta más fácil, para escribir o producir textos, dictarlos. Entonces, la idea es dictarme yo mismo, grabando con el teléfono, y después voy a transcribir eso.

Obviamente lo voy a editar bastante, lo voy a toquetear, pero la idea es a ver si se logra que fluya más las cosas para contar y no terminar con dos o tres descripciones parcas y nada más.

Grabador de voz

En tren de contar algo de lo que fue sucediendo, el mes pasado hice el asado geek, que aunque es sólo un asado un domingo, realmente hay que ir a comprar un montón de cosas, y acomodar cosas en la casa, preparar todo, un largo etc. Después es un par de días de reorganizar todo de nuevo.

Se vino también el cumple de Malena, que implicó organizar la fiesta en el salón, la reunión en casa, etc. Y estamos armando una fiesta de cumpleaños con Moni, lo cual también lleva su tiempo de coordinación.

A nivel programación, estoy avanzando con varios proyectos, puntualmente CDPedia, fades, y Encuentro.

Con respecto a CDPedia, había preparado hace unos meses una imagen nueva para Huayra, que me pidió Karucha, pero revisando lo que se había armado nos dimos cuenta que había problemas en la búsqueda (vos ponías una palabra y jamás te traía un resultado).

Empecé a analizar el problema, y ví que no era algo que había salido mal en esa imagen, sino que teníamos un problema a nivel código, era algo a arreglar, así que me puse con eso y encontré que estábamos sacando mal títulos de las páginas (habían cambiado el formato interno).

Lo mejoré, y ahora no sólo saca bien los títulos sino que los saca en una etapa anterior, lo que es más eficiente. También metí un par de mejoras con respecto a la internacionalización.  En este momento estoy generando una imagen beta para ver si está todo bien, y ahí armar un set completo de imágenes, para distribuirlos. Luego, saldrá una beta en portugués, a ver cómo anda :)

El otro programa en el que estoy metiendo tiempo, como decía, es Encuentro. Cuando Humitos estuvo en casa (en esos días antes y después del asado geek) le metimos unas horas a este programa porque él está haciendo lo que es la integración con el backend de CDA, y ayudándolo y probando algunas cosas me di cuenta que la autenticación de Conectate cambió con lo cual no se podían bajar bien los videos.

Eso ya lo arreglé, pero todavía no lo liberé. Mi idea era esperar a Humitos para ver si metemos lo de CDA, pero creo que no lo va a tener para las próximas semanas, así que voy a hacer un release estos días, no sólo con ese fix sino también con otras mejoras y pequeñas correcciones que fui haciendo.

Finalmente, el otro fin de semana pasé un rato por FLISOL y luego me fui para la casa de Gilgamezh donde le estuvimos metiendo tiempo a fades, porque queremos hacer un release pronto con algunos features realmente copados ahí. Ya tenemos planeado con qué queremos llegar a la v3, nos falta poco :)

Facundo Batista: Búsqueda por prefijos tolerante a errores


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á.

Marcos Dione: processing-huge-DEM-datasets

As I mentioned in one of my lasts posts about it, I started using SRTM 1 arc data for rendering my maps. So far, with the 3 arc dataset, I was able to generate a huge image by stitching the tiles with gdal_merge.py, then generating the 3 final images (height, slope and hill shade) plus one intermediary for the slope, all with gdaldem. Now this is no longer possible, as the new dataset is almost 10x the old one, so instead of going that way, I decided to try another one.

With gdalbuildvrt it is possible to generate an XML file that 'virtually' stitches images. This means that any attempt to access data through this file will actually make the library (libgdal) to find the proper tile(s) and access them directly.

So now the problem becomes processing each tile individually and then virtual stitching them. The first part is easy, as I just need to do the same I was doing to the huge stitched image before. I also took the opportunity to use tiled files, which instead of storing the image one scan line at a time (being 1 arc second resolution, each scan line has 3601 pixels; the extra one is for overlapping with the neighbors), it stores the file in 256x256 sub-tiles, possibly (that is, no tested) making rendering faster by clustering related data closer. The second step, with gdalbuildvrt, should also be easy.

The first block on the way is the fact that SRTM tiles above 50°N are only 1801 pixels wide, most posibly because it makes no sense anyways. This meant that I had to preprocess the original tiles so libgdal didn't have to do the interpolation at render time (in fact, it already has to do it once while rendering, using the lanczos scaling algorithm). This was done with gdalwarp.

The second one came from slope and hill shading tiles. As the algortihm goes, it generates some 'fade out' values in the edges, and when libgdal was stitching them, I could see it as a line in the seam. This was fixed by passing -compute_edges to gdaldem.

Finally, for some reason gdalbuildvrt was generating some very strange .vrt files. The format of these files is more or less the following:

  • For each band in the source tiles it creates a band in the result.
    • For each source tile, it describes:
      • The source file
      • The source band
      • The size and tiling of the source (3601², 256²)
      • The rectangle we want from the source (0², 3601²)
      • The rectangle in the result (x, y, 3601²)

The problem I saw was some weird declararions of the rectangles in the result, where the coordinates or the sizes didn't match what I expected. I will try to figure this out with the GDAL poeple in the following weeks, but first I want to make sure that the source tiles are easily downloadable (so far I have only found download options through USGS' EarthExplorer, which requires you to be logged in in order to download tiles, which means that it is not very scriptable, so not very reproducible).

So for the moment I'm using my own .vrt file generator, completely not generic enough for release, but soon. I also took the opportunity to make the rectangles in the result non-overlapping, being just 3600² in size. I know that the generated file works because I'm also generating smaller samples of the resulting layers (again, height, slope and hill shading) for rendering smaller zoom levels.

The only remaining question about huge DEM datasets is contour generation. So far I had just generated contour lines for each tile and lived with the fact that they too look ugly at the seams.


gdal gis srtm

Mariano Guerra: Making a GIF out of a folder of PNGs (plus resizing)

I need to update the gif from the Event Fabric landing page and I forgot how I did it last time.

So this time I will write it here as a reminder.

First take the screenshots, I do it the good ol' way by using the browser fullscreen and hitting the screeshot key at almost regular intervals.

That leaves me with a set of screenshots I want to resize, so I run:

mogrify -path small -resize 800x450 *.png

Note

This requires imagemagick to be installed

This will resize all the *.png files in the current folder to 800x450 and write the results into a folder called small.

Now we go to the small folder and generate the gif:

cd small
convert -delay 100 -loop 0 *.png animation.gif

This will greate a gif that transitions every second from the png images and save it in the animation.gif file.

Mariano Draghi (cHagHi): Rearrancando...

Restart, human!

Restart, human! por Anders Sandberg

Nueva casa, nueva tecnología, nuevo formato. Todo es nuevo. Menos el contenido, que está abandonado hace casi un año. Y que ya venía semi abandonado antes de eso.

Ya ni los ¿clásicos? posts sobre los viajes estoy haciendo. Hay por lo menos dos que no están acá. Y es una pena. Esto nunca fue muy popular, ni tuvo muchos lectores, pero siempre fue un buen ejercicio esto de escribir, y más de una vez fue interesante en lo personal volver para atrás y releer algunas cosas. Y eso que he escrito cada pelotudez... :p Pero nada, las pelotudeces también son interesantes. Es interesante ver como uno cambia, o como el mundo cambia, y contrastar lo que pensaba, sentía o vivía mi "yo" de hace X tiempo con mi "yo" actual.

Y cada tanto, cada muy tanto, hasta llegué a escribir algo que le sirvió a alguien. Y eso también está bueno.

¿Y por qué dejé de hacerlo? No se muy bien, pero en general siento que la culpa es de Facebook y Twitter. Es mucho más fácil escribir una gilada de 140 caracteres en Twitter o un par de párrafos en Facebook que ponerlo en un blog.


Para motivarme un poco, porque uno ante todo es nerd (?), decidí demoler el blog anterior y armarlo otra vez. Estoy usando Nikola, mascota de Roberto Alsina, que resulta que además de recomendar muy buenos libros, desarrolla muy buenos generadores de sitios estáticos ;-) (¡gracias Roberto!)

La principal ventaja para mi de haber migrado a Nikola es que ahora el contenido del blog está en archivos de texto, en un formato que es legible por un humano incluso sin la magia que lo transforma en páginas web.

La segunda ventaja es que está desarrollado en Python, que es un lenguaje de programación que me gusta hasta el infinito y más allá más que PHP (que es lo que usa WordPress), y que me resulta mucho más fácil de entender cuando necesito tocar algo, o agregar funcionalidad, o hacer modificaciones.

La tercer ventaja es que Nikola es minimalista. No tiene las decenas de características que tiene WordPress, ni sus miles y miles de plugins. Tiene lo que necesito. Es más simple. Y cuando uno no necesita la complejidad extra, "simple es mejor que complejo" [*].

Migrar de WordPress a Nikola es algo que es más o menos automático en un 75%, pero si sos obse como yo y realmente querés emprolijar las cosas, requiere luego una serie de ajustes que dependen de cuan horrible sea el formato heredado de WordPress. Para algunos de esos ajustes fui haciendo reemplazos semi-automáticos con distintas herramientas, para otros tuve que ir a mano (y para esos casos, que no fueron taaaaantos, agradecí no haber estado escribiendo con más frecuencia :p). En todo este proceso me vino de 10 la experiencia previa de Humitos.

Todavía tengo cosas que ajustar, como los tags y categorías, o hacer que el sitio tenga un look un poco menos genérico. Y otro gran tema es encontrar un mecanismo cómodo para poder publicar desde el celu/tablet, o una compu desde la que no tenga acceso al servidor. Esto es medio una desventaja común a todos los generadores de sitios estáticos. Hay varias opciones, pero todas requieren algún trabajillo extra, todas tienen algún pero, y va a requerir un poco más de tiempo evaluar que es lo que más me conviene.

Pero la base está...


Para terminar el revoleo, el blog no está más alojado en un hosting compartido. Me llevé todo a un VPS. Y eso también es toda una novedad, y en parte un desafío, porque tengo que administrar absolutamente todo yo. Es un arma de doble filo: puedo hacer lo que quiera en el servidor, y por lo tanto también puedo romper todo. Y tengo que tener un ojo puesto en todo lo que sea configuración, actualizaciones, seguridad, etc.

Al pasar a un VPS hay una cosa que estaba seguro que no quería administrar: las cuentas de correo de mi dominio. Administrar un servidor de correo propio es, para mi, "ligas mayores" (para hacerlo razonablemente bien), así que tuve que encontrar una solución, preferentemente gratuita. En una época la respuesta obvia a esto era Google Apps, pero no es más gratis. Por recomendación de Roberto (que además de recomendar buenos libros, y de desarrollar buenos generadores de sitios estáticos, hace buenas recomendaciones de servicios en la nube), el correo de mi dominio quedó en Zoho, que ofrece un plan gratuito que me alcanza y sobra.

Y acá estamos. Todo nuevito. Ahora solo falta escribir...


[*] El Zen de Python

Roberto Alsina: Some New Stuff in Nikola

I did so­me qui­ck wo­rk on Niko­la (a sta­tic web­si­te/­blog ge­ne­ra­to­r) la­te­l­y, after a long ti­me, and he­re's what it wa­s:

Multilingual Sitemaps

So, site­maps are us­ed by Google to in­dex your si­te. It turns out that they can des­cri­be when the­re are se­ts of pa­ges ­that are trans­la­tions of ea­ch othe­r. So the next re­lea­se wi­ll do that (Is­sue #1610)

Matplotlib Plots

Ma­tplo­tlib co­mes wi­th a sphi­nx ex­ten­sion to do plo­ts So I went and im­ple­men­ted it, this was Is­sue #1242 and it's a plu­gin ca­lled py­plo­ts, whi­ch wi­ll be soon at http://­plu­gin­s.­ge­tniko­la.­co­m#­p­y­plo­ts

I hated the ori­gi­nal co­de. It felt con­vo­lute­d, and just weird (i­t's pro­ba­bly just me) so I wro­te it from scra­tch and it has so­me mi­nor di­ffe­ren­ce­s, but it's fair­ly com­pa­ti­ble.

Classy Images

The do­cu­tils ima­ge di­rec­ti­ve, for whate­ver rea­so­n, does­n't su­pport a cla­ss op­tio­n, so you need to do things like this:

.. class:: foo

.. image:: blah.png

Whi­ch is ... not pre­tty. So I did a ha­cky plu­gin that mo­nke­y­pa­tches the ima­ge di­rec­ti­ve to add that op­tio­n. ­The plu­gin is at http://­plu­gin­s.­ge­tniko­la.­co­m/#­cla­ss­y-i­ma­ges and this fixes Is­sue 1538

Mediawiki Markup

dj­b­cla­rk po­inted out that the­re is a li­bra­ry to par­se Me­diaWiki from py­thon ca­lle­d sm­c.­mw so I im­ple­men­ted a plu­gin to use it, so now you can use Me­diaWiki ­ma­rku­p. The plu­gin is at http://­plu­gin­s.­ge­tniko­la.­co­m/#­me­diawiki

Removed Default Swatch from Bootswatch

This was Is­sue #1656 and now you ha­ve to spe­ci­fy ­the swa­tch. This is a usa­bi­li­ty fix, be­cau­se de­faul­ts ma­tter.

Played with KaTeX

Niko­la su­ppor­ts ma­th using Ma­th­Ja­x. Ma­th­Jax has so­me in­te­res­ting qua­li­tie­s:

  • It's 160MB of co­de or so
  • It's not prac­ti­cal to use wi­thout a CDN
  • It's not prac­ti­cal to use we­ba­sset bund­les wi­th it

Then, klin­gtnet men­tio­ned so­me­thing ca­lled Ka­TeX I had ne­ver heard abou­t. I did a qui­ck ha­cky con­ver­sion to see how it wo­rks. ­Not do­ne ye­t, to­ta­lly ex­pe­ri­men­ta­l, but it may be po­s­si­ble to bund­le it, and ma­y­be even ha­ve it tur­ned on by de­faul­t, re­mo­ving the need for the ma­th­jax la­bel whi­ch is aw­ful usa­bi­li­ty-wi­se.

So­me of the­se things are mer­ge­d, so­me are sti­ll PR­s, so­me are in co­re, so­me are plu­gin­s. They we­re all pre­tty fun ­to do :-)