The short summary is that in fiddling with my blog, I permanently broke the RSS/Atom feeds I used to have. If you subscribed to those in the past, you need to subscribe to my new feed.
I blame Octopress.
Though that doesn’t really explain anything.
So back when I started this incarnation of my blog, I realized that I didn’t want to use something like Wordpress again. The friction inherent in writing a new post—along with my consistent worry about how the posts would be backed up—was just too much. I needed to do something different.
Some coworkers of mine were attempting a competition at the time, to just regularly blog. Part of me wanted to join their quest, part of me knew that my previous blog was basically a disaster.
But I was looking at various other ways of doing blogs—and I was also getting interested in static site generation.
Somehow or another, I ended up looking at Jekyll. And then discovering that Atom had a plugin that played nice with it. And possibly some other things.
So I decided to go for it.
Though, it wasn’t just Jekyll. It was Octopress.
To provide some context: Jekyll is a static site generated geared towards bogging. Octopress advertises itself as a plugin shell around Jekyll to make it really awesome. And it promises a lot.
But it did not live up to those promises, and still doesn’t. At the time, the author of Octopress had basically announced a complete rewrite of Octopress (before the previous version had particularly been finished), which was still in its early stages.
I was perhaps a little wary (though my ignorance at the time regarding
bundle didn’t make me wary enough), but Octopress had some things that I really did like in it, such as a plugin that handled all of the Atom/RSS feeds.
Therefore, I went with Octopress. But as I built out the blog theme, I discovered that I used very little of Octopress. Its documentation was sparse, and its override system overly arcane for what I wanted to do. It seemed like Octopress had largely been built as something that you either drop in and accept the defaults with few modifications—or are the author of Octopress.
Needless to say, my theme did away with a bunch of that.
I still ended up using two Octopress plugins, though. The first would allow me to easily do link-style posts; the other would do my feeds. All was good.
Then Jekyll released version 3; I had been on version 2.5-something. It broke everything, because Octopress hadn’t been updated to Jekyll 3, and Jekyll 3 had changed some of the underlying APIs.1 This is when I created a
Gemfile and tried to manage the dependencies that way.
But I still wanted to update to Jekyll 3 sooner or later.2
I therefore had two options: either wait for Octopress to support Jekyll 3; or expunge Octopress and revert to a more pure Jekyll installation.
While I waffled between those two options, a couple things happened. The first was that Octopress pretty much made no apparent effort to even acknowledge Jekyll 3, much less make any attempts at all to support it; there are issues that have been sitting open for literally years asking for Jekyll 3 support, with no real follow-up.3 The second was that my own work pushed me towards more command-line solutions, and I started to realize that I didn’t need Octopress for its
deploy command or other chrome like that, because I could just write the
rsync myself. I had no desire to dump Jekyll, but I started to embrace the idea of just rolling my own solution to things. The third was that I was starting to be more and more disappointed with the Octopress chrome I had, and how bloated it felt.
And then, I decided I wanted to make some changes to my templates. I wanted an archive page. I wanted to make tags more apparent and visible. I wanted to add a JSON feed.
Things that would require me to make changes and build stuff.
And that tech debt of Jekyll 2 was hanging over my head.
And Octopress still hadn’t made any real motion towards being compatible with Jekyll 3.
So, I decided it was time to expunge Octopress.
deploy was easy: I created a
Makefile that runs the
Expunging the plugin for allowing link posts was pretty easy: I just copy-pasted that plugin into Jekyll, because it’s a standalone; I can trim it down to what I want/need later.
The Octopress plugin for generating feeds relies on literally the entire Octopress architecture. It’s not really just one plugin; it’s somewhere around a dozen. Some of which were also incompatible with Jekyll 3.
I tried to do the same thing. I tried to copy-paste the plugin in Jekyll, so I could trim it down later. I ended up doing it for the first layer of dependencies. And I just could not make it work.
So, dear reader, I gave up. Instead, I pulled the official Jekyll plugin for creating a feed. The downside is that it’s nowhere near as customizable, and it doesn’t support link posts well.
But it finally allowed me to get rid of Octopress…and reduce my blog generation time significantly.
It’s just that in the process, I broke the old feeds. I wonder: how many people were actually using them?
At some point, I might go and just do my own custom feed XML, using the current plugin as a base. Then I’d be able to do link posts the way I want. I might even try my hand at replicating what Octopress did, but without the ridiculous number of dependencies it had.
Yet again, I am convinced that having as few third-party dependencies as possible is a very desirable thing. I’m just sorry I broke all the feeds. But it’s not like I post so often that I need all those other ones.
I suppose this is, ultimately, the ultimate theme of this blog: that things always change. You can’t count on anything truly being static, because it’s all shifting and changing out from under us.
We’re just along for the ride.
Presumably, with good reasons. ↩
Why? That’s a good question. Some of it is my general desire to stay up-to-date; some of it is that the documentation is now for Jekyll 3. Some of it is just stubbornness on my part, I suppose. I can’t leave well enough alone. ↩
This is a common problem among open-source projects largely maintained by one person. They build the project to fulfill their needs and release it because other people might find it useful, but if any problems that arise don’t fall under their scope of using the code, then it frequently gets deprioritized or forgotten. I’m not necessarily blaming those authors; I would probably do similar in their positions. But it is rather frustrating when there’s an outstanding bug in a software package you use with an outstanding pull request to fix, and the author simply says “it’s not a problem I have, so I’m not going to bother trying to fix it.” ↩