Flag voting

What it is built on

Django is my go-to framework for any sort of website, so I made this a basic Django application. I wanted to avoid using any JavaScript in favour of keeping this all managed server side, for no real reason except to maybe strike out at the current state of web development.

I store each vote so the whole voting system can be replayed if there was ever a bug found in how votes were calculated, if I wanted to add new voting methods or if I wanted to analyze the data over time.

Problems started early

I started with a set of country flags, opting to use SVGs since they scale perfectly regardless of how high DPI your display is. I shortly noticed some weird problems on certain flags, and it wasn’t until I saw this disaster that I started to realize what was going on

Since I was just inserting the content of the SVGs directly in the DOM, the ID values of various elements (usually stars, which are a very common theme in flags) would conflict and the flag on the right would end up with weird rendering issues.

Solving the rendering problem

I still wanted to keep things as SVGs, so my first thought was to find any ID values in the SVGs and prepend them them with a unique identifier from my database, but I must have done something wrong because this approach ended up not helping and corrupted a few of the SVGs. For the sake of not getting stuck on this little problem I decided to just serve each flag as a SVG from a URL, and change from having the SVGs declared in the HTML directly to be fetched from the server. This had a few disadvantages, since it would cause 2 extra requests to the server, and some extra database queries since all the flag data is stored in the database. It was better than having broken rendering so I went ahead with it thinking I would revisit if it ever became an actually problem in rendering speed.

Showing results

With the rendering problem solved I wanted to show the top and bottom 5 results. This was pretty easy since the scores are all available in the database… mostly. With TrueSkill you save a mu and a sigma value which you can perform some basic math on to come up with the actual rating. I didn’t want to duplicate this calculated value in the database so I added a custom manager to add the trueskill rating as a field that could be acted on.

class FlagManager(models.Manager):
    def get_queryset(self):
        qs = super().get_queryset()
        qs = qs.annotate(
            trueskill_rating=models.ExpressionWrapper(
                F("trueskill_rating_mu") - (3 * F("trueskill_rating_sigma")),
                output_field=models.FloatField(),
            )
        )
        return qs


class Flag(models.Model):
    # [field definitions snipped for brevity]

    objects = FlagManager()

I could then show the results, without any database duplication!

Adding state flags

I am going to call these state flags, even though I live in Canada which does not have states, but has provinces. State is a nice short word that people generally understand is a bit easier to describe than something generic like “administrative district” since many countries have different terms for this sort of thing.

Country flags were added and working but were getting a little boring. Many people like to joke about how bad the United States’s state flags are so I added a new type of voting for these so-called state flags. I started with Canada, USA and Netherlands but grew to add many more as the process became more streamlined.

I quickly noticed that any new flag that was added would be considered a low ranked flag, which didn’t make a lot of sense to me since it never got the chance to prove itself and took away from the fun of seeing the truly lowest ranked flags on the list. I needed to add a new way to only consider flags which were involved in a minimum amount of votes.

I decided to add a new object manager for this, which would only include flags which have had been involved in at least some lower bound of votes.

class MinimumVoteManager(FlagManager):
    def get_queryset(self):
        qs = super().get_queryset()
        qs = (
            qs.annotate(
                num_first_choices=Count(
                    "first_choice",
                    Case(
                        When(first_choice__choice__isnull=False, then=True),
                        When(first_choice__choice__isnull=True, then=False),
                    ),
                ),
                num_second_choices=Count(
                    "second_choice",
                    Case(
                        When(second_choice__choice__isnull=False, then=True),
                        When(second_choice__choice__isnull=True, then=False),
                    ),
                ),
            )
            .annotate(num_choices=F("num_first_choices") + F("num_second_choices"))
            .filter(num_choices__gt=settings.MINIMUM_VOTES_FOR_STATS)
        )
        return qs

I had never used the Case(When()) syntax in Django before but it really is powerful and lets you express some complex scenarios without a lot of fuss.

One interesting thing is that I switched from using Sqlite to Postgres around this time, and saw that this query would take about 500ms to complete on Sqlite, but with the same data in the database the query would take less than 50ms on Postgres. Before I switched to Postgres I was thinking about removing this query because it wasn’t strictly required but was making pages take a noticeably longer time to load than would usually be needed.

Finishing touches

I added a full list of results, showing both state and country flags in their complete ranking. This page ended up serving 80MB of content and took something like 4 seconds to load. I reconfigured my nginx configuration to compress HTML requests and ran all of the SVGs through a python library named scour which brought the total request size down to around 14MB.

This page was now making hundreds of individual requests to my web server, since every flag had to be its own request to avoid the previously mentioned rendering problem. Now that this was an actual problem I figured I should solve it.

After a bit of searching online I decided to make each SVG use a data URI instead of a new request. This avoids the rendering problem since every SVG is in its own scope I guess. I was running into issues unless I also ran each SVG through a base64 encoder which I don’t think is strictly necessary but I didn’t really feel like trying to optimise this any more than it needed to.

So now the website is mostly complete. I might decide to add more state flags or even grow the concept into city flags if I get bored one day.

The results

With all the boring technical ramblings out of the way I am going to talk about what my website has decided the best and worst flags are.

The most common voters were myself, and some of my friends and co-workers. I tried to advertise the website briefly on reddit and twitter but that got very little uptake.

I’m not going to bother showing images of the flags here, you can just look at the results yourself if you want to see what they all look like.

Conclusion

I really enjoyed working on this project. I wish that I was able to get more people interested in casting votes. I learned a bunch about SVGs and some new ways of querying in Django. The whole thing is open source on Github if you are interested.