Acts as Conference - Day 1
February 8, 2008
The first day of Acts as Conference is in the books. I’m not going to give a full summary of each presentation, just a couple of highlights that I remember. The first thing is that I won the Engine Yard 3 slice configuration for one year giveaway! I’m super excited about that, but as everyone said to me throughout the day “What are you going to use it for? Something good I hope!”. I think I’ve got an idea for something good, but we’ll see.
Next up was Evan Phoenix. He gave a talk about Rubinius, which I believe, as do many others, is the future de facto ruby interpreter. More than just that, it will open up a world other world of possibilities.
Although I love the idea of Rubinius, the most interesting parts of Evan’s talk weren’t about Rubinius specifically. First, he talked about how sometimes when you are banging your head against the desk trying to come up with the best solution for some complex problem, the best thing to do can be put on your iPod and take a walk:
The unconscious mind is a better problem solver than the conscious mind
That’s a good quote. The other point I took away from his talk is his philosophy about how to build a vibrant community for an open source project. For Rubinius, his idea has been that any person that commits even the smallest patch gets commit rights. The idea is that you want to “hook developers in with a small patch”. Once you get them in doing small things, they will feel like it is fun and they are invested in the project and they will go on to contribute more substantial features.
Evan and Ezra’s talks got me motivated to get involved. During lunch I discovered and reported a small Merb bug and then submitted a patch for it, which was accepted and merged in. Michael Ivey’s “So you want to contribute to Merb” article was very helpful in figuring out how to get involved.
After that was Neil Ford’s presentation on Advanced DSLs in Ruby. One neat technique I picked up from this is how to use
instance_eval to remove repetitive calls to an object. Say you have this:
class Foo attr_accessor :foos def add(s) @foos ||=  @foos << s end end foo = Foo.new foo.add "bar" foo.add "bang" foo.add "baz" puts foo.foos
To avoid calling foo mutliple times, you can refactor that out like this:
class Foo attr_accessor :foos def initialize(&block) @foos =  instance_eval &block end def add(s) @foos << s end end foo = Foo.new do add "bar" add "bang" add "baz" end puts foo.foos
It seems contrived in this example, because it is, but this can definitely be useful when creating internal DSLs.
I liked his definition of internal vs. external DSLs. Internal DSLs are DSLs that you write on top of a host language, like Ruby, whereas an external DSL is a DSL that is parsed, meaning you take a string, parse it and then do something. Based on that definition, I don’t like the terms internal and external DSLs because of the implications that come along with that. I think the terms “Hosted” vs. “Parsed” DSLs would be much clearer. Just because it’s an internal DSL doesn’t mean that you can’t expose it to end users. The whole point of a DSL is to allow end users to define things like business rules. Neil’s opinion is that external DSLs can be more flexible, but are usually harder to develop and evolve, but there are tools coming out to make that easier, so keep an eye out for that.
The next talk was Luke Francl. Someone asked him a question about pair programming and I think he had a good point, which was that pair programming stops developers from goofing off. The example he gave is that when you are programming by yourself, you might say “I’ll take 5 seconds to check out Reddit”, which inevitable turns into 5 minutes. You’re not likely to do that with someone else sitting right next to you. It’s true. I think a thing to add is that pair programming acts as real time code review. In my experience, code review never happens, so pair programming is good way to get that. It is also a good way to get developer buy in. Sometimes you might have a developer create something by themselves and then another developer sees it and says to themselves “WTF, why would he do that this way!”. If you are there when the code gets written, you wil have a discussion with the developer, so you will have that understanding, or possible have a better way to do it.
Lastly Dan Benjamin wrapped up the day with a talk about simplicity and focusing on the user experience. It was a nice talk to cap off a day of technical talks. I’ll definitely be thinking more about simplicity and the user experience on my upcoming projects.