HTTPX multipart plugin, lessons in the wild

Some say that open source maintainers should “dogfood” their own software, in order to “feel the pain” of its users, and apply their lessons learned “from the trenches” in order to improve it. Given that no one else is better positioned to make improvements big and small, it’s hard to dispute against this.

Gitlab CI suite optimizations, and how I decreased the carbon footprint of my CI suite

Ruby 2 features, and why I really like refinements

This is my second entry in a series of thought-pieces around features and enhancements in the ruby 2 series, initiated in the Christmas of 2013, and now scheduled for termination in the Christmas of 2020, when ruby 3 is expected to be released. It’s supposed to be about the good, the bad and the ugly. It’s not to be read as “preachy”, although you’re definitely entitled not to like what I write, to what I just say “that’s just my opinion”, and “I totally respect that you have a different one”.

Ruby 2 features, and why I avoid keyword arguments

Some politician one day said “may you live in interesting times”. Recently, it was announced that the next ruby release will be the long-awaited next major ruby version, ruby 3. That’s pretty interesting, if you ask me.

Ramblings about initial design decisions, internals, and devise

Yesterday I was reading this twitter thread, where Janko Marohnić, the maintainer of Shrine, who has recently integrated rodauth in Rails and is preparing a series of articles about it, describes the internals of devise, the most popular authentication gem for Ruby on Rails, as “making every mistake in the book”, claiming that rodauth, the most advanced authentication framework for ruby, is much better because its internals are “easier to understand”, thereby sparking some controversy and replies, with some people taking issue with these claims, and also with his approach of criticizing another gem because of “look how awful its internals look like”.