In the end notes of my post on creating a sorting and filter table using custom elements, I mentioned that my solution would not work if the <table> inside <fancy-table> was modified. This post outlines how to address that using MutationObserver, and it’s kinda gnarly.

Custom elements that wrap HTML (AKA “HTML Web Components”) can be extremely useful for re-using logic without requiring the user of the custom element to adopt any particular UI or styling. And this is usually the sort of re-use you actually want.

Let me demonstrate by creating a way to sort and filter any HTML table. Sorry, this is a bit long.

Noel Rappin wrote an article on static typing in Ruby that does a great job outlining the various techniques to achieve the benefits often ascribed to static typing. I have two more techniques that address the 80% case of typing problems in Ruby: keyword arguments and class constants.

In my experience, most typing issues in Ruby and Rails apps are the result of overuse of hashes as data structures, coupled with the use of symbols to refer to classes instead of using the class itself. Both of these patterns result in indirection between intention and behavior. When you get it wrong—use the wrong hash key, call the wrong dynamically-created method—you get errors that don’t make sense.

Peter Shilling wrote a blog post about generating what he calls “cool ids” for models in Rails. Instead of numbers, models have an id prefixed with its type, like cus_abcdefg1234 for a customer. I like the idea, but don’t think these ids should be used as primary keys. External IDs are incredibly useful for a lot of things, but they aren’t great as primary keys. I’ll explain what public-facing external IDs are, how to make them, and why they shouldn’t be your primary keys.

I could use Docker, but didn’t understand it until I wrote Sustainable Dev Environments with Docker and Bash. While I was expecting to kind hate it, there’s actually some really cood stuff about Docker and its ecosystem. But yeah, there’s some crap, too.

Marco Rogers asked about estimates on Mastodon, and I agree with a lot of what he’s written. Engineers often think they should not have to do estimates, going so far as to champion the “no estimates” movement, or claiming that engineers should not have to be accountable for their work. Writing software is expensive, and the people paying for it have every right to ask the developers when it might be done.

Working on some personal projects where I’m not constrained by older versions of Ruby or on Rails, I’ve been trying to learn and use features of Ruby introduced in the last few years. One feature is pattern-matching, and it’s caused me to ask the question: what is the best way to create a branching control structure in Ruby?

Before going into this, I was solidly team if statements, but now I’m not so sure.

My new book “Sustainable Dev Environments with Docker and Bash” is now available for $19.99. It will teach you Docker and Bash fundamentals you can apply to build a dev environment for any tech stack, that runs on Windows, macOS, and Linux.

On Matstodon, Peter Solnica posted some Ruby pattern-matching code, asking what Rails devs think about it. While pattern matching is interesting, I think I still prefer if statements based on return objects. But, I also think the “success/failure” dichotomy is unnecessary, confusing, and often a modeling error.

I’ve previously written about a basic experience with Web Components and not getting it, but I think I get it now. In this (quite long) post, I’m going to go over how I built Ghola, a palette generator for developers. It’s entirely built with custom elements. It has almost no dependencies, runs fast, and was fun to work on.