Matthew Lang

This paste on Sourcehut isn’t particularly positive reading if you are a fan of plain text files. I’m not sure what not to make of this. Are software engineers the last group keeping plain-text files alive? I’m not sure. Obsidian is still a popular tool and it can’t be only software engineers that use it.

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.