[three]Bean

We just put out a new release of the badges site with a bucket of new features:

• An interface to diff users against one another (be warned, there are some typos)
• Reports for periods of years, months, weeks, and days.
• FOAF metadata (as per our discussion at Flock on an infrastructure ontology. This is just the beginning.)
• A profile button that lets you optionally add a URL to your homepage and tack on a short bio.
• Some feedback as to when you were awarded particular badges.
• And a new badge to boot.

Oh, and that bad link on the badge page? (the "last awarded to...")..? That has been fixed.

Thanks to all who contributed to the latest release. If you were following the code review bonanza today, you know it was a real team effort.

Before I start, I have to plug that last week we presented on Mozilla's Open Badges community conference call. There were lots of good questions and ideas -- the whole thing went well. You can read more in Mozilla's writeup.

Ok, ok. The news from today is that I turned on 5 new badges in the Fedora Badges backend awarder. This one is my favorite from the batch:

As always, you can find the Fedora Badges people in #fedora-apps on freenode or on our swank mailing list

The latest release of tahrir (the Fedora Badges web frontend) includes a parade of optimizations. In my local tests, almost all page loads are 50 times faster.

As the number of users and badges in the system grew, performance got worse and worse. There were some so-called n+1 queries in there where page loads would scrape over the whole DB counting everyone's badges before responding.

That stuff has been removed; the badges site should be much snappier now (same goes for the the JSON API employed by Fedora Mobile).

I turned on 10 new badges in the Fedora Badges backend awarder this week.

This one's my favorite:

As always, you can find the badges people in #fedora-apps on freenode.

Talking over a pull request with @pypingou, we found that this one method of constructing a set from a list of stripped strings was slightly faster than another:

#!/usr/bin/env python
""" Timing stuff.

::
    $ python timeittest.py
    set(map(str.strip, ['wat '] * 200))
    30.9805839062
    set([s.strip() for s in ['wat '] * 200])
    31.884624958
"""

import timeit


def measure(stmt):
    print stmt
    results = timeit.timeit(stmt)
    print results


measure("set(map(str.strip, ['wat '] * 200))")
measure("set([s.strip() for s in ['wat '] * 200])")

Admission: Pierre bullied me into blogging about this!

UPDATE: Folks in the comments recommended using a generator or itertools.imap. The results are significantly better. Here they are:

import itertools; [s.strip() for s in ['wat '] * 200]
28.2224271297
import itertools; (s.strip() for s in ['wat '] * 200)
3.0280148983
import itertools; map(str.strip, ['wat '] * 200)
25.7294211388
import itertools; itertools.imap(str.strip, ['wat '] * 200)
2.3925549984

UPDATE (again): Comments further reveal that the update above is misleading -- the generators aren't actually doing any work there. If we force them to spin out, we get results like these:

import itertools; set([s.strip() for s in ['wat '] * 200])
33.4951019287
import itertools; set((s.strip() for s in ['wat '] * 200))
35.5591659546
import itertools; set(map(str.strip, ['wat '] * 200))
33.7568879128
import itertools; set(itertools.imap(str.strip, ['wat '] * 200))
35.9931280613

No clear benefit for use of imap or generators.