Yesterday I wrote a write up of eRubyCon 2008 Day 1.
– Charles Nutter started up with JRuby. I’m always impressed by people that are able to make their weekend project their full time job. I was further impressed that Charles was up with the rest of the speakers until closer to 4am than any of us should really admit, drinking really good scotch and solving the world’s problems.
Charles talked about the JVM and Java as both a problem and a great asset. There are a lot of people that look at the J in JRuby and automatically associate it with all of the things that they don’t like about Java. Charles answer is to separate the JVM from the Java language. He did a really good job of talking about the things that the JVM brings over the standard Ruby runtimes such as world class garbage collection, memory compaction, thread handling and the like. He did a number of really compelling demos around threading in particular. One of the things that he said here is that JRuby and IronRuby are really the only Ruby implementations that are able to do native threads because they are the only ones that are built on production quality VMs that handle that native threading for them.
One of the great quotes was “We write a lot of Java. So you don’t have to…” – Charles Nutter
After setting the stage, he pulled up a long list of features and said – “There’s way too much for me to cover in the time left – what do you want to see?”. that was fun. The first suggestion that he showed was 2D graphics that flashed a bunch of little balls around the screen. It was even responsive to voice commands. The second suggestion was to show Rails running on JRuby. He showed that they are running Rails on Ruby 1.8.6 (java). Next he brought up image_voodoo to do more 2D libraries. Lastly, he showed “java_inline” which allows you to inline Java code similar to the Ruby_inline which allows you to inline C right in your Ruby code.
– Evan Light came up next. Unfortunately I was putting out a few small fires. Fortunately Michael Lettere wrote up a small write up so that I could include it here.
Evan Light hates EJBs.
EJB encourages difficult to test idioms, private fields, private static final fields.
Nice demo code “public class DeepThought” <— How do you test that?
You COULD shoot the guy who wrote it, but don’t do that.
Very good use of humor, engaged the audience.
– The lunch keynote was Neal Ford. Neil Ford is an amazing speaker. What’s cool about him is that every time I see him speaker, I wonder how he could get any better. And then he does. Today’s talk was about complexity. One of the core concepts that he talked about is the idea of Language Lockdown. It’s when language writers put in features to protect people from themselves and cut down on the stupid things that you can do. The idea is that if you do that the lower end (read cheaper) developers will still be productive. “What they are trying to do is strap a rocket to the ass of a turtle. What they are actually doing is putting chains on the rabbits than can go fast.”
The problem with that take though is two fold. First, it is not a linear line between the top developers and the lower end developers. What that means is that on the curve, a highly productive programmer will get done in one day what it will take an average developer more than a week to do and the weak developer a month or more. To point out the second issue, Neal quoted one of my other favorite speaker – “Bad developers will move heaven and earth to do the wrong thing” – Glenn Vanderburgh
One of the huge questions that he put out there is “How much of your enterprise software simple services accidental complexity?”. It’s a great question.
As he was wrapping up, he left us with the thought that “Courage is contagious. Cowardice is infectious”.
– Following Neal was Stuart Halloway again. He was talking this time about how one can fail with 100% test coverage. It’s an interesting topic because for so many people, 100% test coverage is the holy grail that they shoot for. The first thing that he pointed out is that you might cover all the lines, but not all the branches so it depends on how you measure things to get to 100% coverage. The second thing that he points out is that you can cover all the code, but not all the corner cases. The example that he used is testing if a value is above or below $25.00 but forgetting $25.00 even. Oops. Then you can start writing way too much code and too much complexity into your tests. Now you need to test your tests and you’ve taken too much time writing them. Then he talked about the “ugly mirror” where the test is really a mirror of the code where you’re covering the line but using the code that you are trying to test while testing – oh dear I have a headache. This is where he says that you are allowed to write literals in your tests.
Neal Ford piped in – “It’s ok for your test to be moist, not drenched”.
The next topic was slow tests and how dangerous they are. The short version of the issue is that if the unit tests don’t run in under 1 second, developers are not going to run them. Functional tests should run in under 2 minutes. If they don’t, then factor them so that they run on different schedules, parallelize them on different machines to get the normal check-in process back under the 2 minute mark if possible.
The last type of fail that he talked about is shallow tests. The quote that he referenced is “No automated test suite can ever replace exploratory testing.” – Jay Fields. The goal is that once the unit and functional testing passes, that people will put themselves in the clients seat and go spelunking and try out a bunch of stuff.
– The next talk was a very unique idea called “Dialogue Concerning the Two Chief Modeling Systems”. They wrote a play! The guys from EdgeCase, Joe O’Brien, Jim Weirich and Chris Nelson, acted out a normal project for them. They started out on twitter talking about the new project that they just landed. Then they actually started with the early on meetings that they have. Joe played the cowboy dev lead who insists that it’s a “simple rails app” and decides to do a data first model. Chris played clueless nub and Jim played the seasoned architect that was concerned about requirements analysis, separation of layers and behavior driven models. Joe, ready to start slamming code out, starts pairing with Chris. The first thing that they tackle is a simple calendar event. Then they have to schedule r
eoccuring events. Joe, the cowboy, just decides to replicate the events in order to do the reoccurence. The next requirement is rescheduling the reoccuring meetings…. Oops. They have neatly coded themselves into a corner and start hacking out a solution. At that point, Chris decided to take a walk and went to see what Jim thought of it all. Jim started writing out CRC cards and started thinking about higher level ideas, bringing in light-weight design patterns around temporal expressions from Martin Fowler and so on. Jim, the architect, is blithely ignoring “implementation details” such as where to store the data and performance. When performance sucked – they went back to the drawing board. Jim and Joe had to eventually come together. Of course the answer was to write a DSL… 🙂
Great talk. The good news is that Neal Ford is following them so there won’t be a let down as we end the day…
– The last talk of the day was Neal Ford talking about Design Patterns in Ruby. One of the things that he pointed out fairly early on is that the Design Patterns book, even according to one of the authors ( Vlissides), should have been called “Making C++ Suck Less”. Even the Smalltalk that’s in the book was really C++ written in Smalltalk syntax. He covered a number of different patterns including the Iterator and the Interpretor pattern. There were a number of circumstances where he pointed out that the issues addressed by the pattern were addressed by the Ruby language. For example, the interpretor pattern’s intent is really addressed by DLSs which are dead easy to implement in Ruby. The only problem with this session is that it’s at the end of the day and my brain is a little mush at this point.