Hello, I wanted to start out by paying my regards to the family/friends of Jim Weirich. Although I never met this gentleman, he has undoubtedly been a pillar in the Ruby community and probably other language communities as well.
I remember when deciding to switch from PHP, that I saw a video of him programming robots in Ruby. His videos on the topic helped make the fairly easy decision of jumping into Ruby even easier, and I know for sure that I’m not the only one he has positively influenced in this manner.
Well, I’m finally starting to remove some of the fog as it pertains to interfacing with external APIs from Rails. I’ve also been tasked to research into some topics associated with building the logic of a request/response cycle when communicating with an external API. The topics I’ll be reading and sharing about in the future include:
I haven’t yet had an opportunity to look into the decorator/adapter patterns yet, but when I do (sometime this week or weekend), I’ll be sure to write a post on them.
Separation of concerns
A concern can be considered as a component of focus in a program. Typically this can be synonymous with features or behaviors of a program.
Separating concerns in a web program will provide benefits, such as making our code easier to add features to, facilitating reusability and ensuring maintainability of a system among other things.
Sandi Metz talks about this thoroughly and descriptively in her book Practical Object-Oriented Design in Ruby. And I’ll tell you what I like about books like Sandi’s. Whenever I allow a little time to pass between the reading of some chapters in her book, without fail I have experienced small epiphanies on how to relate her authored guidance to directly improving the way I think and ultimately write code. When looking to better understand how to keep my program’s concerns separate, my thoughts resonated first on chapter 2: Creating classes that have a single responsibility.
Here are a few additional resources that helped me put things in perspective:
- Separation of concerns vs. Single Responsibility Principle
- Separation of Concerns: The most important principle in software engineering
- Ruby Best Practices Post on SOLID
- A stack-overflow on the topic
Separation of Concerns & more
With the information about these new topics that Adam has presented me, I will attempt to build a modular concern for handling communication with zesty.com.
Here is my airpair today with expert Adam Cuppy.