A few of my articles have caught some attention or challenged ideas and I thought you might like to read them.
Take a read through these articles and let me know what you think about object modeling and understanding and building your tools.
Developers and teams that understand their tools will be better able to choose the right ones. They'll make better decisions about when to avoid existing tools and when to build their own.
Take a deep dive into Ruby's standard library Forwardable. Use this article to get to know how it's built and how it works. Take lessons from the code and use them to decide when and where to use it or write your own. Alternatively, another good library to know is 'delegate' and I dove deep into that one too.
Enforcing Encapsulation with East-Oriented Code
Responsibilities can explode in our programs without us ever realizing exactly how it happens. Before we know it, we've got a mess of interconnected objects that know too much about each other. With an approach called East-oriented Code (coined by James Ladd), we can create objects which enforce their responsibilities and make sure that you tell, don't ask. If you're interested in seeing more about it, check out my presentation from RubyConf and of course I wrote something for functional programming and immutable data afficionados: Commanding Objects Toward Immutability
How I fixed my biggest mistake with implementing background jobs
Distractions are an enormous problem for every software developer. This article doesn't solve all of them but it (and the others in the series that follow) shows one way to keep me focused on the problem at hand.
Walk through building a tool to remove distractions from your code. I pull from my own projects to show how I try to make a short a step as possible from deciding when to run code in the background.
The Gang of Four is wrong and you don't understand delegation
When I began researching earnestly for Clean Ruby I regularly came across references to Object-oriented programming about "delegation." What I found is that we tend to use this term to mean something entirely different than what it is.
Misunderstandings lead to frustration and bugs.
To make sure I understood it correctly, I spoke with Henry Lieberman creator of Self, a language which created the delegation concept. I followed it up with more research and contacted object modeling pioneer Lynn Andrea Stein who wrote that "Delegation is Inheritance" when I then wrote Delegation is Everything and Inheritance Does Not Exist