zerosleeps

Well I’ve done it. I’ve converted my personal financial transactions to Beancount plain-text accounting format.

Before I dumped my old MacBook I exported everything from Banktivity to a QIF file. Boy what a pain that file format is to work with. I tried parsing it using Python a few different times, but I eventually resorted to just using Sublime Text and some regular expressions. It’s one of those one-off tasks so there was no point sweating over anything more robust or reusable.

Interestingly, during about my 3rd attempt at scripting the conversion, I installed a trial version of the latest release of Banktivity to see if maybe chucking money at the problem was in fact the best solution. First thing it asked for? The credentials for an online Banktivity account. I couldn’t see any way around the creation of an online account, so that made my easy decision every easier. You blew it, IGG Software.

I made an aside about my dislike of autoloading in Rails a few weeks ago. As is almost always the case, other folk are far more eloquent at explaining these things than I am, so here’s a person called Eric Bower on the matter:

Since there are no import statements at the top of the file, it was a guessing game to figure out where source code was located. Is SomeClass a class we created in one of our repos? Is it a third-party class? I have no clue just by looking at how the class is being used.

I’ve been using an application called Banktivity since early 2016 to track my personal finances. Apparently I paid AU$83 for it back then, and another AU$50 in October 2018 to upgrade to Banktivity 7, and that’s the version I’ve been using ever since.

Then in mid-2020, and with great excitement, IGG Software announced that the next version of Banktivity would be switching to a new pricing model…

…a subscription 😡

They tried to sugar coat it by explaining you could subscribe then unsubscribe, and still be able to use the software. “A subscription unlike any other”. I absolutely get it - subscriptions are a great way of ensuring developers receive a predictable income, and customers receive continual updates. And don’t get me wrong: I rarely hesitate to plonk down money for software that makes my life easier or better, and I have several subscriptions for software.

But Banktivity just wasn’t - and still isn’t - worth another AU$50 to me. I only use it to track where money comes from, and where money goes. I don’t use any of the bank integration stuff, budgeting, or investment tracking functionality. I just like to be able to see how I’m doing, and have a good history of my spending. It’s a great life-journal too (“can you remember when we went to see that show?”) and it’s how I was able to open this post with exact dates and numbers.

So I stayed with version 7.

Right up until I got a new M1 MacBook this week. Banktivity 7 is old enough that I’d need to install Rosetta to use it and that, I’m afraid, was the straw that broke the figurative back.

So here we are. Another blog post where I state a problem, don’t have a solution, and just kind of wonder aloud what I should do about this. As I’ve alluded to I don’t want to stop recording this information, and I have a lot of history that I don’t want to throw away. But it doesn’t feel like a big enough problem that it’s worth paying for? Pre-2016 I just used a spreadsheet. Could go back to doing that? Or I could use something like Beancount which combines the beauty of plain-text files with the nerdiness of Python? I briefly tried GnuCash but it’s ugly and difficult and does way too many things I’d never touch.

Ah well, something else to add to my growing list of projects I really need to give my attention to.

Progress update on maybe possibly switching this site to Django.

So far so good. As predicted turning Jekyll posts (which are Markdown files with some YAML front matter) was pretty straightforward: a few regular expressions and a bit of json.dump gets me what I need. It’s not pretty, but it doesn’t need to be.

I dithered around a for a bit trying to work out if I should use migrations (with the posts data baked in since the source files won’t be available anywhere other than my local machine), or JSON fixtures. I’ve settled for fixtures, since I’ll need some realistic data to run tests against anyway, and it means I can load the posts whenever I want and as many times as I want.

Fun fact which doesn’t appear to be particularly well documented in the Django documents: if you include the “pk” value in a fixture, Django will create/update the corresponding record in the database. But you can also omit “pk” and it’ll always create a new record (assuming the model has an automatic primary key).

Also as predicted, turning the reading log entries into something sensible is going to be fiddly. Again, a couple of regular expressions has gotten me about 75% of the way, but for the other entries I’m just going to manually fix them up. There are only 87 of them in total (as I type this) so no big deal if I have to eyeball ≈20 of them.

My next challenge will be tackling Octopress’ code blocks and img tags.

So zerosleeps has been chugging along as a static, generated website since early 2015. Unfortunately Octopress, which I use to generate the site, hasn’t been updated for several years. I haven’t helped matters - I don’t think I’ve once attempted to update any of the dependencies. It doesn’t really matter because the end result is still perfectly legal and valid HTML and CSS (although I am serving version 1.9.1 of jQuery which is from 2013).

Anyway, I’m starting to get nervous about using outdated tools to generate the pages. Octopress was written for Ruby 1.9 which has long since stopped receiving maintenance updates. There’s a dependency on Jekyll 2, while the latest version of Jekyll is version 4. Rake is now on version 13 but I’m pinned at version 10.

I’m thinking Django. My goto for this kind of stuff used to be Rails, but I’m a bit over Rails these days. It looks like Rails 7 takes a serious stab at resolving a lot of the front-end nonsense that’s in Rails 6, but Rails 7 hasn’t been released yet and the more I use Django the more I like it. It’s the explicitness that attracts me - something which is very much missing in Rails between autoloading, deep class hierarchy, and Ruby’s wild-west require system.

There’s also the matter of my reading log, which at the moment is a single static Markdown document. It’s just screaming to be turned into a proper database entity.

So what would I need to do to make this happen? Well each post is an individual Markdown document with some YAML front matter. Should be pretty straightforward to convert and pop into a title + date + body model. I’ve used Python-Markdown before, and the only issue I think I’ll have is with Octopress’ custom img tags. I don’t have too many posts with images, but now I’m thinking about it I probably would include images and photos more if they weren’t such a pain - I currently manually create different sizes of each file and copy/paste filenames.

I’ve got heaps of posts with blocks of code as well. Might have to get Pygments involved somewhere…

URLs are important. I don’t want to break any external links, so I’ll be keeping the current “blog/<year>/<month>/<day>/<slug>” structure around. Maybe just for backwards compatibility though - the granularity of the current structure is unnecessary so perhaps a simpler default?

There’s the aforementioned reading log, which will be a pain to convert and transform. While there is structure to each entry, it’ll be a pain to programmatically parse. There are also some entries that don’t have full dates, so can’t be represented by a datetime object. I’ll need to think about that.

The only other thing I can think of at the moment is RSS feeds - I currently have a JSON feed (which should be easy peasy to replicate), and an Atom XML thing, which might be trickier.

And I’ll for sure be using a CSS framework, likely with minimal changes because I suck at visual design.

Let’s see what happens, and how long it takes me!