Noel Rappin Writes Here

Tag: object-oriented

Another Refactoring Story: ActiveRecord Lists

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.

More Ruby Magic

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.

Refactoring, Part Two: In Defense of Magic

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.

An Object-Oriented Example

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.

Object-Oriented Design from the 90s, or more on Domain vs Technical Modeling

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.

Another Entropy Essay #3: Flavors of Object-Oriented Design

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.



Copyright 2024 Noel Rappin

All opinions and thoughts expressed or shared in this article or post are my own and are independent of and should not be attributed to my current employer, Chime Financial, Inc., or its subsidiaries.