zerosleeps

Since 2010

Converting Jekyll posts

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.

Time for a new platform?

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!

New Rails projects still wet the bed

Here we go again. Past all the Ruby/Rubygems/Node.js/Yarn nonsense and on to creating a shiny new Ruby on Rails project:

% ruby --version
ruby 3.0.1p64 (2021-04-05 revision 0fb782ee38) [x86_64-darwin20]
% rails --version
Rails 6.1.4
% rails new foo

At this point you’ll have about 150 gems installed and 687 (!) folders in node_modules 🙄 Anyway, switch to the brand new, everything-as-per-defaults project and run rails test:

% cd foo
% ./bin/rails test

And what do you know?

/Users/scott/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/bootsnap-1.7.5/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:34:
in `require':
cannot load such file -- rexml/document (LoadError)

There’s an issue about this but it’s been closed with a “not our problem” type of response:

This is an issue with selenium-webdriver … Could you please report there?

But the thing is Rails developers, the dependency on selenium-webdriver is your dependency. It’s in the Gemfile created by default. Out of the box Rails does not work.

I believe this is the first time I’ve attempted to spin up a new Rails application since my last rant back in January, and it’s sad that I wasn’t in the least bit surprised that the defaults don’t work.

I can only assume Rails isn’t interested in attracting new users, because goodness knows why anyone would put up with the amount of shit you need to know about and debug from the first minute of using this stuff.