Matthew Lang

Over the weekend, I wanted to build something with Hanami. I wanted to build something with Hanami more as a learning exercise than anything else. I had a bookmark manager written in Rails that has been languishing on the side, so I thought I would build something a bit more functional using Hanami. I called it Laurel.

Bookmarks usually build up for me. I wanted to build a way to resurface bookmarks so they can be acted on. It’s something I didn’t have in the previous bookmark application. I also didn’t want to be distracted by using background processing. Any methods that calculate ranks or anything else like that will be handled during the request.

This isn’t my first Hanami project. I built a couple of smaller applications a couple of years ago, but I never kept them because they were just a way to see what Hanami can do.

Getting the project started was familiar. Typing bundle exec hanami new is almost the same as kicking off a new Rails project. Once I had a blank application set up, I started looking into the code. It has similarities to Rails, but also differences.

I’m not going to delve into the experience of using Hanami or compare it to Rails, but I enjoyed using it, and the developer experience is good.

As for the project’s goal, I eventually finished it on Sunday night. It includes the following features:

• Capture: add/edit, tag, import
• Curate: the digest page, Elo comparisons, evergreen marking, archiving, snoozing or ignoring bookmarks
• Decay: the HN-style ranking score

The digest page is the real workhorse of the application. Here you can decide which of the two bookmarks is more important and also action other bookmarks that appear on this page. Being able to action bookmarks over time with the archive, snooze or ignore buttons is more helpful to me and actively curates the collection.

The difficult part was deploying the application to Hatchbox. I originally had an error in the application that appeared only in the production environment, not the development environment. I eventually resolved this issue, but I still seem to have a deployment issue: it requires a restart after deployment, and I’m sure this is a mistake on my part when setting up the application.

I’m going to definitely keep using this, and over the next few weekends, I’ll be adding more features and hopefully resolving that deployment issue on Hatchbox as well.

I started working on a new bookmark manager tonight using the Hanakai toolset. It comprises the Hanami framework, Dry validation library and the Rom persistence toolkit.

This little project has two goals. The first is to learn Hanakai. Ruby on Rails is a reliable web framework, and I’ve used it for over 15 years, but I want to try something different. The second is to try something different with a bookmark manager. Instead of just saving bookmarks and forgetting about them, I’m going to try to build a bookmark manager that resurfaces bookmarks over time. It will do this on a schedule and based on bookmarks that fit the criteria for being resurfaced. The idea is that, over time, you’ll weed out anything that isn’t relevant and be left with only the bookmarks that matter.

I initially envisioned this as an email workflow, but I’m going to keep it simple and display the decision in the web app. Email would have meant building the sending infrastructure, but I didn’t want to deal with that this weekend.

The fundamentals are already in place. I will be dipping in and out of this over the weekend with a view to having something to deploy on Sunday night. The final decision screen will be for me only, but I’ll follow this blog post with more information on how I got on.

I’ve run my own bookmarking app for a few months now, and it has the same problem as every bookmark manager I’ve used. Nothing ever resurfaces. Save the bookmark, forget the bookmark.

That’s really two problems in one. First, bookmarks aren’t all the same. Some are evergreen and worth keeping forever. Others, like anything about a web framework, are stale within a year or two. I end up with two collections tangled into one. Second, managing bookmarks at scale is a chore. Bulk-editing helps — filter, select, update — but it doesn’t solve the deeper issue. I never revisit anything on purpose.

Over the weekend I sketched an app that tries to fix that with a daily email. Each one asks a simple question about these bookmarks. Which still matters? Whatever you pick gets a new lease of life. Whatever you skip goes back into the pool for another chance later. Miss a bookmark enough times in a row, and it’s archived for good — no more resurfacing, no more guilt.

I’ve also been itching for an excuse to build something real with the Hanakai toolset, and this feels like the right fit. I have no idea if it’ll become an actual product, but it’s a fun problem to build, and it should get me using my own bookmarks again.

I’m resetting my systems right now. It’s a chance to review a few of the tools I’m using and decide what works and what doesn’t.

Why now? Goals can wait for a date. A year gives you a clean line to measure against. Tools can’t. A broken system costs you something every day it stays broken, and there’s no reason to keep paying that cost until the calendar says it can change.

My experience with digital tools hasn’t been great. I find they add friction instead of removing it. So, what’s mostly changing is a switch from digital to analogue.

I’ve been using a loose version of bullet journaling for my workday for most of the past two years, and it’s worked quite well, so it makes sense to expand it into my own side projects and a few other things.

Fix it when it’s broken. Not when the calendar says you’re allowed to.

Over the last two weeks, two companies I rely on every day have made major financial contributions to a project run by an individual whose views I increasingly disagree with.

If you don’t know, and apologies if you do, here’s the gist.

1Password and DigitalOcean have each pledged money to the Omacom Foundation, the organisation behind David Heinemeier Hansson’s Omarchy Linux distro. Since starting a few months ago, the Omacom Foundation has received pledges from several well-known companies and patrons, bringing the total backing to $18.5 million. A startling pace of pledges for any Linux-related project.

I mention this because I use both 1Password and DigitalOcean. I’ve used 1Password every day for years. I’ve never used another password manager. I have several DigitalOcean droplets that run my own website and a few others. These aren’t just brand names to me; they are companies I’ve built tools, habits, and workflows around. That, and a fair amount of trust.

So, seeing these same two companies make substantial pledges to an organisation run by an individual whose views I don’t agree with is uncomfortable in a way I have found hard to act on. Where I keep coming back

It would be easy to say to boycott these companies like others have already said before me, but that’s not where I find myself.

The truth is, switching password managers isn’t a small thing. It’s more than an inconvenience; it’s a massive change involving family accounts, shared vaults, years of logins, and a process that has only now become second nature to my family.

Switching from DigitalOcean isn’t straightforward either. It’s servers, databases, file storage, DNS, and a handful of integrations I would need to build elsewhere.

The honest version of this post isn’t outrage. I understand why others feel that. I’m uneasy about the pledges, but this post is about something closer to friction. It’s the feeling of thinking I should do something about this, then wondering whether it’s actually worth it once I try to work out a plan to switch to alternatives.

Trying to separate the company from the founder

What makes this messier than the typical “company does a bad thing, boycott company” story is that the pledges don’t actually go to David Heinemeier Hansson. Omarchy isn’t a 1Password or DigitalOcean product. It’s a third-party product they have chosen to fund. On its own, this would usually be admirable.

But it’s hard to look past that DigitalOcean reportedly ended a modest, roughly $50-a-month sponsorship of GNOME and Flathub not long before pledging $3 million to Omarchy. That’s not “we don’t fund open source” — it’s a choice about which open source gets funded, and at what scale. GNOME is the desktop environment millions of Linux users rely on every day, quietly, without a headline-grabbing founder attached to it. Omarchy is only a few months old.

The complaint isn’t that they have funded open source; it’s that they have chosen to fund a project, a specific project, at a very specific time. It’s not that 1Password or DigitalOcean haven’t said anything themselves. It’s that they have picked a project with a loud and polarising founder, at a time when his politics are most visible.

Where does that leave me?

I’ll be honest, I don’t have a clean ending here. Not the one you’re probably expecting. I’m not migrating my 1Password account to another password manager today, or even next week. Probably never. I’m not migrating away from DigitalOcean either. It’s not what I want to do, but it’s the decision I have reluctantly made.

What I am taking from this is what I suspect a lot of people are quietly doing. Paying closer attention when my subscription renewals come up, keeping a better eye on alternatives I haven’t bothered to research before, and finally being honest that convenience does a lot of the work in keeping me as a customer.

It’s not the conclusion that many will be hoping for, but it is the honest one.