Skip to main content

Cuando Sea Grande

Este sábado cumplo 41 (no, no hago fiesta, no es que no te invité), y creo que llegó el momento de decidir que voy a ser cuando sea grande.

Mi problema principal para decidir un tema tan crucial antes de hoy es que me interesan muchas cosas. Y las que no me interesan... sospecho que si le pusiera un poco de ganas me interesarían.

Pero peor, tengo esa convicción interna, totalmente injustificada de que si me pongo, puedo más o menos hacer casi cualquier cosa que no involucre una aptitud física específica.

O sea, no, nunca voy a ser power forward en la NBA, ni triatlonista, ni equilibrista, ni ninja. Pero... sospecho que podría ser un guitarrista mediocre, o un poeta medio pelo, un escritor adecuado, o un razonable peluquero, por no decir un competente paleontólogo, un interesante director de cine, un actor promedio, un interesante analista político, o un buen taxista.

Esa sospecha es infundada dado mi desinterés en la política, poesía, detalles de cómo se toca la guitarra, y no saber manejar, entre otras cosas.

Así que durante los próximos diez años, mientras me voy haciendo grande, me voy a concentrar en cosas que ya sé hacer, como... epa. Lo charlamos el año que viene.

Nikola is Pluginificated.

Yes, I know that's not a real word.

So, the git master of Nikola now has plugins. In fact, not only does it have plugins, but is basically made of plugins.

You see, the code used to mostly be inside a class (called Nikola), and ... it had grown. That class had grown up to around 2000 lines of code. Which is completely ridiculous.

So, using Yapsy I turned the code inside out: almost all the code that was in that monster class was moved into plugins and the class turned into a smart plugin loader.

This has brought several advantages:

  • Now you can extend Nikola for your own purposes. Just create a plugin folder in your site, and put the extra functionality there.

  • Support for whole categories of things is now modular. Want to support a different markup? A different template system? Just write a plugin.

  • Want to add completely new functions to Nikola? Like, say, a way to import data from another blog tool, or something like planet software? Well, just add a "command plugin".

What has changed for the user?

  • You can delete from your site.

  • Use nikola build instead of doit

  • Use nikola serve instead of doit serve

Some minor things still need doing in this area (notable, fixing the docs), but the main refactoring is there.

Taxes, Game Theory, and Python (Part 1 of 2)

Before I gave up on becoming an educated man, I studied math. And to this day it pisses me that noone has figured out how to make math interesting to the math-averse. Here's a small attempt.

Let's consider the following scenario, based completely on things I know, not things I do ;-)

Suppose that in a city called San Isidro, there is a house. Houses in San Isidro pay a municipal tax, in exchange for the service of garbage collection, street sweeping, tree trimming, and street lighting.

It's a very small tax, but let's say it's $100 a month because it's a nice, easy to handle number.

Also, San Isidro is in a country called Argentina. In that country there are several laws that affect the home owners:

  1. You can't sell a house if you owe any taxes.

  2. The owner has a 1% chance of wanting to sell the house each month.

  3. Debts expire after 5 years.

  4. If you are sued and you lose, you pay they other guy's lawyer fees.

  5. Lawyer fees are capped to 25% of the money being disputed.

  6. Lawyers are reluctant to help you sue someone if they get very little money (defined as less than $2000)

  7. If sued by the city for owed taxes, the owner always loses.

  8. Unpaid taxes accrue 2% compound interest monthly. So, if you don't pay your $100, you will owe $102, then $104.04, $106.0128 etc.

With all those elements in place, let's play a game called "Tax Golf"!

The game is played by an indetermined number of players called owners and one special player called city.

The game is played to 100 "months" or until all property has been sold.

The goal of the game, for the owners, is to pay as little money as they can. The score is calculated like this: amount of money you paid divided by the time you owned the house.

The owner with the lowest score is the winner.

The goal of the game for the city, is to get as much money as he can. He's not competing against the players, for him it's a sort of solitaire where he competes against his past performance.

This, my friends is math. Math is a tool that helps you (among other things) do the right thing in this sort of complicated, arbitrary, real life scenario.

So, what's a good strategy for a owner, and for the city?

In a second post next wednesday, I will give some answers to those questions, using python.

Improved Importer and a Question

Thanks to the cooperation of Humitos who gave me his wordpress backup, I did some improvements in the import feature of Nikola, my static website/blog generator

So, if you were to try to use nikola_wordpress_importer from master now, it would:

  1. Not crash ;-)

  2. Download attachments

  3. Fix links to attachments so they work on the new site

However, I am now unsure of what exactly is in's export XML file. The posts themselves are in this form:

Muchas gracias Nico por hacer el video este. Groso, quedó muy bueno.


Two things jump to me:

  1. That's not HTML

  2. WTF is that youtube thing?

I am having some success processing it as markdown, since that handles the paragraph breaks and some other stuff. Maybe the youtube embedding is done with a markdown extension?

Anyone knows?

New Nikola Feature: Importer

I implemented a first drat of a importer for my Nikola static site/blog generator It's a work in progress but it works well enough that it can turn this blog into this blog

What works:

  • Posts

  • Pages

  • Drafts

  • Tags

  • Personal information

What doesn't work:

  • Comments

  • Links across posts/pages are left untouched

  • The output is pretty generic

This needs testing, so feel free to get master and try it. Asuming foo.xml is your data from

nikola_import_wordpress foo.xml
cd new_site
doit && doit serve

And point your browser to http://localhost:8000 to see the result :-)

Minor tweaking of the generated is generally needed for improved results.

The Steady State of Open Source

The Steady State Theory says, in rough terms that the universe has been and will be more or less as it currently is, because there are parallel processes of creation and destruction.

So, galaxies exhaust but then there are new galaxies, and the thing, as a whole, remains unchanged, in a way. Sure, it's not the same galaxy, and nothing that was in the old galaxy remains, but if you avoid specifics, things are the same.

I feel the same thing happens in the free software universe. The two forces are reaction and features.

Reaction is the creative force. Most, if not all, free software is reactive. It itches, I scratch, scratching is reactive. There are many examples:

  • There is no free desktop! Let's create KDE!

  • KDE is not the right kind of free, sort of! Let's create GNOME!

  • KDE and GNOME are too heavy, bloated and whatever! Let's create XFCE!

  • XFCE is not as lean and mean as before! Let's create LXDE!

  • LXDE is (we'll find something) let's create WHATEVER-DE!

This even happens within a project:

  • Hey, we created KDE!

  • KDE 1.x has no object model and GNOME does, let's do KDE 2.0 on CORBA!

  • Hey, that sucked, let's do KDE 2.0 on DCOP and KParts!

  • Well, that's old an crufty, let's do KDE 3.0 cleaner!

  • KDE 3.x looks old, let's throw all the UI away and do KDE 4!

And I am sure those familiar with any software product that has lived long enough to go through major rewrites and upheaval can do similar lists.

However, sometimes, the complains just don't go away.

  • Netscape 4.x is slow and crufty! We rewrote it as Mozilla!

  • Mozilla (SeaMonkey) is slow and crufty! We rewrote it as Firefox!

  • Firefox is slow and crufty! We wrote Chrome using webkit!

And guess what people say about Chrome? It's slow.

So, the lesson there seems to me that writing a lightweight, generally useful, web browser is impossible. Why? Because of features.

As projects age, they grow features. Like the strange ear and nose hair men start growing in their 30s, features are a fact of the lifecycle. And with features come code, because that's how you do features.

And code is a liability, as (I hope) you all know. The more code you have, the more expensive it is to add things, and to be swift about improving your application. Most successful projects die, or grow senescent, hobbled by the weight of their features.

So how does a project stay young? I can think of a few ways.

It may have a benign (or evil, for that matter) dictator, with the right amount of hostility towards features (Linux). It may be so exquisitely modular that features don't couple with each other (emacs). It may reinvent itself every 5 years and throw everything away (KDE). It may have a very clear focus on one feature and a culture around it (Bacula).

And for each of those mechanisms, there are incountable examples of projects with too annoying dictators, projects overengineered to absurdity, stalled rewrites that never release and absolute focus on a feature noone cared about.

Sorry, the universe is a tough place.

Nikola: New Tag Index Pages

Short and sweet:

In Nikola my static site/blog generator, the Tag pages used to just be a big list of titles linking to the posts in the tag. Now they can (optionally) look just like the blog does, but filtered. Check it out.

Minor tweaks still needed (like, mentioning the tag somewhere in the title), but the basic functionality (filtering, pagination, layout, etc) is complete.

To enable it in your site, just use master from git and enable TAG_PAGES_ARE_INDEXES = True in your

The end of

This site has been,,, and has been, for several years,

Well, I am slowly going to deprecate that URL, and the new URL will be // where you already can find it since a few months ago.

It will involve some work moving comments around and such, but nothing much should change, all old links should remain valid, and all comments should stay attached to the right post.

I will contact the various planets that aggregate it, but since the feed will remain constant thanks to feedburner, I expect not to lose anyone in transition.