The Week of Feb 11, 2018

A brief check-in of the ongoing development of Blundit, the world’s only expert accuracy tracker.

It’s been a long time since the last update, and much of that owes to the fact that Blundit is still very much a project I’m working on in my spare time, and being a freelancer is very much feast and famine. And while having a surplus of work is good for my wallet, it’s bad for my time to work on things like this site.

But!

I’ve been working on it for the past few months, and have gotten some good progress in. Unfortunately, given the nature of the work, it doesn’t look like it yet. I’ll describe my reasons at length in future posts, I’m sure, but I’ve been rewriting the front-end from scratch, and that takes a long time. The end results will be great, and technologically the site will be in a much better place (ES6 yay!), but I’m still actively reimplementing features that already exist on the old, Coffeescripted version of the site.

I’ve got a list of planned articles describing the process of rebuilding and completing Blundit, but to help me get back into the flow of blogging about it, I thought I’d also do a weekly summary of what I’ve done on the site, which this is.

If you want to follow along with what I’m doing in real-time, you can check out the project Github repos, and look at our public Trello board (we’re currently in the “Pre-Alpha v0.2 — CURRENT” column).

Staging sites

Previously, we had the working version of the site on Blundit.com, with no established staging environment. This was obviously bananapants crazytown, and is something we’ve corrected:

• If you go to Blundit.com now, you’ll see a brief “coming soon” page with an email newsletter signup form;
• The new staging environment is dev.blundit.com. This has the most current version of the site, implementing our more visually polished layout. Warning, though: it’s still pretty rough.
• The old Material-UI heavy version of the site is visible at old.blundit.com, should you have a desire to see it. It connects to the same data source as dev.blundit.com, and remains online so that I can use it as a comparison, which means it will go away in the future.

Query optimizations

For the backend, we’re using Ruby on Rails, and before this week, our DB queries were slower than they needed to be. To gratuitously insert a graphic into this post, this is what the DB currently looks like:

Tables!

Caveat: I’m a decent generalist, but I don’t always know about a lot of high-level optimizations to make. So the implementation of data models on Blundit is a bit elaborate, but basic. This didn’t lead to incredible slow-downs in local development, but on our staging environments (currently hosted in one of Heroku’s cheapest tiers) the site runs suuuuper slow at times. I think a lot of that can be fixed with a credit card, but before upgrading our tier (which will 100% happen when the development gets a little further along) I wanted to make sure that we were going as fast as we could be. To that end, I wanted to optimize our DB queries.

I found the very helpful article “Monitor and Optimize database queries in Rails” by Rutvij Pandya, which pointed me toward two Rails gems to use:

• lol_dba — It checks your db structure and suggests locations to add indexes. I had precisely zero indexes in my setup at this point, so it was a long list.
• bullet — This identifies areas where you should be using eager loading, where you’re using it but you shouldn’t, and where a counter cache should be used. I’d already implemented counter caches site-wide, so I was really just looking for places where I ought to be using eager loading.

DB Indexes are magic to me, so I won’t even attempt to explain them, but eager loading makes enough sense to me for fumble through an explanation. In Rails, if I had an Expert model and a Comment model and each Expert has many comments, that would be described like this:

class Expert < ApplicationRecord
  has_many :comments
end

If you needed to iterate through all Experts to get the most recent comment, the quickest way to do that (in terms of least effort on my part) would be:

Expert.all.each do |expert|
  @latest_comment = expert.comments.order('created_at DESC').limit(1)
end

This works but isn’t optimal, and I didn’t realize why until recently. In the above iterator, the DB gets called 1+N times: 1 for the Expert.all query, and 1 time each for every expert to pull in the associated comment data. So if you have 10 experts, you’d be making 11 queries against the db. Enter eager loading:

Expert.all.includes(:comments).each do |expert|
  @latest_comment = expert.comments.order('created_at DESC').limit(1)
end

Adding the includes(:comments) bit will make rails perform the initial query with a join, such that no matter how many experts there are, only 1 call to the db will be made. Much improved!

Vote override

One of the core elements of Blundit is user voting. A user submits a claim about an expert, and folks vote. There’s an initial voting window (currently set to 14 days) after which the system tabulates the votes and marks the claim true or false. Now, I will spend a significant amount of time in the future describing that system, and all of the steps we’re going to be taking to sidestep the very real risk of turning the site into an incorrect consensus reality machine, but for right now my main concern is that we don’t have enough users: if there aren’t enough votes on a given claim or prediction when the 14 days elapses, the system won’t mark it true or false, and will simply extend the voting period until the minimum has been met.

Since I didn’t want to drop the minimum to 1 vote on staging or manually set the claims to true or false using the rails console, I decided to write the first bit of my admin system and add the ability to force the truth of a claim or prediction. It looks like this, on the front-end:

If you’re not an admin, you can’t see this.

When you’re looking at a Claim or Prediction page, you can select true or false from the drop-down, and enter a reason. Since one of the overriding goals in Blundit is absurd transparency, I will be adding a History card to all Expert, Claim and Prediction views, so you can see every change and modification made to them over time, the vote overrides, and the reason provided.

Now, I want to use solutions like this as sparingly as possible: Blundit needs to be as nonpartisan as possible, and every intrusion like this risks that (or risks the appearance of partisanship, which I also want to avoid). Nevertheless, issuing summary judgment on truth claims in the early days of the site, so that when new users come to the site they don’t just see a field of question marks where Expert ratings should be, seems worth the trade-off. And in the future I’ll be adding a way for users to flag items as being marked incorrectly, so that if I get one of the overrides wrong, it can be fixed.

That’s it for this past week. Tune in next time for a bunch of Homepage content additions and, if there’s time, some work on the Embed feature!