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.

First off, Ezra gave a talk on Merb. It was mostly a repeat of stuff for me, although it was good to hear some of the ideas about the refactoring towards a 1.0 release.

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

foo =
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
  def add(s)
    @foos << s

foo = do
  add "bar"
  add "bang"
  add "baz"
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.

Next up was Peter Armstrong, who talked about getting Flex/Air to work with Rails and how he is working on a framework called Ruboss, which is a simpler alternative to Carnigorm. Personally I don't think I'll be doing any Flex-related stuff in the near future, I'll probably be looking into ExtJS to try to create a rich user experience. I don't like the idea of writing code in ActionScript and then compiling it. I'd rather either write code in JavaScript or have the option of generating the JavaScript dynamically with a "hosted" DSL written in Ruby.

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.

Posted in Technology | Tags Merb, Ruby, Rails



Thanks for the summary, Paul - sounds like it's going great so far!

And yes, those of use who couldn't make it are jealous.

# Posted By Ben on Friday, February 8 2008 at 9:17 PM


Thanks for posting this. I'm still working on overcoming my fear of flying, and could not attend this year, so your summary is very useful.

I like the idea of calling them "parsed" DSLs, but I'm not sure how the term "hosted" applies to the others; can you clarify?

# Posted By Joe Grossberg on Saturday, February 9 2008 at 12:00 PM


A hosted DSLs is one where you just use the syntax of the host language and it just looks readable. Here's my attempt at a hosted DSL, similar to the one Neil showed during his talk. Ignore the ugly, semi-working implementation at the top, check out the "API" at the bottom:

# Posted By Paul Barry on Saturday, February 9 2008 at 3:59 PM


Thanks for sharing! It's good to see (read) what's going on when not being able to be there...

# Posted By Joseph Hsu on Sunday, February 10 2008 at 12:21 AM

Comments Disabled