I just added code signing and notarization for PaperAge macOS binaries using GitHub Actions, so here’s a very rough guide to how I did it.

→ Read more…

As I recently migrated this blog from Middleman to Bridgetown, I thought I could document one of my Bridgetown customizations: on-demand or build-time image resizing.

Notes

• In this approach, the originals are stored in the frontend/ directory and should therefore be also accessible via the Bridgetown built-in asset_path helper or through esbuild imports.
• The resized images are stored in src/images/resized so that they don’t need to be processed by esbuild
• The resized images contain a digest of the original (CRC32 by default) ensuring that they get reprocessed if the original changes.
  • The CRC hash should be sufficient for detecting changes in the original file in a non-adversarial environment, and it is very fast to compute.
  • The CRC code can be easily replaced with a more robust, though slower, cryptographic hash function if desired
• On the other hand, I’ve chosen not to add a hash of the generated image to the filename in order to avoid having to keep track of the originals and generated files in a manifest file.
• I’ve chosen not to commit the generated files to Git, but you might make a different choice based on your needs. If you do push the resized images to version control, make sure to also clean up any versions that are no longer needed.

→ Read more…

Which Ruby hash or message digest algorithm is the speediest in Ruby? My cursory Googling didn’t surface an up-to-date benchmark from anyone else so here are some rough results of my own.

Note: These algorithms are not all equivalent so don’t just blindly pick the fastest one! CRC32, MurmurHash, xxHash, and CityHash are all non-cryptographic.

• Ruby stdlib:
  • MD5
  • SHA1/SHA256/SHA512
  • Zlib CRC32
• Gems:
  • digest-xxhash v0.2.7 (XXH32/XXH64/XXH3)
  • murmurhash3 v0.1.7 (32/128)
  • cityhash v0.9.0 (32/64/128)
  • openssl v3.2.0 (MD5, SHA1, SHA256, SHA512, SHA3)

Update 2024-03-11: Added OpenSSL::Digest for MD5, SHA1, SHA256, SHA512, and SHA3

Results

100,000 iterations of hashing a 1 MiB blob of random data.

The benchmarks were run on an M1 MacBook Pro.

• Apple M1 Pro with 10 CPU cores (8 performance and 2 efficiency)
• macOS Sonoma 14.3.1
• Ruby 3.3.0
• OpenSSL 3.2.1

The benchmark source code is available on GitHub.

Simple syrup is an extremely common ingredient in cocktails and, as the name implies, very simple to make: it’s just sugar and water in a 1:1 ratio. What’s slightly less easy is knowing how much water and sugar to measure out to get a given volume of syrup.

My calculator uses the densities of water (1g/ml) and crystalline sucrose (1.5862g/ml) to do a fairly naïve estimation of the final volume.

This isn’t totally accurate because densities don’t quite work that way in real life. Possibly the most well known example of this is what happens when you mix ethanol and water (250ml + 250ml = 480ml).

However, for cocktails this gets us in the ballpark and the small difference doesn’t really matter.

Recipe

Combine both ingredients in a saucepan and cook over medium heat until all the sugar has dissolved.

Transfer immediately to a heat-safe bottle or let it cool to room temperature in the saucepan and then transfer to a bottle.

Simple syrup should be refrigerated unless consumed within a day or so. The sugar content is too low to prevent the growth of microbes.

My first Rust-based project, PaperAge, is a solution for making secure paper backups of important secrets. The backups are secured with state-of-the-art cryptography using the age format.

Personally, I use it to make paper backups of the bare minimum credentials I’d need to regain access to all my online accounts and backups. For example, the 1Password recovery kit plus my email account and Apple ID credentials.

One of the requirements for PaperAge was being able to print the backups at any printer without having to trust the printer or whoever operates it. This is why the generated PDF has a blank space for the passphrase. Additionally, this allows you to store the passphrase separately for extra security (either physically or you can trust yourself to remember it).

My personal threat model doesn’t include state actors or extremely tech-savvy burglars, so just relying on physical security and/or obscurity provides a sufficient level of security for my needs. I’m mostly guarding against the unlikely event where I lose access to all my devices at the same time and have to regain access to my accounts and backups from scratch.

Equally, I didn’t want the backup solution to be dependent on any one tool or person. Not even if it was my own project. To this end, you don’t need PaperAge to recover from backups made with it. Instead, you can use either the original age CLI tool or any compatible implementation. Behind the scenes, PaperAge uses rage, the Rust port of age.

Automated releases

The release workflow for PaperAge is highly automated and uses cargo release to tag and publish new releases.

Pushing a release tag to GitHub kicks off a GitHub Actions workflow that will create a new draft release on GitHub, cross compile for macOS, Linux, and Windows, and publish the release once compiled. Finally, it sends a workflow_dispatch event to the matiaskorhonen/homebrew-paper-age repository to kick off a GitHub Action that updates the Homebrew formula for PaperAge.

The Homebrew formula update action will install Homebrew, update the formula based on a template, test that the formula still works, and finally commit and push the updated formula.

Eventually, I’m planning on trying to get a PaperAge formula up-streamed to Homebrew itself, but the current Cask workflow works so well that I haven’t been very motivated to get it done so far.

Further reading

• Awesome Age: A collection of projects and resources in the age file encryption ecosystem
• cargo release: Cargo subcommand for releasing a crate
• upload-rust-binary-action: GitHub Action for building and uploading Rust binary to GitHub Releases

Last year finally brought to a close my three-year journey as an Euruko organiser. Euruko Helsinki took place at last, in-person, on the 13th and 14th of October 2022. 640 wonderful Rubyists from all over Europe and beyond descended on Helsinki, and we managed to have a wonderful in-person Euruko for the first time since 2019. Plus, another 200 or so joined the conference remotely.

Many people might not realise just how weird Euruko is on the conference circuit.

1. The organisers change completely every year. This means that there is very little institutional knowledge about organising the event. Every organiser ends up having to make their own decisions about everything from ticket and sponsorship pricing to venues to finances and taxation.
2. The country changes. I’m perfectly happy to lend a hand to the organisers of next year’s Euruko in Vilnius, but I have no knowledge whatsoever about venues, laws, or vendors in Lithuania, so my experience from Euruko 2022 will be of limited use. We help where we can, of course, but we have our own events to plan too.

I’m aware of no other event that operates like this, certainly not at this scale. Setting up an event for 500–700 people is a lot of work and involves a lot of moving pieces. Depending on your ticket prices and sponsorship sales, there’s quite a lot of money at stake. For example, the venue and catering alone cost us north of €80K.

As far as ticket and sponsorship sales go, we were able to take advantage of some pent-up demand in the community, so there wasn’t any doubt that the conference would be financially viable. At least not after we’d cleared the hurdle of the 2020 postponement and the 2021 remote-only conference. Even so, 1–2 months out from the conference, it looked like the event wouldn’t sell out. It did in the end, but much closer to the event dates than we would have liked. One of the biggest favours you can do for an event organiser is to buy your ticket as early as possible.

Euruko 2022 was run with an extremely lean organisation with most of the work going to me and Simo Virtanen with assistance from other volunteers as needed. For example, we had a small team of people for talk proposal reviews and a handful of volunteers for the conference days. It would have been a smart move to recruit volunteers earlier and to get them more involved sooner in order to offload some of the workload from my shoulders.

In the end, the event ran just about as well as I could have hoped, and the feedback from participants was overwhelmingly positive. I’m happy we had the chance to bring so many Rubyists together in Helsinki, but I’m not in a rush to organise another event of the same scale again. 😅

PS. I intended to write this blog post a month or two after Euruko 2022 but, as I often do with blogging, I procrastinated. Better late than never, I suppose.

PPS. If you liked Euruko 2022, have a look at our next conference, Oh the Humanity!

Related post: Picking the worst year to pitch for Euruko

In no particular order and not particularly well organised.

iOS 16

• A more comprehensive Map component in SwiftUI (support clustering, custom layers and so forth)
• A way to persist list expansion state for deeply nested Swift UI lists
• TranslationKit (allow apps to use Apple’s translation service instead of needing to send users to Google Translate)
• Better picture and video quality in shared albums (currently limited to 2048px on the long edge and 720p, respectively)
• Fix the autocorrect mess
• Walking instructions in public transportation navigation. In other words, give me turn-by-turn instructions if I need to walk from the last stop to my destination.

macOS 13

• Native collapsing of menu bar items in macOS (please Sherlock Bartender)

Xcode

• Code autoformat for Swift & Objective-C (in the vein of gofmt or prettier)
• More reliable SwiftUI previews

Moonshots

• A Music app that isn’t terrible (both on iOS and macOS)
• A redesigned Home app
• Having an Apple Watch shouldn’t block iOS app builds if they don’t have a watchOS build target (“Preparing the watch for development”)

Recently the fan on the PM2.5 sensor on my Awair had started to make an annoying amount of noise and no amount of canned air seemed to fix it. As I didn’t want to spend €329 on a new Awair Element, the best option seemed to be to replace the whole sensor (a Honeywell HPMA115S0-XXX).

→ Read more…

Da Bomb really is as terrible as everyone says…