Noel Rappin Writes Here

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.

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.

Maybe more about the past than you needed to know? Previously on Locally Sourced: I wrote about kinds of object-oriented design. Before that, I asked why you hired that test. I didn’t exactly set out to write 1300 words on the history of OO design, but I pulled out some old books and got nostalgic. Tune in next week for more on Agile, communication, and inclusion. As I was writing the last post, I started skimming through a couple of my Object-Oriented textbooks from the mid-90s.

Who doesn’t love a taxonomy? Previously on Locally Sourced: We talked about test speed, and we asked why you hired that test? If you like this kind of thing, tell a friend or colleague. One thing that I see a lot in online discussion of programming styles is the idea that Object-Oriented Programming is just one thing that you either do, or don’t do. I think that’s reductive, and not just because different languages encourage different structures in objects.