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.
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.