POODR Book Review

Practical Object-Oriented Design in Ruby by Sandi Metz is on the short list of excellent software development books I have read. It falls into a very nice place of being a great book on OO Design, plus some interesting ruby tips.  I would recommend it for non-ruby developers who would like to see some great step by step OO design via refactoring.  The book is an easy read due to the fabulous conversational tone Sandi uses, and the examples feel just complicated enough to make her points without being too simple.  It feels like a book I’ll read multiple times between the ease of reading and the wealth of good information.

The top 4 items I found interesting in the book were:
1.  In chapter 3 (Managing Dependencies), the section that lists basic types of dependencies was eye-opening.  I would not have thought of parameter ordering as a dependency due to my background having more hours of programming in statically typed languages.   The solution was obvious (a hash of arguments with keys for each parameter), and one I have used in the past.  However, I know in some of the fun projects I have done this became a small pain point for me that I never naturally made this jump to, but now feel like a fool for not doing so.
2.  In chapter 4 (Creating Flexible Interfaces) the discussion of the Law of Demeter was interesting.  The caveat around list manipulation in ruby was the point I found most interesting.  The caveat was around code like hash.keys.sort.join(‘, ‘), which are common ruby style, and is clearly a violation of a “strict” interpretation of Demeter. Sandi appropriately points out that at best this is a light violation, and trying to avoid the violation will likely have higher cost.
3.  In chapter 8 (Combining Objects with Composition) the discussion of Inheritance vs Roles with Modules vs Composition was superb.  Is-a, behaves-like-a, and has-a are simple concepts, but Sandi explains them very well.  Roles using modules is not in the classic OO inheritance discussion, but clearly for ruby it is a  powerful techniques of code reuse.
4. In chapter 9 (Designing cost-Effective Tests) the discussion of testing of class hierarchies using test modules was very education.  The whole section on testing is great (and see her talk about the testing to get a feel for most of the chapter), but the testing of interfaces is superb.  It is another item that seems obvious in retrospect (use a module to test that a class supports the expected interface), but was new territory for me.

Overall, I loved the book and highly recommend it.  Anyone who has interest but is not sure might want to read this review or listen to the Ruby Rogues podcast on this book.


Linkfest 2011-06-05

A quick set of links I’ve enjoyed recently.

How Facebook pushed new code live
I was going to link right to the Facebook video. However, this blog does a far better job of summarizing than I would.  The culture of technical excellence and responsibility is what stands out to me. I found the PHP compiler and BitTorrent aspects especially interesting.

RailsConf 2011 Video Playlist from O’Reilly
There was a post by Peter Cooper live blogging DHH’s keynote at Ruby Inside, which took me to the full play list. DHH is aways interesting to listen to, and this talk hits a lot of highlights of Rails 3.1. I also enjoyed Aaron Patterson’s, though that is as much for the dancing as the presentation. I had not heard of Code For America, so Dan Melton’s talk spawned some research. Honestly, every video I watched gave me something to think about and is making me thing more seriously about getting to some Ruby conferences.

Ruby Rogues Podcast
After not listening to a software podcast in a couple of weeks, this one has me hooked. The podcast has several Ruby contributors I recognize as panelists. Having a decent focus and a solid moderator lets the panel style work. Listening to smart and energetic people talking about something they enjoy is just a good experience. Having recently read the Pragmatic Programmers RSpec book, the discussion around it and Cucumber in the first episode was great. Doing a quick review of the list of podcasts, the first four I have listened to have all been excellent and given me things to think about.

Linkfest 2011-05-18

A quick set of links I’ve enjoyed in the past month.

Lunch – at Joel on Software
Good thoughts on one way to help keep a team, even a partially siloed team, more connected. This post was the straw that broke the camel’s back and prompted me to schedule lunch with our whole development group once a week. The group lunch is something we used to do, but have gotten away from. Some of the developers had mentioned that the team was feeling fragmented, so I’m using this as one way to help. I do not know if this will bear fruit by breaking down barriers, but at least once a week the we can all eat away form our desks and have some social interaction.

Working effectively with legacy code
This post has four things going for it. First, I like this blog and the book written by the author (though I still need to finish it). Second, I really like the Michael Feathers book the post references. Third, I was able to point one of the developers working at my company at this post to give him some ideas as he attempts to add unit tests and tries TDD on a code base he wrote about a year ago. Last, it is a good well written post.

The Hot/Crazy Solid State Drive Scale
During the past 6 months I have been thinking about purchasing a SSD, and this gave me some pause. The post also gets bonus points for referencing a TV show that I enjoy. Buying a SSD is not in my near term future, but I’ll keep this one in the pocket if I do it any time soon.

Rails for Zombies
This was a really good beginners tutorial on Rails. I found it enjoyable and fun. Did it turn me into a real Rails developer? Not even close. Did it give me a basic framework and understanding to spring board me into doing Rails development? I would say yes. Have I been able to leverage that? Unfortunately, no.

Initial Thoughts On Git

Four years ago I moved the development team at my current company from Visual SourceSafe to Subversion. I had been using SourceSafe at my current company and a previous employer for about ten years total.  Our SourceSafe was at times painfully slow, and I knew of some of the issues SourceSafe had with possible data corruption. At the time I was reading a several books from the Pragmatic Bookshelf, so picking up “Pragmatic Version Control with Subversion” made sense.  There were two core improvements I was looking for.  First, I wanted a product that could handle merges better from the start the SourceSafe. Second, I needed something that would work in both a Windows and Unix environment, because our Unix code badly needed source control.  To me Subversion made perfect sense, and seemed like the best option at the time.

Another developer mentioned Mercurial, and I spent a little bit of time researching it.  I recall having a hard time understanding how a distributed version control system made much sense.  I saw the central repository being the core feature in a VCS, and had not read enough to really understand how distributed version control really worked.  In retrospect I can also see that since most of our projects were solo projects, some of the core advantages of being distributed would not have been realized.  I also doubt I could have gotten my boss at the time to buy into using a distributed VCS.

Over the past several years, Git started to show up on the blogs I follow with more and more regularity.  When the Pragmatic Bookshelf had a sale in November of last year, I decided to pick up “Pragmatic Guide to Git”. This month I finally managed to crack it open, and run through the fabulous Git Immersion site by EdgeCase.  I have some initial thoughts on Git as compared to what I have used in the past.

The first thing I like is that tagging makes sense. Subversion’s paradigm of making a copy always felt a little off to me. This is much cleaner in Git, feels more natural, and seems like it will be easier to understand.

The second thing that interests me is the flexibility. If you want to run it as a centralized version control system it is possible. Individual developers would still have the option to use all the features that Git brings to the table.

There are some advantages that come from being a distributed VCS.  There is the obvious advantage of being able to work offline.  Easy integration with offshore resources is a possible huge win.  I had a moment last week where I thought how much simpler something we were doing would have been if we were using Git with an offshore resources.

Git seems to remove some of the friction that I felt when I was setting up Subversion for some solo projects.  In place branch switching and two stage commits seem useful, but I won’t know how useful until I’ve had a chance to use Git a little more.

Overall it seems as though Git (and other distributed VCSs) are source control for the developer.  It gives the developer a lot of power to easily create experimental branches on their code base.  It allows them to have a ton of small commits, and then share them back to the master with less friction for the other developers.

For my current company, Git seems like a less than optimal fit.  We don’t have large enough teams to get much advantage of the merging and distributed nature. I would not have a problem with someone using it to supplement our central control system (right now transitioning to TFS to leverage work item tracking in TFS).  This is especially on the Unix side, and I would want to evaluate using something like Git-TFS bridge as well.