April 11, 2025

すみません

I'm heading to RubyKaigi next week. It'll be my first time in Japan. I'm currently frantically trying to memorize a handful of useful Japanese phrases, but I'm told that "sumimasen" and "kore o onegai shimasu" will get me pretty far.

I don't really know how many of you subscribed to this know about Solidus, the ecommerce framework that I specialize in. My company, Super Good, works primarily with companies that use it. I serve on the project's core team.

It's a really interesting project. The Solidus meta-gem is rapidly approaching 3 million downloads on RubyGems. Solidus powers billions of dollars in annual transactions. I've personally worked with plenty of 9-figure ecommerce businesses on the platform.

Because Solidus is a fork of an older platform¹, there are tons of stores out there. An important part of my job as a maintainer of the project is to ensure that we serve the needs of that existing community.

As a result of that, we've become adept at avoiding breaking changes. When we want to make significant changes to the project, we often follow this process:

1. We isolate the code we want to change by making the class or classes configurable.
2. We then deprecate the current implementation and introduce new classes to replace the existing ones, leaving the current implementation as the default.
3. In the next major release, we change configuration so that it now defaults to the new implementation.

At a later date the legacy implementation then either gets removed or moved to an optional gem for users that want to continue with it. This approach has two big benefits:

1. It reduces the burden of upgrades, while still allowing users to access the new implementations if they are ready.
2. It adds configuration points for users of Solidus to bring their own implementations of classes. This flexibility is one of the selling points of Solidus.

As we continue to develop Solidus, it continues to become more flexible, while keeping the upgrade path as smooth as possible. This helps avoid fragmentation in the community, allowing must users to stay up-to-date.

I'm writing about this because we've got two interesting efforts underway. The first is an effort to make it so that the code that recalculates an order's state (the promotions applied, taxes, adjustments, etc.) can be run without touching the database if all the records are already loaded.

This will hopefully be faster, but also allow Solidus stores to "simulate" changes to an order and show the results to a customer. This is useful when working with subscription orders, but also has many other use cases.

Similarly, I'm looking at making the pub/sub system pluggable. The current implementation, Omnes, is pretty neat, but frankly overkill for most stores. None of the stores we maintain take advantage of its more advanced features.

It's fun working within these kind of constraints. It changes how you work and is very different from most regular application/product work. That said, having these skills absolutely can come in handy for that kind of work, especially on large projects.

---

I've seen Deafheaven twice. I love them. They mix shoegaze with just the right amount of black metal to create a truly unique sound.

I've had their new record, Lonely People with Power, on loop since it came out. I think it's their best record to date and really exemplifies their sound. That's not to mention how appropriate the title of the record is.