I am heading to Chicago for the Chicago Area Ruby Group meeting next Monday.

I’m Speaking at Chirb

I will be speaking at the next Chicago Area Ruby Group (Chirb) next Monday evening, March 6th. It looks like the meeting is starting at 6:30. You can get directions and all the details here. The topic will be “Demystifying Continuations” (a reprise of the RubyConf talk Chad and I gave last year). Bring a laptop if you have one, the evening will involve some Ruby coding.

I look forward to seeing some Chicago Rubyists.

A Movie of last Tuesday’s Intro to Rails talk is now available.

An Quick Introduction to Rails

Last Tuesday evening I gave a “Quick Introduction to Rails” talk at the local XP users group. The talk was a departure from my normal presentation style and was inspired (in part) by Dick Hardt’s Identity 2.0 talk I saw at OSCON last year. Bill Barnett has made a movie of the talk available for download, so those of you who missed it can still see it.

Next Presentation

I will be giving shortened version of the talk again on the 21st of January at the Dayton-Cincinnati Code Camp sponsored by the Dayton and Cincinnati .NET users group. I will also be giving the popular 10 Things Every Java Programmer Should Know About Ruby talk at the same conference. Hope to see you there.

Presentation Links

I probably won’t post the “Intro to Rails” slides. (Update: See below). I don’t think the slides stand alone very well. But several people have asked about links to the stories I mentioned. Here is a partial list:

• David Geary
  • BIO (http://nofluffjuststuff.com/speaker_view.jsp?speakerId=4)
  • The Koolaid Posting (http://rubyurl.com/I9t)
  • Retraction (http://rubyurl.com/HeG)
  • Demo (http://jroller.com/page/dgeary/20050821)
  • The Rails Cafe (http://jroller.com/page/dgeary/20050714)

• Justin Gehtland
  • BIO (http://www.nofluffjuststuff.com/speaker_view.jsp?speakerId=5)
  • Java 2 Ruby Project (http://www.relevancellc.com/blogs/?p=29)
  • Feedback on J2R (http://www.relevancellc.com/blogs/?p=30)
  • Performance Numbers (http://www.relevancellc.com/blogs/?p=31)

• Stuart Halloway
  • BIO (http://nofluffjuststuff.com/speaker_view.jsp?speakerId=6)
  • Estimating Rails Jobs (http://www.relevancellc.com/blogs/?p=92)
  • Feedback on Estimating (http://www.relevancellc.com/blogs/?p=93)

• C.A.R. Hoare
  • The 1980 ACM Turing Award Lecture The Emperor’s Old Clothes (PDF) (http://www.braithwaite-lee.com/opinions/p75-hoare.pdf)

• David Heinemeier Hansson
  • BIO—Source of the XML Situps quote (http://conferences.oreillynet.com/cs/eurooscon/view/e_spkr/2130)
  • Ruby on Rails (http://www.rubyonrails.org/)
  • List of Real World usages of Rails (from which I pulled a small fraction for the talk (http://wiki.rubyonrails.com/rails/pages/RealWorldUsage)

There’s some other great articles on Stuart’s and Justin’s Relevance blog site. Also, the Hoare paper is a classic and well worth the read (even though I understand he retracted much of what he said about Ada later).

Presentation Styles

The software I used for the slides runs entirely on Firefox, and a reference can be found here: http://cardboard.nu/blog/2005_12_15/a_cute_mozilla_xul_app.html.

Here are some references on the influences on that particular presentation style:

• Dick Hardt’s Identity 2.0 Presentation at OSCON 2005 (http://www.identity20.com/media/OSCON2005/)
• The Takahashi Method (http://rubyurl.com/r81)
• The Lessig Method (http://rubyurl.com/4YH)

It is interesting to note that TAKAHASHI Masayoshi, the inventor of the Takahashi method, is involved with Ruby in Japan.

Update (Monday: 9/Jan/06)

Several people have asked for the slides and pointed out that if I published them, you could watch them in conjunction with with the video. Ok, good point.

The online version of the presentation is available here.

If you wish to download the presentation for local viewing, or for your own use or modification (under the terms of the Creative Commons Attribution/Non-Commercial License), then here is a tarfile. If you download the tarfile, make sure you specify the data file properly in the URL. See the live link above for an example.

Have fun.

It always bothers me to see mock objects creating and returning other mock objects.

David Chelimsky on Dependencies

David Chelimsky of Object Mentor notes that dependency injection eases the pain of dependencies so much that we sometimes don’t bother to root out the bad dependencies. Read the article and pay close attention to the dependencies in the original and final versions (I drew a couple UML diagrams to keep it clear in my head).

Plus its got a great Princess Bride reference!

Inevitably, every Ruby nuby asks the question “What are symbols?”, and the standard answer is “A Symbol is an immutable string”. I have some issues with that answer.

Every Nuby’s Question

Whenever someone asks “what are symbols” in the ruby-talk mailing list, the explaination almost always begins with “Symbols just immutable strings”, and then goes on to explain what symbols are good for and how they are used. Comparing them to something familiar (like a String) is a good pedagogical technique, but I’m left feeling that the answer leads the nuby down the wrong path to understanding.

Symbols aren’t Strings

First of all, symbols really aren’t immutable strings. Not even close. In fact, they aren’t Strings of any kind. This simple fact is easily demonstrated by the following:

  $ irb --simple-prompt
  >> sym = :symbol
  => :symbol
  >> sym.size
  NoMethodError: undefined method `size' for :symbol:Symbol
          from (irb):2
  >> sym[0,2]
  NoMethodError: undefined method `[]' for :symbol:Symbol
          from (irb):3

You can’t ask for the size of a symbol. You can’t ask for a substring of the symbol. You can’t do anything that you can do with strings on Symbols except (1) convert it to an integer (using to_i) and (2) convert it to a symbol (using to_sym). If a symbol is not a duck-type for a String, it hardly seems reasonable to call Symbols any kind of String, even immutable ones.

So if they aren’t Strings, what are they?

A Symbol is a simply an object that can be can be uniquely identified by its name. Every time you say :xyz in your code, you will be refering to an object (a symbol) that has the name “xyz”. There is only one Symbol with the name “xyz”, so all references to :xyz will refer to the same symbol¹.

So you see, there is a tight relationship between Strings and Symbols. Every symbol has a string name (available via to_s). And every String can be asked for its corresponding symbol (via to_sym). Strings and Symbols are closely related, but they are not the same thing.

So, fundamentally, Symbols are just objects with names.

And when should we use Symbols?

Invariably, when presented with the “Symbols are immutable Strings” meme, the nuby will ask “So when do I use Strings and when do I use Symbols”? By pointing out that Symbols are not Strings at all, makes it clear. Use Strings whenever you need … umm … string-like behavior.

As we pointed earlier, Symbols are not even duck-typed strings. So using a symbol where you really want string-like behavior is a mistake. Rather, take a clue from the description of a symbol: an object with a name. It turns out that symbols are great for naming things. Use them whenever you need to name something in your code. For example:

1. Naming keyword options in a method argument list
2. Naming enumerated values (e.g. like enums in C).
3. Naming options in an option hash table.

I’m sure other uses will come to your mind.

Some Closing Thoughts

Here’s how I like to express the difference between Strings and Symbols. Strings are about a sequence of characters. Symbols are about naming and identifying things.

There you have it.

I’m watching. Perhaps the next time this question comes up on ruby-talk, someone will say “A Symbol is an object with a name”. That would make my day.

¹ For anyone familiar with Lisp, the simularities between Symbols and Atoms are obvious.

The last several clients I have worked for loved to publish huge coding standards documents. A recent one was only 20 pages long (and that was one of the shorter ones).

While browsing the new Rails 1.0 web site1, I stumbled upon the Rails coding standard. Here it is in full (link):

• Two spaces, no tabs
• MyClass.my_method(my_arg)—not my_method( my_arg ) or my_method my_arg
• Follow the conventions you see used in the source already

¹ You did know that Rails 1.0 was released today, right?

Does the open class nature of Ruby effect how we think of classes? Perhaps it does.

More on the Array API Controversy

I commented earlier on the Array API controversy (see Array API). I had some more thoughts on that topic.

As both a Java programmer and a Ruby programmer, I enjoy comparing the two languages, noting their differences and more importantly, recognizing the different ways they effect my thinking.

In general, I would tend to agree with Elliotte on creating classes with small APIs. They do seem to be easier.

On the other hand, I’m not really bothered by the large Array API provided by Ruby. There is a clash between what I believe and what I find to be true.

Perhaps some of the answer lies in the open nature of Ruby classes. A Ruby class can be extened at any time by any user. Although the potential for abuse exists, it is also a very handy thing to be able to do.

As a result, methods tend to migrate to the classes they belong to, rather than put in a utility method somewhere. Although I might never use assoc, if I were to look for it, I would start in the Array class¹, or one of its included modules.

Since rubyists accept the fact that we can’t ever completely know a class, the fact it has extra methods on it that we aren’t using doesn’t seem to be a big deal.

Java, on the other hand, has closed classes. The methods available on List are all that are there, and all that ever will be there (well, until someone modifies and recompiles the class). This gives the impression that I can fully understand the class and exactly what it is doing. This impression is further strengthened by the use of interfaces, which further narrows down the user’s view of a class to just the methods available in an interface.

I don’t know, maybe this has nothing to do with it. And there are certainly other factors involved. For example, Array is such a commonly used class² that perhaps this is the exception to the rule of small interfaces.

Whatever the reason, I don’t find using Array objects to be a burden at all, despite what the theory of small interfaces might indicate.

¹ In fact, I did need assoc recently. Guess where I found it.

² I find that Array is used much more in Ruby than any variety of List is used in Java. I don’t know if that a good thing or not.

Minimalists VS Humanists—A tempest in a teapot is brewing over the proper design of a class API.

Martin Fowler VS Elliotte Rusty Harold on API Design

There’s a hot debate going on about humane API design. Martin Fowler points out that Ruby’s Array API is very rich, providing the user with lots of options when using it. Elliotte Rusty Harold responded with “A 78 method List class is about three times as bad as a 25 method List class, not three times as good.”

And so the debate rages on. Read the links on the bottom of Martin’s page for other opinions on the topic.

I was going to write a long post pointing out that java.util.List is an interface, and we like to keep interfaces short. Ruby’s Array is not an interface (Ruby doesn’t have interfaces as a language construct) but a class, and the forces that keep interfaces small don’t apply so strongly.

But … I decided not to.

Instead I’m going to point out just a small irony. Elliotte writes:

Another example: Fowler likes the first and last methods in Ruby, but list.first() is not significantly simpler than list.get(0). list.last() is perhaps a little simpler than list.get(list.size() – 1) but only because Java stupidly indexes everything from 0 rather than 1. And how often do you actually need to get the first item in the list?

But java.util.LinkedList provides:

   Object getFirst()
            Returns the first element in this list.
   Object getLast()
            Returns the last element in this list.

Interesting.

Why does Elliotte not use getFirst()? ... Because it is not available in the java.util.List interface. Java programmers typically write:

   List myList = new LinkedList();

And then use myList in their code. Since myList is declared to be a list, the getFirst() method never pops up in their completion menus.

As they say: “Out of sight, out of mind.”

Why the Lucky Stiff provides us with yet another Ruby Goodness.

Try Ruby Now

For those of you who have been living under a rock and have missed this link, you need to check this out:

• Try Ruby

(courtesy of Why the Lucky Stiff)

Via Elizabeth Keogh ...

If an Agile Evangelist falls in the forest and there’s no one to hear him, does he still go on, and on, and on about it?

(link)

RubyConf at a Glance

It was very clear by Saturday that I wasn’t going to be able to blog each and every talk like I had in the past. There was just too much going on and I had too much on my plate to do it justice. Plus there were a lot of people doing a talk by talk blog on the conference, so my additional comments seemed superfluous.

So rather than do a blow by blow descriptions, I thought I would just touch on a few highlights.

Matz’s Keynote Address

Matz subtitled his talk “Weird and Crazy Ideas” and he talked about some of the “stretch” ideas he has for Ruby 2.0. If you are following the Ruby 2.0 discussions up to this point, there wasn’t anything that was a big surprise. But he did give some more details on what we should be expecting.

Two big topics of conversation came out of this keynote. One was the syntax for anonymous functions. The second was the syntax for keyword arguments. See the ruby-talk mailing list before the conference for a discussion of anonymous functions. See ruby-talk after the conference for keyword arguments discussions. Both topics are generating a lot of traffic on the ruby-talk mailing list, so check the mailing lists for any details.

Selector namespaces were mentioned by Matz, but without any hint of how they would be implemented. After the keynote, Rich Kilmer brainstormed some ideas and Paul Brannon actually did a (simplifed) pilot implementation in pure Ruby to get a feel for how they might work.

The Long Tail

One of my favorite talks was Nathaniel Talbott’s talk on the long tail of software development. He explored the question of what happens to software development as the time and cost to develope software approaches zero. He compares it to intercontinental railroad (rails ... get it?) which lowered the cost of traveling to the interior of the US to a point that almost anyone could travel.

Metaruby and Ruby2C

The Seattle group is doing some really exciting stuff exploring what it would take to get the standard Ruby library (currently written in C) defined in Ruby. Its a two pronged approach. Part 1 is the Metaruby effort to rewrite the standard classes is a (rather static) subset of Ruby. Part 2 is the Ruby2C translator that can take a subset of Ruby and rewrite it as C code. If this project is successful, moving Ruby to a different platform (i.e. the Java JVM or .NET CLR) much easier. Ryan Davis and Eric Hodel were the presenters for these two talks.

JRuby and YARV

I see these two projects are very important to the future adoption of Ruby in two different groups. YARV addresses the “Ruby is too slow” crowd, while JRuby addresses the “but it doesn’t interact well with Java” crowd. While neither group is critical to future adoption, Ruby acceptance would be enhanced by addressing their concerns.

My Talks

I did two talks this year. One was in the standard track and was on the topic of Domain Specific Languages written in Ruby. It was well received and seems to seeded some new ideas in some people.

The second talk was a workshop (with Chad Fowler) on Sunday afternoon where we delved into the details of programming with continuations. The other workshop was on Rails, so I expected a light turnout at ours. Surprisingly we had a very good crowd. Presenting with Chad was a lot of fun (I really liked the conversational approach we used) and people seemed to enjoy it. Plus I worked in playing a video game into the talk.

Other Stuff

I think the best part of RubyConf is not the formal talks, but the chance to meet and talk to people over meals and between sessions. I will post on some of the topics sparked by these conversations in the weeks to come. Unfortunately, I didn’t get to participate in as many code fests as I had hoped (I was too brain dead for serious coding by the end of the day).

I’m already looking forward to next year!