Posts about programming

Gyro 0.3

Gyro grows some legs

It was just a few days ago that I started an experimental wiki project called Gyro ... it's always fun when a project just grows features organically. It does this, so it makes sense to make it do that, and then this other thing is easy, and so on.

So, here is what happened with Gyro:

  • Federico Cingolani made it run on docker
  • I added some features:
    • UI for creating new pages
    • UI for deleting pages
    • Support for multilevel pages (so you can have "foo" and "foo/bar")
    • Autocompletion with titles in search
    • Breadcrumbs so you can actually follow the multilevel pages
    • Lots of code cleanup
    • Themes (via Bootswatch)
    • Custom fonts (via Google WebFonts)
    • Automatic linking for WikiWords if you like that kind of thing

And, I published it as a Google Chrome Extension ... so you can now have a wiki on your chrome. If you saw how it worked before, you may wonder how it became an extension, since those are pure Javascript. Well... I made it have pluggable backends, so it can either use the older Sanic-based python API or use LocalStorage and just save things inside your browser.

The behavior is identical in both cases, it's just a matter of where things are saved, and how they are retrieved. The goal is that you should not be able to tell apart one implementation from the other, but of course YMMV.

And since I was already doing a chrome extension ... how hard would it be to run it as an electron "desktop" app? Well, not very. In fact, there are no code changes at all. It's just a matter of packaging.

And then how about releasing it as a snap for Ubuntu? Well, easy too, just try snap install gyro --beta

All the Gyros

Is it finished? Of course not! A non exhaustive list of missing MVP features include:

  • Import / Export data
  • A syncing backend
  • General UI polish (widget focus, kbd shortcuts)
  • Better error handling
  • General testing

But in any case, it's nice to see an app take shape this fast and this painlessly.

New mini-project: Gyro


Facubatista: ralsina, yo, vos, cerveza, un en tres horas, pensalo

Facubatista: ralsina, you, me, beer, a in three hours, think about it


The next day.

So, I could not get together with Facu, but I did sort of write it, and it's Gyro. [1]

Technical Details

Gyro has two parts: a very simple backend, implemented using Sanic [2] which does a few things:

  • Serve static files out of _static/
  • Serve templated markdown out of pages/
  • Save markdown to pages/
  • Keep an index of file contents updated in _static/index.js

The other part is a webpage, implemnted using Bootstrap [3] and JQuery [4]. That page can:

  • Show markdown, using Showdown [5]
  • Edit markdown, using SimpleMDE [6]
  • Search in your pages using Lunr [7]

And that's it. Open the site on any URL that doesn't start with _static and contains only letters and numbers:

  • http://localhost:8000/MyPage : GOOD
  • http://localhost:8000/MyDir/MyPage: BAD
  • http://localhost:8000/__foobar__: BAD

At first the page will be sort of empty, but if you edit it and save it, it won't be empty anymore. You can link to other pages (even ones you have not created) using the standard markdown syntax: [go to FooBar](FooBar)

There is really not much else to say about it, if you try it and find bugs, file an issue and as usual patches are welcome.

[1] Why Gyro? Gyros are delicious fast food. Wiki means quick. Also, I like Gyros. to check it out. So, since this was a toy project, why not?
[2] Why Sanic? Ever since Alejandro Lozanoff mentioned a flask-like framework done with the intention to be fast and async I wanted
[3] Why bootstrap? I know more or less what it does, and the resulting page is not totally horrible.
[4] Why JQuery? It's easy, small and I sort of know how it works.
[5] Why Showdown? It's sort of the standard to show markdown on the web.
[6] Why SimpleMDE? It looks and works awesome!
[7] Why Lunr? It works and is smaller than Tipue which is the only other similar thing I know.

La Importancia de los Dedos en el Pensamiento Informático

Pensar con cosas que no sean el cerebro es descalificatorio: vos pensás con el culo, vos pensás con el pene. Es una variante de hacer cualquier cosa con la parte incorrecta del cuerpo, porque yo escribo con los codos, ella programa con las patas, etc. Tal vez por eso me siento incómodo cuando empiezo un proyecto nuevo, porque siento una picazón indecente de empezar a pegarle a las teclas con las yemas, como si las ideas de como implementar cosas no salieran de mi cabeza, como si brotaran de mis dedos, como si fluyeran por mis brazos, como Palpatine electrocutando a Darth Vader, con esa prepotencia Arltiana de no poder conversar sino tipear en orgullosa soledad programas que encierren la violencia de un cross a la mandíbula, y "que los eunucos bufen".

Y no, no es la manera ideal de hacer las cosas, sospecho, en el mismo sentido que chapar en la primera cita o tocar ese culo consentido en el primer lento de Air Supply fueron decisiones que parecieron buenas en el momento pero muchos hemos vivido para lamentar, pensar demasiado con los dedos produce código de mierda, como era de mierda el noviazgo que empezó en aquel asalto, pero es realmente código de mierda si es código que existe comparado con el teórico noviazgo con la chica que no quiso bailar con uno? No, es código copado, es código gauchito, es código con savoir faire.

Pensar demasiado es someterse al waterfall interior, que es el peor waterfall, y sí, a veces he pensado un programa muy lentamente durante cinco años, dejándolo madurar en mi interior como una Tahina spectabilis que florece cada cien años, pero recuerden que la flor que produce huele como un cadáver y la planta muere inmediatamente. Los proyectos maduros son proyectos pudriéndose, es un equilibrio fino que no cualquiera puede caminar, no somos todos Philippe Petit, no sabemos cruzar de una torre a la otra sobre una soga, nos caemos como King Kong, trepados a una torre que no entendemos pensando en Jessica Lange.

La programación no es prog rock, no es Lark Tongues in Aspic, programar es, el 90% del tiempo, los mismos cuatro acordes de Sheena is a Punk Rocker, cambiados de lugar, más rápido o más lento, mientras hacés temas de dos minutos porque tu papá no te quiso cuando eras chico, es recordar que el primero se tira, como el mate, que el primero te lo regalan el segundo te lo venden, que por eso el primero lo regalás, el segundo lo hacés bonito y lo regalás también, que carajo.

Y mientras tanto, escuchen "Como salvajes" de Attaque 77, que dura tres minutos, te da ganas de salir a patear bolsas de basura por la calle, y es un cuento de scifi medianamente decente, no perfecto, pero mucho mejor que el que no escribiste.

I am now using almost an IDE

I have long been a proponent of simple text editors.

Not for me was emacs, with its multitude of modes and magical elisp code to do everything.

Not even vim with its multitude of extensions achieving magical productivity with three keystrokes.

Not even would I use the ubiquitous jetbrains IDE with magic refactoring that writes code on its own.

No, for twenty years or so I have written my code using a plain text editor. Until recently, that meant kwrite. Not even kate. Kwrite, the one that is slightly more powerful than notepad.

But then I got a new job, and everyone uses an IDE so I started thinking... I must be missing something.

Because if everyone is doing it differently from you, then one of the following things is likely to be true:

  • everyone is wrong
  • it's purely an opinion thing and it doesn't matter much
  • you are missing out

You know you are old once you assume the first. Since I am going through some sort of weird mid life crisis I am forcing myself to choose the last option most of the time. So, I started trying out stuff. Which is why I no longer use bash. Or unity. Or KDE. But those are stories for some other bonfire, this one is about my text editor midlife crisis.


It's huge. And slow. Like, really slow. And the extension quality is very uneven. For example, all the terminals felt wrong.

Once it started dragging after being open for a couple of days... well, I removed it and smugly went back to my old workflow.

And then I tried...


The extension quality was soooo much better! And some are just awesome. The way you can choose a virtualenv interpreter for a project is awesome.

Compared to Atom it's downright snappy!

The only things I did not like were:

  • So much magic in place, sometimes things only worked in the IDE.
  • Too slow to start, so I still had to use a plain text editor for casual edits.
  • At one point, things started to rot, and functions that had been working fine started to misbehave.

So then I had my goldielocks moment...


I was expecting to hate it. It's called Visual Studio! It comes from Microsoft! It's electron-based like Atom!

Yet, I loved it at first sight.

Not going to go over many details because I am not in the business of convincing people of things but here are some of the highlights:

  • Good python support, including virtualenvs, formatting, autocomplete, refactoring, debugger, etc.
  • Good Go support.
  • Nice terminal gadget! Ctrl+click to open files mentioned in the terminal!
  • Good markdown/reSt support including previews
  • The "compared to working tree" view is genious
  • If you run "vscode somefile" in the terminal, it opens in the current vscode.
  • The settings mechanism and UX are a great idea.
  • It's fast enough
  • The UI is fairly minimal, so most of the time it will look like my previous workflow used to look: two text files open side by side.
  • Test runner integration is neat.
  • In Ubuntu you can install it as snap install vscode --classic ... takes all of 30 seconds. And it's updated forever.
  • Lots and lots and lots of decent quality extensions.

So, all in all it does all the things I liked from the IDE side of the universe while not making the things I liked from text editors less convenient. And that's why I use it now.

How I Learned to Stop Worrying and Love JSON Schema


This post operates on a few shared assumptions. So, we need to explicitly state them, or otherwise you will read things that are more or less rational but they will appear to be garbage.

  • APIs are good
  • Many APIs are web APIs
  • Many web APIs consume and produce JSON
  • JSON is good
  • JSON is better if you know what will be in it

So, JSON Schema is a way to increase the number of times in your life that JSON is better in that way, therefore making you happier.

So, let's do a quick intro on JSON Schema. You can always read a much longer and surely better one from which I stole most examples at Understanding JSON Schema. later (or right now, it's your time, lady, I am not the boss of you).


So, a JSON Schema describes your data. Here is the simplest schema, that matches anything:

{ }

Scary, uh? Here's a more restrictive one:

  "type": "string"

That means "a thing, which is a string." So this is valid: "foo" and this isn't 42 Usually, on APIs you exchange JSON objects (dictionaries for you pythonistas), so this is more like you will see in real life:

  "type": "object",
  "properties": {
    "street_address": { "type": "string" },
    "city": { "type": "string" },
    "state": { "type": "string" }
  "required": ["street_address", "city", "state"]

That means "it's an object", that has inside it "street_address", "city" and "state", and they are all required.

Let's suppose that's all we need to know about schemas. Again, before you actually use them in anger you need to go and read Understanding JSON Schema. for now just assume there is a thing called a JSON Schema, and that it can be used to define what your data is supposed to look like, and that it's defined something like we saw here, in JSON. Cool?

Using schemas

Of course schemas are useless if you don't use them. You will use them as part of the "contract" your API promises to fulfill. So, now you need to validate things against it. For that, in python, we can use jsonschema

It's pretty simple! Here is a "full" example.

import jsonschema

schema = {
  "type": "object",
  "properties": {
    "street_address": {"type": "string"},
    "city": {"type": "string"},
    "state": {"type": "string"},
  "required": ["street_address", "city", "state"]

    "street_address": "foo",
    "city": "bar",
    "state": "foobar"
}, schema)

If the data doesn't validate, jsonchema will raise an exception, like this:

>>> jsonschema.validate({
...     "street_address": "foo",
...     "city": "bar",
... }, schema)
Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
  File "jsonschema/", line 541, in validate
    cls(schema, *args, **kwargs).validate(instance)
  File "jsonschema/", line 130, in validate
    raise error
jsonschema.exceptions.ValidationError: 'state' is a required property

Failed validating 'required' in schema:
    {'properties': {'city': {'type': 'string'},
                    'state': {'type': 'string'},
                    'street_address': {'type': 'string'}},
     'required': ['street_address', 'city', 'state'],
     'type': 'object'}

On instance:
    {'city': 'bar', 'street_address': 'foo'}

Hey, that is a pretty nice description of what is wrong with that data. That is how you use a JSON schema. Now, where would you use it?

Getting value out of schemas

Schemas are useless if not used. They are worthless if you don't get value out of using them.

These are some ways they add value to your code:

  • You can use them in your web app endpoint, to validate things.
  • You can use them in your client code, to validate you are not sending garbage.
  • You can use a fuzzer to feed data that is technically valid to your endpoint, and make sure things don't explode in interesting ways.

But here is the most value you can extract of JSON schemas:

You can discuss the contract between components in unambiguous terms and enforce the contract once it's in place.

We are devs. We discuss via branches, and comments in code review. JSON Schema turns a vague argument about documentation into a fact-based discussion of data. And we are much, much better at doing the latter than we are at doing the former. Discuss the contracts.

Since the document describing (this part of) the contract is actually used as part of the API definitions in the code, that means the document can never be left behind. Every change in the code that changes the contract is obvious and requires an explicit renegotiation. You can't break API by accident, and you can't break API and hope nobody will notice. Enforce the contracts.

Finally, you can version the contract. Use that along with API versioning and voilá, you know how to manage change! Version your contracts.

  • Discuss your contracts
  • Enforce your contracts
  • Version your contracts

So now you can stop worrying and love JSON Schema as well.

Creating Languages For Dummies


I don't have the usual programmer's education. I studied maths, and then dropped out of that, and am mostly self-taught. So, there are some parts of programming I always saw wearily, thinking to myself that I really should go to school to learn them. One remarkable such area is parsing and implementing languages.

Well... sure, school is always a good idea, but this is not that hard. In this article I will explain how to go from nothing to a functioning, extensible language, using Python and PyParsing. If you are as scared of grammars, parsers and all that jazz as I used to be, come along, it's pretty simple,

Read more…

FLOSS Decision Making in Action

If you are reading this there is a good chance you are involved somehow in open source development, or software development in general. One thing lots of people ask me when they know I have lead this sort of projects for a long time is "how do you decide things?". To which I have all sorts of bad answers like:

  • "It's a consensus thing"
  • "It happens organically"
  • "Sometimes it just happens"
  • "Anarchy!"
  • "You do what you do"

So, now here I have an AWESOME example of FLOSS decision making in action, which is ... all of the above.

Some context: Nikola is a static site generator, so it deals with reading and writing textual data from disk. It's also an internationalized project, which supports multilingual sites and translated data. It also runs un multiple platforms, like Windows, OSX, Linux, etc.

And to make that more fun, it also works on Python 2.7, and 3.3 or later. Which means it has to handle two different models on how to work with unicode data, in the same codebase. And that's not fun. So, we have been floating around the idea of deprecating python 2.7. And so, when s2hc_johan walks in with a unicode problem...

14:23:16 <s2hc_johan> I don't have a site with sections, but I tested it for the other case
14:35:42 <s2hc_johan> strange it worked for a while broken again, probably because I've got åäö in it now.
14:35:45 <s2hc_johan>
14:36:17 <s2hc_johan> if you wrap data with unicode it works, but I'm not sure that works in python3
14:36:37 <ChrisWarrick> s2hc_johan: how do you wrap it with unicode?
14:36:48 <s2hc_johan> unicode(data)
14:37:05 <s2hc_johan> but is that valid in  python3?
14:37:11 <ChrisWarrick> s2hc_johan: this is wrong on so many levels
14:37:16 <ChrisWarrick> s2hc_johan: please don’t do that, ever
14:37:48 <ChrisWarrick> s2hc_johan: This won’t work in Python 3 either.  You must have an actual encoding, and use the decode method.   try: foo = foo.decode('utf-8'); except AttributeError: foo = foo  # python 3
14:38:02 <s2hc_johan> what do you mean, that is like my standard when I get strnage data in, undoce(data) data.encode(whatever) data.decode(whatever) :)
14:38:23 <s2hc_johan> one of them ussually work
14:39:22 <ChrisWarrick> s2hc_johan: unicode() assumes ASCII, it never works right
14:39:32 <s2hc_johan> true
14:39:40 <ChrisWarrick> s2hc_johan: encode/decode with a specified encoding is fine
14:40:00 <ChrisWarrick> s2hc_johan: but you might need a try/except for Python 3 if it could have Unicode data already
14:40:16 <s2hc_johan> I'm a bit confused in this case since the output comes from json.dumps
14:40:34 <s2hc_johan> thought that would produce a unicode object
14:40:51 <ChrisWarrick> s2hc_johan: not necessarily on python 2
14:41:05 <ralsina_> if isinstance(thing, utils.str_bytes): thing=thing.decode('utf8')
14:41:15 <ralsina_> that works in py2 and py3
14:42:12 <ChrisWarrick> easier to ask for forgiveness imo
14:43:07 <ralsina_> maybe we should have helpers in utils enforce_unicode and enforce_bytes
14:43:13 -GitHub[nikola]:#nikola- [nikola] Aeyoun pushed 1 new commit to feed-previewimage:
14:43:13 -GitHub[nikola]:#nikola- nikola/feed-previewimage 4b79e20 Daniel Aleksandersen: Deprecated RSS_READ_MORE_LINK and RSS_LINKS_APPEND_QUERY...
14:44:58 <Aeyoun> Or upgrade to Py3.
14:45:11 <ChrisWarrick> ++
14:45:47 <Aeyoun> Unicode in Py27 is a nightmare. It tries as hard as it can to kill you at every turn.
14:48:09 -travis-ci:#nikola- getnikola/nikola#6426 (feed-previewimage - 4b79e20 : Daniel Aleksandersen): The build is still failing.
14:48:10 -travis-ci:#nikola- Change view:
14:48:10 -travis-ci:#nikola- Build details:
14:48:27 <ralsina_> ok, let's consider py3-only seriously.
14:48:40 <ralsina_> 1) Is there any distro commonly used with py3 < 3.3 ?
14:48:55 <ralsina_> 2) Do we just stop using py2, or we deprecate slowly?
14:49:15 <ralsina_> 3) Do we just start doing py3-only code, or we actively de-hack the codebase?
14:49:21 <ralsina_> That's my 3 questions :-)
14:50:13 <SteveDrees> Unicode is a nightmare
14:50:53 <SteveDrees> different python versions just changes where the pain point is
14:50:53 <s2hc_johan> which one is better isinstance... or hasattr('decode', ..)
14:51:02 <ralsina_> isinstance
14:51:08 <s2hc_johan> oki then
14:51:10 <ralsina_> hasattr is evil in itself
14:51:26 <s2hc_johan> just going to feed the kids then I'll make another pr
14:51:28 -GitHub[nikola]:#nikola- [nikola] Aeyoun pushed 1 new commit to feed-previewimage:
14:51:28 -GitHub[nikola]:#nikola- nikola/feed-previewimage 4c950ac Daniel Aleksandersen: flake8
14:52:13 <Aeyoun> ralsina_: user survey? pip download data?
14:52:33 <gour> ralsina_: create some poll at website/mailing-list about it?
14:53:18 <ralsina_> dude, I offered free shirts and I got only 10 requests ;-)
14:53:30 <ralsina_> so, how many answers do you expect about that sort of thing?
14:53:43 * gour thought shirts are jsut for devs :-(
14:53:47 <Aeyoun> ralsina_: release a unchanged version on pip that is flagged as py3 only. see how many downlaod it versus previous version in same amount of time.
14:53:51 <ralsina_> gour: go add yourself dude
14:54:18 <ralsina_> gour: TO THE SHIRT LIST! I just notced that sounded very rude :-)
14:54:43 <gour> ralsina_: where it is?
14:54:43 <Aeyoun> ralsina_: or one py27 version number and and one version py3 only version number at the same time.
14:55:17 <ralsina_> gour:
14:55:17 <gour> found it
14:56:00 <gour> ralsina_: wonder if xxl is too large or xl is enough
14:56:00 <Aeyoun> ralsina_: american or european sizes by the by?
14:56:03 <ralsina_> Aeyoun: that reflects how many people use py2.7 by reflex. I know *i* do because it's "python" and not "python3"
14:56:20 <ralsina_> Aeyoun: no idea about sizes to be honest... probably american
14:56:21 <Aeyoun> American sizes are … a big bigger. I’m probably a XS/S american but M european. :P
14:56:28 <Aeyoun> *bit bigger
14:56:39 <gour> ok
14:56:57 * gour submitted request
14:57:17 <ralsina_> So, what I would prefer to do is make people use py3 if they can. And it seems to me that pretty much everyone can, regardless of whether they still use py2 by defect.
14:57:26 <ralsina_> by default*, spanishism leaked there.
14:57:52 <ChrisWarrick> technically, using py2 is a defect
14:57:59 <ralsina_> So, if we all agree that most users *could* run nikola in py3... then let's do it.
14:58:02 <Aeyoun> Agreed.
14:58:15 <gour> sites won't stop working :-)
14:58:26 <Aeyoun> ralsina_: act on data not dev agreement?
14:58:42 <ChrisWarrick> guess we could change our docs/webiste to highlight 3.x
14:58:59 <ralsina_> Aeyoun: the only data we'd need is to know how many people have py2.7 and no py3.3
14:59:14 <ralsina_> not how many are *using* 2.7 instead of 3.3
14:59:38 <ChrisWarrick> micro-survey via ml?
14:59:39 <ralsina_> How about: let's announce that, unless lots of people complaint, we deprecate py2 by end of october
14:59:45 -travis-ci:#nikola- getnikola/nikola#6429 (feed-previewimage - 4c950ac : Daniel Aleksandersen): The build was fixed.
14:59:46 -travis-ci:#nikola- Change view:
14:59:46 -travis-ci:#nikola- Build details:
14:59:47 <Aeyoun> Mac is shipping with Py2.7 and no Py3. BUT MacPorts and Homebrew offer painfree Py3 installs.
14:59:58 <ralsina_> ok, mac is a good point
15:00:25 <ChrisWarrick> it’s not like we have Homebrew/MacPorts/Fink-based install instructions for them…
15:00:27 <Aeyoun> ralsina_: we could add a deprecation message every time `nikola` is run and ask people to bitch in a bug?
15:00:32 <Aeyoun> ChrisWarrick: hehe. ;)
15:00:50 <ralsina_> "I see you have python3 installed but I am running on 2.7 ... dude, what's wrong with you?"
15:00:51 <Aeyoun> Or maybe once per 24 hour rather  than every time its run.
15:01:00 <ralsina_> doit timed tasks :-)
15:01:12 <Aeyoun> ralsina_: "Don’t get in the way of progress! Upgrade to Py3 and save a developer’s mind today!"
15:01:32 <ralsina_> "niec unicode you have there, would be a shame something happened to it.. switch to python 3!"
15:01:39 <ChrisWarrick> ralsina_: hey, let’s start with a Google Docs survey on the ML.  One question: what Python version and OS are you using for Nikola? 2.7/3.3/3.4/3.5; Windows/OS X/[other: linux/bsd distro]
15:01:57 <gour> "Free t-shirt foreveryone switching from py2.7 to py3.3"
15:01:58 <ChrisWarrick> ralsina_: Just don’t require a Google account like you did last time.
15:02:00 <ralsina_> Second question: "Do you have python 3.3 or later installed?"
15:02:03 <Aeyoun> How much code can be removed with dropping Py27? Lowers maintenance cost and increases performance. That is also an important datapoint.
15:02:11 <ralsina_> ChrisWarrick: I needed to know who was asking for the shirt :-)
15:02:21 <ChrisWarrick> ralsina_: good point
15:02:25 <ralsina_> Aeyoun: not all that much, really
15:02:47 <ChrisWarrick> Aeyoun: it would need to start with a huge rewrite to remove all of our pointers in nikola.utils
15:03:00 <ralsina_> Aeyoun: there are a number of tiny hacks, which were a pain to get right but they always amount to one if and/or one decode :-)
15:03:26 <ralsina_> We can just turn a bunch of helpers in utils into noops
15:04:52 <gour> py3-only nikola is going to become v8?
15:05:15 <Aeyoun> gour: seems like a likely outcome. you’re following the discussion live.
15:06:34 <ChrisWarrick> if we do v8, we’ll have to merge the early tasks garbage
15:07:03 <ralsina_> Is it technically backwards-incompatible if we just stop working on py2.7?
15:07:21 <ralsina_> gour: welcome to open source software: behind the code.
15:07:30 <gour> ralsina_: :-)
15:07:35 <Aeyoun> Someone call in a documentary crew!
15:07:43 <ralsina_> Aeyoun: we have logs!
15:07:51 <Aeyoun> Oh, wait. This is already logged for prosperity.
15:07:57 <ralsina_> I am totally posting this somewhere as "this is how decisions are made in FLOSS"
15:08:40 <ralsina_> Ok, who creates the poll and who posts it in the blog, and who makes sure it appears on planet, and who sends it to the list?
15:08:49 <ralsina_> I would do it but I have work to do :)
15:08:51 <ChrisWarrick> ralsina_: I’ll do it
15:08:57 <ralsina_> ChrisWarrick: you rock dude!
15:09:01 <ChrisWarrick> ralsina_: should be really simple
15:09:03 <ralsina_> Ok, we have a plan!
15:09:17 <ralsina_> Let's consider the poll results in ... a week?
15:09:25 <Aeyoun> Let the logs show we’re all in favor of this plan of action. ;-)
15:09:29 <ralsina_> aye
15:09:51 <ralsina_> Also: can I do the "shame on you" thing on nikola build? It sounds like fun :-)
15:10:27 <ChrisWarrick> ralsina_: for the python version question: radiobox vs checkbox?
15:10:28 <gour> ralsina_: you can mention that Nikola (Tesla) was always for innovation ;)
15:10:44 <Aeyoun> "You’re using FIVE YEAR OLD SOFTWARE. Update your system."
15:11:00 <ralsina_> Aeyoun: I am totally getting at least 5 different comments there
15:11:01 <Aeyoun>
15:11:05 <ralsina_> ChrisWarrick: checkbox... maybe 2?
15:11:23 <ralsina_> ChrisWarrick: one for python version, one for operating system
15:11:32 <ChrisWarrick> ralsina_: ?
15:11:38 <ralsina_> ChrisWarrick: two questions
15:11:54 <ChrisWarrick> ralsina_: there will even be three questions (py2/3 used, OS, has py3)
15:11:57 <ChrisWarrick> ralsina_: and checkboxes it is
15:12:02 <ralsina_> right
15:12:05 <ralsina_> awesome
15:14:44 <ralsina_> Copied / Pasted for posterity

There you go, half an hour later, we have a plan to (maybe) deprecate it.

Now go vote here: Should Nikola support python2.7? Gives us data to decide!

Javascript Makes Me Cry: Turning a Date into a String

Working late last night in Alva I wanted to do something that sounded trivial:

When the page loads, get the current date and time, and if a certain input is empty, put it there like this:

28/05/2013 23:45

So, how hard can that be, right? Well not hard, but...

Getting the current date-time is easy: now = new Date(); So, is there something like strftime in Javascript? Of course not. You can get code from the usual places and have a untested, perhaps broken, limited version of it. And I am not about to add a strftime implementation to use it once. Sure, there are a number of Date methods that convert to strings, but none of them lets you specify the output format. So, let's try to do this The Javascript Way, right?

To get the elements I want to put in the value, I used accessor methods. So, obviously, these should give me what I want for the string, right?

now.getDay(), now.getMonth(), now.getYear(), now.getHour() now.getMinute()

Well, they are, at the date mentioned above, respectively: 2, 4, 113, error, error

Ok, the errors are easy to fix from the docs. It's actually getHours() and getMinutes(), so now we have 2, 4, 113, 23, 45 and of those five things, the last two are what one would expect, at least. Let's go over the other three and see why they are so weird:

Date.getDay() returned 2 instead of 28
Because getDay() gives you the week day and not the day of the month. Which is absolutely idiotic. So, you have to use getDate() instead. Which means the name is a lie, becasue the logical thing for getDate() to return is the whole date.
Date.getMonth() returned 4 instead of 5
Because getMonth() returns months in the [0,11] range. Which is beyond idiotic and bordering in evil. Come on, Javascript, people have been referring to may as "5" for nearly two thousand years now! What other language does this? Anyone knows one?
Date.getYear() returned 113 instead of 2013
Because it uses offset-from-1900. Which is amazing, and I had never heard of a language doing in a standard type. Because why? So, use getFullYear() instead.

Now, armed with the right 5 numbers, let's format it. Does Javascript have the equivalent of sprintf or format ? Of course not. In JavaScript, without 3rd party modules, you create strings by addition, like a caveman. Again, I know I could add a format method to the String prototype and make this work, but I am not adding an implementation of format or sprintf just to use it once!

So, this produces that I want:

now.getDate()+'/'+(now.getMonth()+1)+'/'+now.getFullYear()+' '+now.getHours()+':'+now.getMinutes()

Unless... the day or month are lower than 10, in which case it's missing the left-padding zero. Luckily, for the purpose I was using it, it worked anyway. Because OF COURSE there's no included function to left-pad a string. You have to do it by addition. Or, of course, add a 3rd party function that's out there, in the internet, somewhere.

Nothing Ever Really Goes Away On The Internet: ra-plugins

I used to manage a large number of QMail installations. And because Qmail was ... weirdly licensed, I wrote a set of plugins that ran on top of a patch called Qmail-SPP. I pretty much stopped doing that years ago because life took me in other directions, and forgot all about it.

That collection is called ra-plugins and I had not touched it since late 2008.

And today... I got a patch with two whole plugins to add to it so that it makes Qmail handle email addresses more like Gmail does (aliases using user+foo and making the same as userfoo).

So, I got them, added them, fixed a few simple building issues, updated the libsmtp it uses internally for one of the plugins to a later version, and there it stays, perhaps not to be touched until 2018.

Qt Mac Tips

My team has been working on porting some PyQt stuff to Mac OSX, and we have run into several Qt bugs, sadly. Here are two, and the workarounds we found.

Native dialogs are broken.

Using QFileDialog.getExistingDirectory we noticed the following symptoms:

  • If you do nothing, the dialog went away on its own after about 20 seconds.
  • After you used it once, it may pop up and disappear immediately. Or not.

Solution: use the DontUseNativeDialog option.

Widgets in QTreeWidgetItems don't scroll.

When you use Widgets inside the items of a QTreeWidget (which I know, is not a common case, but hey, it happens), the widgets don't scroll with the items.

Solution: use the -graphicssystem raster options. You can even inject them into argv if the platform is darwin.