Noel Rappin Writes Here

Hey, if you like this post, you might like my recent books: “Modern Front-End Development for Rails” (Ebook) (Amazon) and “Modern CSS With Tailwind” (Ebook) (Amazon). If you’ve read and enjoyed either book, I would greatly appreciate your help by giving a rating on Amazon. Thanks! When last I talked about the Elmer project tracker, I was talking about Ruby magic and singing the praises of StringInquirer. I was expecting some pushback on the Ruby Magic™, but didn’t get any, so I threatened to do something really weird, like implementing an API for getting project history with something metaprogrammy and dynamic, like project.

A quick program note: If you like this newsletter, you might like my recent books: “Modern Front-End Development for Rails” (Ebook) (Amazon) and “Modern CSS With Tailwind” (Ebook) (Amazon). If you’ve already read and enjoyed either book, I would greatly appreciate your help by giving a rating on Amazon. Thanks! In my last post, I refactored the status field for cards in my project tracker to a more object-oriented representation that used value objects and classes to replace conditionals throughout the code.

If you’ve been reading this newsletter for a while, you’ve may have noticed there are two patterns I talk about all the time: We’re doing something because everybody does it but we don’t know why. We’re doing something, but we don’t really believe in it so we’re doing it halfway and not getting any benefit. Object-Oriented Design often hits both those patterns – teams use OO languages for various reasons without thinking about what OO can do for them, and then teams don’t use OO design or programming tools in a way that can help them achieve their goals.

A long time ago, I studied research on what makes successful engineering teams. (Not programmers, other engineering fields). I don’t remember a lot of it, but one phrase stands out: “preserving ambiguity”. Successful teams don’t make decisions that aren’t needed, and they don’t get themselves locked in too early. One fact about the beginning of a project is that you know less about the project than you ever will. And yet teams are often asked to provide estimates, do architecture, and make long-ranging plans at the beginning of the project when it is guaranteed that some of the assumptions will be wrong.

Previously on Locally Sourced: I wrote about building a small feature in Hotwire. Also, I have two, count ‘em, two, books for sale. Modern Front End Development For Rails (ebook) (amazon) and Modern CSS with Tailwind (ebook) (amazon). I have this idea that teams get in trouble when they do something that they are “supposed to do” without understanding what problem they are trying to solve and what tradeoffs they are willing to make to solve it.

Previously on Locally Sourced: The Tailwind book is out. Buy it in ebook or at Amazon. Modern Front-End Development For Rails is in final layout and headed to the printer. This post will make a lot more sense if you’re familiar with Hotwire If, for example, you bought a book about it… Simplicity is Not Simple To the extent that I have a guiding principle of software development it’s this Alan Kay quote:

Previously on Locally Sourced: About a year ago, I started this newsletter with a bunch of posts that I originally called XP 2020 and later called Entropy Essays – you can find all the posts here. I got bogged down and never got to the punchline… There’s a common thread in the story of how testing, object design, and pair programming have been adapted since XP and Agile became buzzwords. I think estimating fits here as well.

After writing about one kind of contrived sample code, I want to write about a different kind: the kind that is part of an interview process. A disclaimer right up top: I do occasionally evaluate coding samples for Root, but I did not design the current coding problem, nor did I design the metric that is used to evaluate solutions. Nothing I say here should be taken to imply anything about Root’s interview process.

Previously on Locally Sourced: I said this one would be about interview code, which it isn’t. Next time. Meantime, the live home of this newsletter is https://buttondown.email/noelrap, where you can subscribe for free, or for money if that’s feasible for you and you are so inclined. Thanks, and tell your friends! People have been asking me quite a bit recently whether I would choose Hotwire or React for a project and what role each has in the web ecosystem.

I’ve been going back and forth about what to put in this newsletter about Modern Front-End Development For Rails. On the one hand, it’s a big deal for me, and it’d be great for me if people bought it. On the other hand, you’ve likely heard me talking about it for a year and you’ve probably made up your mind. (If you haven’t, would you consider buying a book?) I did realize I had a weird, niche topic about the book that I wanted to talk about.

If you are reading this, then I did at least one thing right. I’ve moved this newsletter to new provider called Buttondown. Ideally, this will not affect you at all. (You may have gotten a request to re-confirm your email, if so, that was my mistake.) For me, it gives me the ability to write in Markdown, with code syntax coloring, an API that I might use at some point, and somewhat better financial terms for what is, let’s face it, a tiny email list.

How We Don’t Know What We Know Previously on Locally Sourced. Who can even remember? Sorry, it’s been a while. I’ve been stuck writing two-thirds of posts and not quite wanting to finish them, but if you are reading this, I assume that means that I finally ended this one. In the meantime, I’ve sold a book-shaped object to Pragmatic that will be about Tailwind CSS. It’s part of the Pragmatic Answers line, which means it’ll be short, and it’s what I’m doing to keep me busy until the Stimulus book is releasable.