Not long after the last siggnal post, I set to work improving the graph. First of all, making it larger so that it was easier to separate dots. I did a lot rejiggering of the visualization. I swapped and tweaked the color scheme – it had been a ‘heat map’ so high was red. I made high-siggnal green and fiddled with it to get the gradient looking just how I wanted – starting to turn yellow around the halfway line. I also modified the graph component to make dot size separate from color, and mapped size to total post volume. It’s a derived number (as is color), but it helps point the feature out, and small dots makes the dense blob of low-volume users easier to pick out
I found that I was mainly using the graph, so I created a dashboard page for it, with short top-5 lists. Not completely sure if those lists are actually useful, given that the same info is on the graph.
One thing I experimented with was aging-out the data. Unfortunately, it seems that you can’t easily do a group select on a subset of sorted data. Perhaps with a sub-query, but that’s rather unusual Arel syntax, if it’s even possible without dropping to SQL.
Account on record
In order to accept payment for Siggnal, I’ve got to be able to tie that payment to an account. So the runtime-only account model had to get converted into a full ActiveRecord object so that it could be saved. With that in place, it’s now possible to store the access tokens in the object/db and only keep an ID in the session, as is the normal practice.
Foundation for duplicity
A user, however, might have multiple accounts. There is still a lot to be cleared out of the way here, but it still seems advisable to separate users from accounts. The user model so far mostly just exists for it’s ID, so that that it can eventually be tied to payments. Code wise, it’s also a place to put all the related access control methods.
Digging up baobabs
After the initial hackathon, there were two really scary things. One was a potentially infinite loop that might very well exhaust the twitter api limit. That’s been fixed. The other was the siggnal calculation, which did a group over votes to get accounts, and then did a separate query for siggnal and noise (each) for each account. That, I’m pretty sure, would not scale. The current solution is to do a group by a bunch of terms, including the siggnal/noise tag, and then iterate over the set combining the two counts into a single object for a given account.
Cookies gone bad
I recently got an iPad (first gen) The siggnal/noise buttons work fairly well. My main difficulty is that whereas a desktop browser can be fairly long lived, the mobile browser resets the session quite liberally. I may have to create an option to stay signed in.