Reviewing pull requests for snaps has been pretty terrible ever since snaps were introduced. There are a few very simple reasons: Building snaps locally in order to review is too much work. This is a fine place to start, but it doesn’t scale, especially if it takes any amount of time to build the snap in question (mine takes over an hour). Most CI engines use Docker. You can build snaps in docker with hacks and tweaks that sort of work sometimes, but it’s not a supported approach, and it’ll just randomly break next week....

The Nextcloud snap updates automatically. By default it might happen any time, although you can configure that. The snap provides a wonderful, user-friendly indicator that an upgrade is happening: it will become unresponsive and unvisitable until the upgrade has finished. Okay, I’m kidding, this is terrible and something we know we need to work on. My point is, there are times when your snap isn’t responding properly, and you want to know WHY....

If you’re an avid reader of the blog (and come on, who isn’t?), you’ll know that I’ve been maintaining a snap for Nextcloud since Nextcloud came into existence. Originally, though, that snap wasn’t called “nextcloud”, it was called “nextcloud-kyrofa”. My original goal was that I would bootstrap the snap for them, and then they’d take it over when they were ready. I hosted the code as a personal project on GitHub....

When I first started learning Rails back in the day, it was my first introduction to Ruby: I was learning them both at the same time. As a result, the line between them was rather blurry; I didn’t know what was coming from Ruby, and what was coming from Rails. The Rails approach of monkey-patching Ruby didn’t help. If I’m being honest, I didn’t realize that Object#blank? wasn’t a Ruby method until only a few years ago....