Nick Sieger: Tag rubyconf2007

RubyConf Day 2: Morning Sessions

2007-11-04T02:12:00+00:00

John Lam: IronRuby

Why IronRuby? John started with RubyCLR, which was a bridge between two languages/environments (.NET CLR and Ruby). Last year he didn’t know he’d be uprooting his family from Toronto and moving to Seattle. Now he finds himself in Microsoft trying to make sense of his new position. He describes a number of higher level goals for himself and IronRuby at Microsoft.

Change or die. Involvement in open source can only go up, right? The challenge is that the company is already doing well, so it’s hard to convince middle management that anything should change.

Open source. To their credit, the IronRuby team appears to be on the leading edge of open source at Microsoft (c.f Microsoft Public License). They also had planned all along to take external contributions, and have in fact started to receive them

Rails. One of the key goals is to be true to the language, and that includes being able to Run Rails.

Performance. Use IronRuby as a testbed for DLR performance testing.

John is showing the REPL now (running under Mono actually), pointing out that “integer math is now supported” (apparently early on someone pointed out that subtraction didn’t work) and that CLR list types automatically appear like Ruby arrays.

Heavy DLR pitch ahead. Performance history, how the CLR used to be slow for dynamic languages, and how it’s better now.

John is running the Rubinius specs now, and showing only 373 out of 1030 failing. (It looked like he was running the core specs only.) Praise for the Rubinius team!

It’s possible to bind C# types to Ruby using annotations. Lots of C# code being shown, including a mess of generated code.

John also showed a XAML/Silverlight demo that was scripted by Ruby.

Charles Nutter and Thomas Enebo: JRuby

JRuby: “Not Just” JRuby for the JVM. I found it hard to take notes for this talk since I’m so close to it. Fortunately, their slides were pretty verbose and comprehensive, and hopefully will be posted shortly.

Evan Phoenix: Rubinius

Rubinius talk in roller derby mode. Ask questions early and often.

What is the end game of Rubinius (or JRuby, or IronRuby)? Total. World. Domination. For Ruby!

Rubinius is 3 things: form, function, and elbow grease. Ruby::Syntax, Ruby::Behavior, and Google.search("crazy cs papers").

Rapid fire CS Nerd attack mode coming. Generational collection, bytecode execution, stackless, bytecode represenation, .rba archives.

Who would rather program C than Ruby? Java? C#? (Only one guy raised his hand that he’d rather code C.)

Hard-hitting portion of the talk. The kernel, broken down.

1.8
- 84,516 lines of C
- 0 lines of Ruby
1.9
- 128,786 lines of C
- 0 lines of Ruby
IronRuby
- 48,282 lines of C#
- 0 lines of Ruby
JRuby
- 114,507 lines of Java
- 0 lines of Ruby*

(*Even though I got heckled for saying it, JRuby does actually have some code written in Ruby that’s not the standard library.)

Rubinius
- 25,398 lines of C
- 13,946 lines of Ruby

1.8 and 1.9 are really Ruby for C programmers. JRuby is Ruby for Java programmers. IronRuby is Ruby for C# programmers. But Rubinius is Ruby for Ruby programmers.

Dogfooding. Gives feedback, which enables tighter loops, improves the kernel, makes life better for everyone on the platform.

Road, rubber, all that jazz. Evan mentions that Rubinius runs 24 of 31 benchmarks faster than Ruby 1.8, but the numbers are shifting rapidly. Evan wanted a 1.0 for RubyConf, but he has come to realize that several things are more important than a milestone. Design, and the technical challenges, certainly. But more importantly, the community.

Taking a cue from the Perl 6 community, -Ofun. The free-flowing commit bit, where patch sumbitters whose patches are accepted are immediately entitled commit rights, has given rise to 57 committers. 17 of these have changed more than 400 lines of code.

RubyConf: Parting Thoughts

2007-11-05T17:57:34+00:00

RubyConf once again was thoroughly enjoyable. I highly recommend it to any Rubyist who is on the fence about attending to make it a priority to go next year. Here are some quick, random notes that didn’t quite fit into a full post.

For those of you who stopped by expecting to see the blow-by-blow of every minute of the conference like last year, my apologies. I think I set the bar a little too high for myself. It takes a lot of energy to stay focused on the sessions for the whole day. Perhaps it’s appropriate to pass the baton on to James Avery or Eric Mill for their 2007 coverage.
Venue (Omni Hotel Charlotte): Generally speaking, thumbs up. There were a couple of annoyances, though. 1. No non-emergency staircase to get to your room, causing huge lines for the elevators at the end of the afternoon. 2. Coffee was removed from the scene before 10 am, raising speculation that it was a conspiracy to drive business to the Starbucks in the mall below. 3. Toasters blew out the sound system on Sunday morning, forcing a PA system to be brought out and throwing a wrench in the rhythm of the morning talks.
I have to give props to Dr. Nic for avoiding getting burnt by the toaster incident and handling it really well. To boot, he gave one of the most entertaining talks at the conference, as the RubiGen video is sure to become an instant conference classic much like Adam Keys’ one-man-one-act event from last year.
Werewolf: I played one game, miserably. I was a werewolf, and when cornered by another in the game, mustered up the quote “I’m not an aggressive player, I prefer to feed off of other people.” Wow, what a freudian slip. While I can sympathize with Charlie’s comments about the game (and I do really enjoy late-night hackfests), I also have to agree with Chad and the other commenters that the two are not mutually exclusive, and the Werewolf games are wonderfully inclusive of RubyConf newbies and veterans alike.
The two-track approach in the afternoon this year seemed to go well, despite making it impossible to see all the talks. I would have liked to have seen Erik Hatcher’s Solr talk, but instead decided to give moral support to Kyle Maxwell’s JRuby in the Wild talk. I also missed the Saturday afternoon tracks to hang out in Stu’s Refactotum session.
Lots of good quotables: check out Nihilist and Twitter for some of the back-channel chatter.

See you next year!

RubyConf Day 3: Behaviour-Driven Development with RSpec

2007-11-04T16:26:00+00:00

David Chelimsky and Dave Astels: RSpec

describe TestDriverDevelopment do
  it "is an incremental process"
  it "drives the implementation" 
  it "results in an exhaustive test suite"
  # but also...
  it "should focus on design"
  it "should focus on documentation"
  it "should focus on behaviour"
end

class BehaviourDrivenDevelopment < TestDrivenDevelopment
  include FocusOnDesign
  include FocusOnDocumentation
  include FocusOnBehavior
end

When doing test-driven development:

Write your intent first. The smallest test you can that fails.
Next, write the implementation. The simplest thing that could possibly work.
Even though you may be tempted to think about additional edge cases, multiple requirements, etc., you should try to be disciplined and focus only on the immediate tests. Only after you’ve made one test fail, then pass, can you continue on to other tests.

RSpec history

Initially BDD was just a discussion among Aslak Hellesoy and Dan North in the ThoughtWorks London office. Dave Astels joined the conversation with a blog post stating that he thought these ideas could be easily implemented in Smalltalk or Ruby. Steven Baker jumped in with an initial implementation, and released RSpec 0.1. Later in 2006, maintenance was handed over to David Chelimsky. RSpec has evolved through a dog-fooding phase up to the present 1.0 product.

BDD is no longer just about “should instead of assert”, it’s evolving into a process. Emphasizing central concepts from extreme programming and domain-driven design, it’s moving toward focusing on customer stories and acceptance testing. It’s outside-in, starting at high levels of detail, rather than low-level like RSpec or Test::Unit.

Story Runner

Story Runner is a new feature intended for RSpec 1.1. Each story is supposed to capture a customer requirement in the following general template:

As a (role) ... I want to (some function) ... so that (some business value).

It uses a “Scenario ... Given ... When ... Then ...” format to express the high level stories. Scenarios are a series of given items, steps, and behaviour validations. Once the basic steps are established, they can be re-used. David even demonstrated a preview of an in-browser story runner that would allow the customer to play with the implementation and create new scenarios.

Pending

Pending is a nice way to mark specs as “in-progress”. You can either omit a block for your spec, or use pending inside the block to leave a placeholder to come back to.

describe Pending do
  it "doesn't need a block to be pending"
  it "could also be specified inside the block" do
    pending("TODO")
    this.should_not be_a_failure
  end
  it "could also use a block with pending, and you will be notified when it starts to succeed" do
    pending("TODO") do
      this.should_not be_a_failure
    end
  end
end

Behaviour-Driven Development in Ruby with RSpec is a new book David and Aslak are working on, due out early next year.

Update: David has posted his slides.

RubyConf Day 1: Morning Sessions

2007-11-02T15:35:00+00:00

Marcel Molina: What Makes Code Beautiful?

What is beauty? Marcel explores this topic, starting with posing the question to the audience. “My wife!” Marcel: Why is she beautiful? “Longer answer than you want!”

Marcel comes from a literature/linguistic background, and is interested in how meaning is conveyed, but even beyond the basic words themselves, but the context and expressivity as well.

Note: Marcel has given this talk before.

History of beauty

Pythagoras: was out in the street, heard the blacksmith’s clanging hammer, and was drawn to the noise. He recognized, through closer inspection, that the different sounds that came from the different hammers had relationships, and eventually saw similar relationships in other parts of nature, architecture, and so on.

Thomas Aquinas: Three things that define beauty: 1. Proportion. The economy of size and ratio of parts. The smallest thing that works. 2. Integrity. Well-suited for the purpose. 3. Clarity. Clear and simple.

Each of the qualities are necessary, but none are sufficent. For example proportion (economy) will often clash with clarity. This is especially true in code.

Applied to software

Case study: coercion. Converting XML strings into rich Ruby equivalents. Marcel’s initial solution was a CoercibleString < String, which used a generator to iteratively try to coerce XML attributes to a number of types, and return the results. ~20 lines of code to convert to 4 types. His second version was a simple class method on String with a case statement.

Kent Beck, in his book Smalltalk: Best Practice Patterns, writes a book about writing good software, but in Marcel’s opinion, arrives at a definition of beauty by describing aspects of code that reflect proportion, integrity, and clarity.

Niels Bohr: “An expert is a person who has made all the mistakes that can be made in a very narrow field.” Marcel calls his CoercibleString a mistake, but one that helped him learn more about coding.

Luckily for us, Ruby is optimized for beauty.

Jim Weirich: Advanced Ruby Class Design

Emphasizing “Ruby” more so than “Advanced”, through three examples that illustrate techniques not commonly found in statically-typed OO languages (Java/C++/Eiffel).

`Rake::FileList`

FileList['lib/**/*.rb']

FileList sports globbing, a specialized to_s, and lazy evaluation. First version: class FileList < Array; end. Good idea, right? Well, with lazy evaluation, resolution of filenames happens only when the list is accessed, not created, so a lot of methods need to be overloaded:

def [](index)
  resolve unless @resolved
  super
end

The problem becomes that FileList too closely mimics Array, and cannot distinguish itself in the case that matters. So it was changed to delegate to array rather than inherit.

Moral: when you want to mimic built-in classes, it might be better to implement #to_ary or #to_str rather than inherit.

Builder::XmlMarkup

What’s the problem here?

  b = Builder::XmlMarkup.new
  b.student do
    b.name "Jim"
    b.phone_number "555-1234"
    b.class "Intro to Ruby"
  end
 end

class is already a method on Object. This begat BlankSlate, which removes unnecessary methods from Object. Several techniques were applied to eventually arrive at the latest version:

Use undef_method to hide methods that we don’t want. Except, leave methods beginning with double-underscore alone (__id__ and __send__).
Catch new methods added via a method_added hook on Kernel, and an append_features hook on Object, to deal with methods defined and modules included after BlankSlate was created

TableNode

Problem: magic conversion of Rails conditions to SQL. An example: User.find(:all).select{|u| u.name == "jim"}. We don’t really want to load the entire database to do this, but we don’t like writing SQL either.

Solution: Record the actions in the select block by yielding a special TableNode object that captures the method calls and translates to SQL on the fly. Now we can write User.select {|u| u.name == "Jim"} and have it still execute SQL

Capture methods called and wrap in a MethodNode to convert to SQL column references
Capture operators and wrap in a BinaryOpNode to handle ==, <, etc.

Clever! Will this work? Here are some issues:

Small issue -- ordering: User.select {|u| "Jim" == u.name} will not work without messing with String#==.
Bigger issues: && and || are not override-able in Ruby. What’s worse, ! has pre-defined semantics (in the parser) and cannot be captured.

Lessons learned

Don’t be afraid to think beyond prior experiences to come up with new ways of solving problems in code.