This past week I've been doing some more not-my-objectives programming, to scratch some of my itches.

Bookmarks

I have a Pinboard account, but I don't habitually use it. I think most often because when I go looking for something, I can't find it from the title or tags and really need to search across the full text of the page.

Now, Pinboard does offer archiving, which brings with it searching against the full text of the page, but that does require a yearly payment. Not that I'm against paying for services I use (quite the opposite) but I just don't use Pinboard enough to justify the extra cost. Which is probably a vicious circle, I'll admit.

I've been trying Stache recently to solve this, and whilst I have enjoyed the simplicity of it, I've also been frustrated by the same simplicity. And by it not syncing correctly (I have no idea if it's the app or iCloud at fault). And by the app not syncing the full text anyway (between OS X and iOS this does makes sense, I don't want many megabytes downloading to my phone, but between my two Macs this would be ideal). And finally, the lack of updates makes me wonder if it's just another piece of abandonware.

Anyway, if I'm going use abandonware, I might as well be the one abandoning it. Then I only have myself to blame. So I started work on a django app for bookmarks, called evocation. Currently it supports adding bookmarks, and will then archive the bookmark permanently and take a screengrab of it. It will search using xapian, but only against the title, short description and URL for now. And it can import from Pinboard (so I had something to work with).

Better pagination of large sets

When you have thousands of bookmarks (4,563 currently), pagination is essential. The pagination example in the django documentation is terrible. And I don't just mean in the markup it uses. It presents as:

Previous  Page 12 of 229  Next

Yeah, I can hack the URL, but that's tedious.

So I added better pagination by using a python package called django-concertina. Which I also wrote. It is based upon how we used to build navigation at Yahoo. Probably around 2006–7, a few of us designed and added what we called "bell curve" navigation links to several Yahoo sites.

The idea is that you provide several points of entry into the pagination, not just first/last/next/previous. Links cluster around the current page you're on, but also move out further to the edges in larger increments (so, like a bell curve around your current position). It presents as:

1 .. 5 .. 10 11 12 13 14 .. 30 .. 50 .. 80 .. 110 .. 160
.. 229

This means your users can explore and drill down to specific things more quickly. It also has the benefit of making your results pages (and therefore the content pages they link to) much more discoverable by search engines as they will go much deeper through your indexes.

Slack

Is it weird that I have my own Pivotal Tracker that is integrated with my own Slack for the personal code that I write by myself? — me

I also started using Pivotal Tracker again to keep track of things. And pushing them into my own [Slack]. So when I write and commit code, I'm immediately told that I've written and committed it.

Using the Github-to-Slack integration requires granting Slack write access to your repos, both public and private. This skeeved me out a little, so I wrote a little python to more easily add the unauthed version of the integration to my repositories.