Mariano Guerra: Papers of the Week VII

   Publicado:

Because nothing lasts forever and after a week half traveling and a busy one I managed to read 4 papers this week.

The first one was interesting but comes from an area I will describe as "let's bend relational databases to fit Event Stream Processing", which is not bad per se but has things like joins and being able to remember past events that make its scalability (at least in terms of memory) quite hard, also it never discuses distribution, which is ok for the field but not what I'm looking for.

The interesting part about this one is the part where it introduces Visibly Pushdown Languages something that looks really interesting but I couldn't find an introduction for mere mortals, the descriptions are really dense an mathematical, which is ok but hard to learn for outsiders like me.

Another interesting point is the fact that it uses the XML Schema to optimize the generated VPA (Visibly Pushdown Automata) and that the implementation not only applies to XML but to any nested semistructured data.

The review of the next one will seem conflicting with my previous reviews, but this one had too much enfasis on the low level implementation details, not novel things and optimizations, just a lot of details, like the guys found the implementation really cool and wanted to share it with the world. Not a bad thing per se, but in this batch I was looking for abstractions, optimizations and distribution characteristics of stream processing, better if focused on distributed systems, and this one talked mainly about the DSL they build that compiles to C. It also sorts the streams, does multiple passes over the data, does lookahead in the stream and does a kind of "micro batches" which isn't what I was looking for.

The last one, I found the approach interesting, they seemed to try to push the purity of the approach (everything is a regular expression) which may have end up with a nice model (a thing I like) but by reading the code it doesn't seem to be really clear, at least for a OO/functional background, and I think less for non programmers. Maybe the syntax doesn't help and some other syntax would make things clearer, I don't know.

Other than that the approach is interesting and it made me think on some ways to define a stream processing language using mainly pattern matching.

Papers this week: 4

Papers so far: 33

Papers in queue: 76

Juanjo Conti: Paredón

   Publicado:

Durante la escuela primaria, jugaba mucho al fútbol. Jugaba en los recreos de la escuela, en el club y en una canchita cerca de casa. A esa canchita iba en bici, una bici roja con calcomanías plateadas. La dejaba tirada y corría hasta donde el resto estaba pateando. Éramos siempre seis o siete. La mayoría, de la misma escuela; algunos un año más chicos, otros un año más grandes, y, de vez en cuando, algún que otro desconocido. Por lo general, pensábamos que los desconocidos no iban a la escuela, a ninguna, y eso les daba un aura de renegados, un halo de misterio que provocaba admiración y respeto. Si la pateaban lejos, no les hacíamos buscar la pelota.

La canchita quedaba al lado de la casa del Sapo; era de tierra y tenía arcos que su abuelo había hecho con ramas secas atadas con alambre. Nunca conoció la gramilla. Jugábamos tanto que no le dábamos tiempo al pasto a crecer. Era un manto marrón violáceo con textura de talco.

El Sapo era nuestro mejor delantero. Era zurdo y tenía una pegada que hacía temblar el alambrado que estaba atrás de los arcos. Muchas veces, si pegaba en el palo, hacía que el travesaño se cayera. Teníamos que suspender el partido y arreglar el arco. El resto éramos de regular para abajo. Ninguno iba a llegar a primera nunca. Sin embargo, el Sapo… sí podría haber llegado.

Una característica que tenía nuestro grupo era que carecía de arquero. A nadie le gustaba tener que encargarse de defender el arco. Seguramente por eso, uno de los juegos más comunes entre nosotros era el “veinticinco”. Alguien al azar empezaba en el arco. Cada vez que atajaba un tiro, podía usar la pelota para intentar golpear a uno de los otros jugadores. Si lo conseguía sin que la pelota pique, el jugador golpeado se convertía en el nuevo arquero. La secuencia seguía hasta llegar a los veinticinco puntos en el marcador global, que se acumulaban a través de los goles que íbamos haciendo. Diferentes tipos de goles valían diferente cantidad de puntos. Por ejemplo, un gol normal con el pie valía uno, pero un gol de cabeza, cinco. Cuando se llegaba a los veinticinco puntos, quien estaba en el arco tenía que cumplir una prenda. La clásica era el capotón: la víctima se agachaba, tratando de cubrirse, mientras todos los demás le pegábamos en la espalda.

Una de esas tantas tardes, el Sapo estaba en el arco y el puntaje acumulado era de veinticuatro. En total, éramos seis chicos jugando. Los que no estábamos en el arco, nos acercábamos tocando la pelota y cuando estábamos lo suficientemente cerca, pateábamos con la esperanza de hacer un gol. Inmediatamente después, retrocedíamos a toda velocidad para intentar evitar la embestida del arquero, que nos arrojaba con potencia la pelota.

En un determinado momento, Fitipaldi, uno que era nuevo en la escuela, pasó a tener la pelota. No se animó a patear y me dio un pase muy cerca del área. El Sapo se me vino arriba y pateé como pude. El Sapo atrapó la pelota en el aire y antes de que pudiera reaccionar, me la lanzó con suavidad sobre el cuerpo. Estaba tan cerca que no pude esquivarla y en el intento, me caí. Ante las carcajadas de todos, tomé mi lugar en el arco con la pelota en la mano. La suma seguía en veinticuatro.

Todos estaban a más de quince metros de distancia. Imposible alcanzarlos. De todas formas, lo intenté. Con fuerza, lancé la pelota con la mano derecha, apuntando vagamente al montón. Se abrieron. Algunos para la derecha, otros para la izquierda, y la pelota pasó picando entre ellos.

En menos de un minuto, luego de otro pase de Fitipaldi, el Sapo pateó al arco de media distancia y me hizo el gol que sumó veinticinco.

---¡Veinticinco, capotón! ---gritó uno mientras yo iba tomando la posición adecuada para recibir el castigo.

---No, mejor no. Tengo otra prenda ---dijo el Sapo y a continuación, explicó el “paredón”---. El que tiene que cumplir la prenda se para de espalda a nosotros, mirando la pared. Ponemos la pelota a seis pasos largos y uno patea “a fundir” para pegarle en la espalda.

---¡Sí! ---vitorearon todos con entusiasmo.

Yo no dije nada; estaba pensando en mis posibilidades. A diferencia del capotón en el que tenía la golpiza asegurada, en esta nueva modalidad tenía la posibilidad de salir ileso. Por supuesto, si me embocaban, el golpe sería más duro.

---¿Y quién patea? ---preguntó uno.

---El que metió el último gol ---respondió el Sapo.

Me ubiqué sin chistar y me persigné varias veces repitiendo en silencio una jaculatoria. “Que le erre”, pensaba para mis adentros.

El sonido pareció uno, pero en realidad fue un repique rápido de tambor: el botín del Sapo en contacto con la pelota de cuero y una fracción de segundo después, el cuero de la pelota contra mi espalda.

---¡Uhhhhhhh! --- gritó el coro de espectadores que, en una onomatopeya, expresó lo que yo no pude. Casi tampoco podía respirar. Encorvado y con un brazo levantado pedía clemencia.

Como no quería que me vean llorar, agarré la bicicleta y pedaleando rápido me volví a mi casa. Estaba transpirado y sucio de tierra. Apenas llegué, sin saludar a nadie, me metí en el baño. Me saqué la remera y mirando para atrás, me vi la espalda en el espejo. Tenía un círculo rojo perfectamente delimitado. Mi espalda parecía la bandera de Japón. Ya no me dolía el golpe, pero ahora sentía un ardor en la piel. Me bañé y no hablé con nadie sobre el asunto.

Al otro día, con el dolor y la vergüenza casi olvidados, volví a la canchita. Además de los de siempre, había un chico nuevo.

---El Crema ---me dijeron que se llamaba.

Que hubiera uno nuevo era bueno. Todos nos complotábamos para hacerlo perder. Si no estaba en el arco, hacíamos que se acerque a él mediante falsas promesas de gol y lo traicionábamos a último momento. Cuando ya estaba en el arco, pateábamos de lejos sin importar que tardásemos en sumar. Así pasó esa tarde con el Crema. Cuando entró en el arco, no salió más.

Veintidós.

Veintitrés.

Veinticuatro.

Yo quería hacer el último gol. Y quería que le hagamos “paredón”. Quería vengarme. No me importaba que el Crema no haya estado el día anterior. Solo quería darle un puntinazo con fuerza a la pelota e incrustársela en la espalda.

Veinticinco.


Este cuento fue publicado para el concurso #historiasdefutbol de Zenda.

Marcos Dione: trace2csv

   Publicado:

Remember this? Ok, maybe you never read that. The gist of the post is that I used strace -r -T to produce some logs that we «amassed[sic] [...] with a python script for generating[sic] a CSV file [...] and we got a very interesting graph». Mein Gott, sometimes the English I write is terrible... Here's that graph again:

This post is to announce that that Python script is now public. You can find it here. It's not as fancy as those flame graphs you see everywhere else, but it's a good first impression, specially if you have to wait until the SysAdmin installs perf or any other tool like that (ok, let's be fair, l/strace is not a standard tool, but probably your grumpy SysAdmin will be more willing to install those than something more intrusive; I know it happened to me, at least). It's written in Python3; I'll probably backport it to Python2 soon, so those stuck with it can still profit from it.

To produce a similar graph, use the --histogram option, then follow the suggestions spewed to stderr. I hope this helps you solve a problem like it did to me!


profiling python

Facundo Batista: Universidad y finales

   Publicado:


El otro día estaba charlando con un amigo sobre algo relacionado a la Universidad, a una materia que cursé en la misma, y no me acordaba cuando la había rendido. En el momento no le dí importancia, pensé "cuando vuelvo a casa me fijo en la libreta universitaria".

Claro, nunca me fijé, porque la libreta está ahí escondida en un cajón de dificil acceso, el típico lugar donde alguien más o menos ordenado tiene los títulos viejos, certificados, papeles importantes diversos, y eso (los que no son medianamente ordenados en general no tienen puta idea donde están estas cosas).

Primera página de la libreta

Entones, se me ocurrió que, habiendo sido la Universidad una etapa tan importante en mi vida, podría tener la info de cuando rendí las materias mucho más a mano.

Busqué la libreta, pasé todas las materias (con fecha de final y la nota), y ahora guardo todo eso acá. Lástima que no tengo los nombres de las/los profesoras/es (me acuerdo algunos, pero la mayoría no...).

Marcos Dione: moving-digikam-collections

   Publicado:

A short story. For years I've not only accumulated thousands of pictures[1] (around 50, to be more precise) but also schemas on how to sort those photos. After a long internal debate, I settled for the following one (for the moment, that is):

  • Pictures are imported from the camera's SD via a script, which:
    • Renames them from DSCXXXXX.JPG to a date based file name, using the picture's exif data.
    • (Hard) links them to a year/month based dir structure.
  • Later, pictures are sorted by hand into thematic dirs for filtering.
  • The year/month tree is handled with digikam for tagging.
  • Pictures are filtered into their final destination sorted by category, year and event (for instance, trip/year/to_this_place).
  • Pictures are also (hard) linked into a tag based dir structure, using nested tags.

So, the whole workflow is:

SD card --> incoming/01-tmp -> incoming/02-new/theme -> incoming/03-cur --> final destination
        `-> year/month                                                  `-> tags/theme/parent/child

The reason for using hard links is the following: I rsync everything to my home server, both as backup and for feeding the gallery(s) there. Because pictures are moved from one location to another until they reach their final destination, rsync retransmits the picture in its new location and then deletes the old one (I'm using --delete-after, to make sure the backup does not loose any picture if the transfer is stopped). This leads to useless transfers, as the picture is in the remote.

I played with the idea of using git or even git-annex for working around this, but in the end I decided to (ab)use rsync's hard link support. Now moving any picture in the workflow or renaming a category, theme or directory just means creating new hardlinks to the links in the year/month tree and removing the old ones later, an almost immediate operation. This also helps saving space and time when implementing the tag based tree.

digikam is good enough to uniquely identify each picture, even when two hard links point to the same file. This still means the picture appears several times; the metadata (most importantly, tags) are shared, but each new link adds load to the digikam's database.

I bit the bullet and sat down to do a last move and be done. I moved the year/month tree to ByDate/, completely isolating it from the rest of the collection. Then pointed digikam to only read that, and here's how I did it:

  • Closed digikam, of course.
  • Backed up everything, including both the database, which was in the collection's root, and the .local/share/config/digikamrc file.
  • Modified the latter so it points to the new database location:
[Database Settings]
Database Name=/home/mdione/Pictures/ByDate/
Database Name Thumbnails=/home/mdione/Pictures/ByDate/
  • Moved the database.
  • Changed the collection's root dir in the database:
mdione@diablo:~/Pictures/ByDate$ sqlite3 digikam4.db
-- Notice the specificPath is relative to the volume. In my case, the volume is /home
sqlite> select * from AlbumRoots;
1|Pictures|0|1|volumeid:?uuid=f5cadc44-6324-466c-8a99-4ede7457677e|/mdione/Pictures
sqlite> update AlbumRoots set specificPath = '/mdione/Pictures/ByDate' where id = 1;
sqlite> select * from AlbumRoots;
1|Pictures|0|1|volumeid:?uuid=f5cadc44-6324-466c-8a99-4ede7457677e|/mdione/Pictures/ByDate
  • Fired digikam and let it rescan the collection, which recognized the only link to the image and kept the tags.

This worked superbly!


[1] When I talk about pictures, I'm also including videos.

Juanjo Conti: No nos dejan usar arrays

   Publicado:

Ayer me pasó algo cuanto poco curioso. Había ido a la facultad a buscar a mi esposa que estaba terminando de dar una clase de Análisis Matemático 2 y llegué antes de que terminé, así que luego de asomarme por el vidrio de la puerta, me senté en un banco del pasillo a leer un libro (nota del editor: Hacé que la noche venga, de Leonardo Oyola).

No había leído dos párrafos cuando la puerta se abrió y un alumno salió con dos hojas en la mano. Las hojas tenían código escrito en C++.

Estaba haciendo la tarea para una de las materias de programación y, como sabía que trabajo de programador, me preguntó como hacer algo. No importa el problema en sí, pero vamos a decir que su solución funcionaba para dos variables y quería que le funcione también para tres.

Le expliqué como lo solucionaría yo. Mi solución consistía en definir una función que reciba como argumento un array y haga cierto trabajo sobre este.

La respuesta del alumno me shokió.

Si... lo que pasa es que no nos dejan usar arrays todavía.

:o

Juanjo Conti: Tarde de escritor (independiente)

   Publicado:

Escribo rápido unas líneas antes de ir a buscar a mi mujer a la facu. Hoy tuve una tarde lida. Una tarde de escritor, independiente.

Lo anoto para no olvidarlo.

  • Terminé de ver Jessica Jones
  • Me hicieron una nota para un periódico
  • Fui a una librería a dejar ejemplares de mi último libro
  • Fui a una radio a hablar de ese libro
  • Leí unas páginas de una novela (siempre tengo una en el auto)
  • Vivi una historia

En las entrevistas se repitió una pregunta: ¿cómo se unen la actividad de programar y la de escribir?

Mi respuesta es que hay dos opciones:

  • hacer matería de literatura la vida del programador (por ejemplo, escribiendo un cuento en el que el protagonista sea un programador)
  • crear (programando) herramientas que le sirvan a mi yo escritor

La primera me cuesta más que la segunda.

Mariano Guerra: How to build Riak TS (Time Series Database) from Source

   Publicado:

To build riak ts we need some basic build tools installed, like compilers and tools.

On ubuntu/debian an derivatives:

sudo apt-get update
sudo apt-get install build-essential autoconf git libncurses5-dev libssl-dev libpam0g-dev

On RHEL, Centos, Oracle Linux and derivatives:

sudo yum update -y
sudo yum groupinstall "Development Tools" -y
sudo yum install openssl-devel ncurses-devel git autoconf pam-devel -y

A quick description of each so you can map to your OS:

  • build-essential: a group of tools to build stuff (duh!)
  • autoconf: needed to build basho's erlang OTP version
  • git: to fetch repos
  • libcurses and libssl: to have curses and ssl support on erlang
  • libpam0g-dev: required to compile a riak module (canola)
    • not sure about the RHEL equivalent, try pam-devel

Now clone the riak repo:

git clone https://github.com/basho/riak.git
cd riak

Checkout the Riak TS tag:

git checkout riak_ts-1.3.0

Download and install kerl to build the correct erlang OTP version:

mkdir -p ~/bin
wget https://raw.githubusercontent.com/kerl/kerl/master/kerl -O ~/bin/kerl
chmod u+x ~/bin/kerl
export PATH=$PATH:$HOME/bin

Build OTP_R16B02_basho10 erlang version (notice that this won't interfere with your local erlang installation, see kerl readme for details):

kerl build git git://github.com/basho/otp.git OTP_R16B02_basho10 R16B02-basho10
mkdir -p ~/soft/erlang-releases/R16B02-basho10
kerl install R16B02-basho10 ~/soft/erlang-releases/R16B02-basho10
. ~/soft/erlang-releases/R16B02-basho10/activate
export PATH=$HOME/soft/erlang-releases/R16B02-basho10/bin:$PATH

Now build Riak TS:

make locked-deps
make rel

And run it:

cd rel/riak
./bin/riak console

Juanjo Conti: En la montañita (audio)

   Publicado:

Hace unos días subí un cuento que escribí para un concurso.

Ayer leí el cuento en el taller de escritura. No está muy bien leído, pero lo subo igualmente para los que les da fiaca leer :)

Mariano Guerra: Papers of the Week VI

   Publicado:

Better late than never (even when I read all the papers last week) here is the sixth installment of Papers of the Week.

Starting next week I will try to write the reviews after I read the papers and not almost one week after when my memories are fuzzy :)

The fist one describes an implementation of out of order processing using punctuation, interesting in that it "applies" the concept of punctuation to building a streaming system and analyzes the result.

This one describes an implementation of a storage engine using LSM Trees and a compression technique.

You can read an overview of the next paper and find the link to it at acolyer's paper of the day: Holistic Configuration Management at Facebook, I copy the first paragraph here:

This paper gives a comprehensive description of the use cases, design,
implementation, and usage statistics of a suite of tools that manage
Facebook’s configuration end-to-end, including the frontend products,
backend systems, and mobile apps.

It's a good overview of tools and techniques used to scale and standardize configuration management and how to avoid problems introduced by sloppy configuration management.

The next one is my favorite of the week, it defines a baseline by implementing solutions from other papers that introduce some parallelization strategy by implementing them in a simple single threaded way and benchmarking it against other solutions, then defined a "metric" that describes how many cores are required to match the single thread implementation, as many sites would tell you "the result will amaze you".

The last one for this week surprisingly brought me to the CRDT/Lasp/@cmeik land, when the title didn't seemed to imply that, the crazy fact is that I saw a talk about this paper at RICON 2015 and I didn't remembered the title :)

Some parts where hard for me since it's the first paper I read about CRDTs so I don't have the vocabulary and basic theory in place but it made me think on some interesting applications on the IoT and monitoring spaces.

Papers this week: 5

Papers so far: 29

Papers in queue: 82

Share