Noel Rappin Writes Here

Most human communication, text or written, is wordier and more redundant than it needs to be, strictly speaking. That previous sentence, for example, would still communicate its point in about a third of the words with “Most human communication is too wordy”. You’d likely still get the idea if I used about half the characters and wrote: “hmn comms too wrdy”. There are certainly reasons why you might include words when speaking or writing that are technically not needed:

This is a quick bit of service journalism about one thing that seemed less than obvious about converting the code in Modern Front-End Development For Rails to Rails 7.0, namely how to integrate TypeScript with the new tools. Specifically, the Rails 7.0 version of the code ditches Webpacker in favor of the new jsbundling-rails and cssbundling-rails gems and uses esbuild instead of webpack. See here for an only-slightly out-of-date description of the new tools.

Jessica Kerr wrote a very interesting post on bell curves and engineering teams. Jessica’s point is that bell curves are for random distributions, and that when teams share information and learn from each other, they no longer can be modeled by a random distribution. I think this as true, and a valuable insight. It reminded me of a different, related observation about teams and bell curves. Back in the 1980s, when he was applying analytics to baseball teams, Bill James argued that a common feature of the decisions made by poorly performing organizations was the assumption that baseball talent was normally distributed and could be modeled with a bell curve.

I’ve now tried to write this post like three times, and one thing that’s clear to me again is why you don’t see more write-ups of even moderately complicated real-ish problems. It’s hard to get enough of the context across to make the code sensible without being overwhelming. But there’s a Rails and ActiveRecord structure that this example gets to that I think is useful, so I’m going to try again.

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.

Or: Rails and JavaScript, Part 5 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! If you are really interested in how we got here, I wrote about the history of Rails and JavaScript, read Part 1, Part 2, Part 3, and Part 4.

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.

You don’t need me to tell you that 2020 was a weird year, and that definitely showed up in my reading list. For a long time mid-year, I really shied away from anything that was dark or challenging. Still, I somehow managed to read books this year, and I managed to put together a list. Eventually, I mean it is April 2021, which is a little late for a Best Of 2020 list.

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.

Previously on Locally Sourced: It’s been quite a while. I’ve been very focused on finishing the big update to the draft of the book. Which I have done, giving me a bit of a breather until the technical reviews come in. I’m hoping this means I’ll be getting this newsletter out more frequently. I was looking back over the past newsletters, which I do from time to time to prevent repeating myself, and I realized that I had promised two posts from talks that I felt never got a wide audience and only delivered one of them.

Previously On Locally Sourced: I wrote about Hotwire and Turbo, the Rails client side New Magic. Then I wrote about them again. I think you are all caught up. I’ve been writing about Hotwire and Turbo, and haven’t said all that much here about Stimulus. Which is a tool that I like so much, that after using it on a project, I literally decided to write a book so I could tell more people about it.

Previously On Locally Sourced: I wrote about how to use Hotwire and Turbo. (My Mac keeps wanting to autocorrect that to “Hot-wire” for some unknown reason…). The update to Modern Front-End Development With Rails is ongoing, the book is available for beta purchase if you want the new stuff as soon as we can get it to you. After writing a post a couple of weeks ago explaining how the new Hotwire framework works I want to spend some time explaining what I like about it.