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.

Andy Croll asked on Mastodon for good/bad/indifferent experiences at previous RailsConfs’ and I wrote him a wall of text in my email client that I instead turned into this blog post.

A while back, Joe Sondow posted a great thread on Mastodon that is a perfect example of why you should split a complex job up into several individual ones. Basically, Worf was experiencing an error that caused Riker to post more than he should have.

In two previous posts, I explored the custom elements part of Web Components, concluding that the lifecycle callbacks provide value beyond rolling your own. I want to look at the other two parts of Web Components, which are the Shadow DOM and the <template> tag. These provide a templating mechanism that doesn’t work like any other web application templating environment and is incredibly limiting to the point I must be just not understanding.