This is my third year at eRubycon. I’m thrilled to be involved and speaking again this year. I’m shocked every year when Joe picks me as a speaker. I’m just honored to be considered worthy of speaking on a docket with Jim Weirich, Glenn Vanderburg, Leon Gersing, Charles Nutter, Randall Thomas, Neal Ford and all of the rest of the amazing speakers that are here. It’s definitely one of my can’t miss conferences every year.
Joe O’Brien does a great job putting this conference on year after year. The logistics are smooth, the talks are great and the vision for the conference is crystal clear.
SOLID Ruby
Jim Weirich started off the day with a talk called “SOLID Ruby”. The whole talk is already up on github at http://github.com/jimweirich/presentation_solid_ruby. Jim is not only very informative but fun to listen to. I really like his delivery and sense of humor.
The first question that he asked is “How do you recognize a good design?” One of the things that Jim points out is that most people can recognize a bad design but we can’t describe what makes a good design. This is actually quite profound. How can we ensure a good design if we can’t describe what makes one? To demonstrate his point, he talked about the 1666 London fire and the subsequent plans to rebuild the city. He talked about 4 to 6 very distinct designs that were all presented to the king at the time. They actually didn’t build any of designs but rather did the first ever agile project with an incremental build and no huge design up front.
SOLID
S – Single Responsibility Principle (SRP)
O – Open Closed Principle (OCP)
L – Liskov Substitution Principle (LSP)
I – Interface Segregation Principle (ISP)
D – Dependency Inversion Principle (DIP)
SRP – Each class should have one and only one responsibility. You should be able to describe what your class does in a single sentence without using the words “and” or “or”.
OCP – You should be able to change the behavior of a class without having to modify it. This is the basis of inheritance. In Ruby, you can just open a class and “Fix it” right?
DIP – Jim took this one out of order because it made ore sense when trying to explain things. Depend on abstractions, not on concretions. In static language such as Java, C#, C++ it meas that you develop to interfaces. In Ruby, you don’t have to do that as there are no hard references to classes so you can swap out classes at will. If you want to swap out the class, you just have to have all of the methods that the code that leverages that class call. Jim calls this coding to a protocol verses coding to a spec or interface.
LSP – the question answered here is how do you know if you can swap out two classes? The reality is that it’s more than just are the methods require present. It’s what are the promises back as well. For example, if you have a square root function but you require a certain level of precision. From the LISP community, Jim pulls the phrase “Require No More, Promise No Less”. If you are well covered on testing, this will be automatic.
ISP – Make fine grained interfaces that are client specific.
To finish up, Jim opened things up for discussion but in traditional Jim fashion he did things a little different. He brought the questions for the discussion.
First question – “ActiveRecord objects implement a domain concept and a persistence concept. Does that break the SRP?”
Next question – “How do you verify that your client software only uses the (narrow) protocol you expect”?”
Next question – “Some SOLID principles are an awkward fit for Ruby as they were built for static languages. Are there design principles from dynamic languages that are awkward fits for static languages?”
One of the key points that Jim implicitly made is that Ruby the language auto-implements many of the SOLID principles and the the culture pushes the rest of them in great ways.
Testing the Enterprise
I was really sorry but I had to miss this talk. I’m planning on getting a summary from the speakers later tonight and posting some notes later. They posted their slides at http://fallenrogue.s3.amazonaws.com/Testing%20the%20Enterprise.pdf.
In short, Leon Gersing and Charley Baker have been working at the Gap on a large project. A big reason for the success of the project and the team is the rigor around testing.
I asked Leon to email me a short write-up and this is what he sent me:
+++++++++++++++++++++++++++++++++++++++++++++++++
“Testing the Enterprise” is about how we brought Ruby testing into Gap Inc Direct. GID has campuses in Columbus, San Francisco and offshore. In addition to the challenges in a distributed environment, training QA resources and developers new to Ruby, Watir, other libraries; we’ll be talking about incremental adoption of Ruby in the Enterprise, and how it enables us to move from a Waterfall SDLC into an Agile model.
We’ll be going over lessons learned, pitfalls and successes. The points of view will be from Leon Gersing, who has been responsible for the adoption of Ruby at our San Francisco campus over the past 4 years, and Leon Gersing from EdgeCase, who’s working with our Columbus distribution IT organization as they adopt Agile practices and using Cucumber have bridged the gap between developers, QA and product teams.
+++++++++++++++++++++++++++++++++++++++++++++++++
Rails in the Large: How Agility Allows Us to Build the World’s Biggest Rails App
Neil Ford came in next and talked about the largest Rails applications known to man.
The application itself is a car wholesaler web site called http://ove.com. He started out talking about how the project came about in the first place. They had a huge complicated web site built in Java. They were looking to do a ground up rewrite in either .NET or Rails.
Neil asked them “There are 300 Java developers downstairs, why don’t you want to rewrite it in Java?” The answer was “Frankly, we don’t want them to touch it.”.
Neil convinced them to go with Rails.
They started out in January of 2007 and built the team at 1 new pair of developers to the project every two weeks. At this poin
t they have 11 pairs of developers, 8 business analysts, an iteration manager, 6 quality assurance, a project manager and a client principle.
One of the key points that Neil made here is that “technology isn’t as important as responsiveness to business needs”. There are a lot of people in the technology world that don’t get that. The reality is that most customers don’t care about what the underlying technologies are, they only care that their business requirements are met.
One of the things that Neil pointed out very strongly, and actually spent a lot of time talking about, is the importance of the testing and specifically the way that they did them. One of the interesting stats that he threw out is that they have 3.2 lines of test code for every line of production code. There’s currently close to 100k lines of test code.
Obviously, this is a lot of code so they have had to pull together a number of other resources and tools to put together to actually run all of the projects. One of them that struck my fancy is DeepTest. It can do distributed testing of your Ruby code. Another one is Selenium grid. This does distributed running of Selenium tests.
One of the side effects of all of this distributed testing is that they have no setup and tear down methods in the tests. Rather all of the tests are completely standalone.
There were a number of social engineering things that they did that were very successful. They have a theme song for broken builds and theme songs for each person that plays on a successful check ins.
Agile, Rails and the Cloud: Why companies can’t afford to ignore the efficiencies of modern development approaches
Ian McFarland finished off the day with a talk about why modern development approaches matter to business. This is a very important thing to talk about and think about for businesses. The reality is that not nearly enough people spend time considering.
He started talking about Agile development and walked through many of the core tenants. He put forth fairly compelling arguments that you really do need to follow the tenants of Agile. For example, having the customers setting the priorities on the things that you are building matters because it helps you produce business value faster. He spent quite a bit of time arguing that you really do need to do paired programming. Everyone learns more faster, gets distracted less and the team knowledge goes up dramatically.
After that, he switched to talking about Rails. He’s got data that switching from Java to Rails proved out to have have 2-4x productivity gain for the developers.
Then he talked about the Cloud. To steal words from Brian Prince to help paraphrase Ian’s thoughts here – “Don’t be a plumber!”. Unless it’s critical to your business to run your own infrastructure, you should outsource the infrastructure. Actually, he made a strong argument that you should outsource a number of things. As I’ve said for a long time, if it doesn’t add to your companies stock price, why are you building it? There are times that you have to run your own infrastructure such as regulatory issues or business needs that make it more advantageous to have it internal.
At the end, he made a very contentious statement that Rails is not ready for the Enterprise. There are a number of reasons for this and mostly it comes to the fact that Enterprise is actually not ready for Ruby. The actual barriers are being solved. For example, companies such as Engine Yard are solving cloud issues and the like.
Now for dinner – more tomorrow!