The CD Baby sponsored contest for RailsConf 2007 is complete! (Original announcement here and here.)

The top 20 winners are posted at the Rails Hackfest 2007 Winners page on WorkingWithRails.com.

But.. I want to point to the top 40 winners for two reasons:

(1) - because everyone who contributed deserves a hell of a lot of credit for making Rails itself even better, even if they weren’t top-20.

(2) - because there’s a chance that not-everyone in the top 20 will be able to attend RailsConf 2007, even though we’re paying for registration and hotel. I’ve already pre-paid for 20 registrations and 20 hotel rooms, so for every person in the top 20 who tells me they can’t make it, I’ll go down to #21 on the list.

Top 40 Rails Hackfest 2007 Winners:

1. Jeremy McAnally (1953)
2. Dan Manges (1771)
3. Jarkko Laine (1128)
4. Scott Meade (1106)
5. Manfred Stienstra (1045)
6. Josh Susser (878)
7. Zack Chandler (864)
8. Ben Scofield (833)
9. Ryan Daigle (809)
10. Brian Donovan (794)
11. Steven A Bristol (785)
12. Anthony Eden (773)
13. Jamie Quint (760)
14. Rob Sanheim (756)
15. Rich Collins (728)
16. Ben Sandofsky (725)
17. Seth Ladd (713)
18. Kevin Clark (685)
19. Dan Kubb (588)
20. Nicholas Wakelin (587)
21. Michael Schoen (483)
22. Benjamin Curtis (360)
23. David Rice (335)
24. Jakob Skjerning (220)
25. Cody Fauser (220)
26. Mislav Marohnić (211)
27. Eustáquio Rangel (204)
28. Josh Peek (171)
29. Laurel Fan (163)
30. Tieg Zaharia (154)
31. Ian Dees (132)
32. Jonathan Viney (119)
33. Bojan Mihelac (114)
34. Bert Goethals (113)
35. Dave Myron (111)
36. Ezra Zygmuntowicz (110)
37. Phil Ross (108)
38. Graeme Mathieson (100)
39. Aaron Wheeler (100)
40. Christophe Porteneuve (76)

a comment and response from my blog entry announcing the release of the Rails Cookbook:

by Leonard Richardson on 27 Jan 01:22

@Leonard: Thanks very much. Yeah, you’re right but as they say, real change
comes from within. That said, having the non-Safari PDF pub two weeks after the print
version (down from six) may have taken some fireworks out of the release party,
but it isn’t really that long to wait–even in Rails time.

In addition to PDF releases, other progress O’Reilly made was towards a 100%
XML-based editorial and production process. Having the book constantly in
DocBook allowed me to incorporate contributed content easily and to build Ruby
tools to manipulate that content. DocBook also allowed me to easily update the
book for Rails 1.2 late in the production process.

In reality, O’Reilly gets a whole different set of problems then some of
their smaller publishing partners, like the Prags. One of those problems is how
to publish the large volume of titles they offer, with consistently high
quality. To do this they have to have more cooks in the kitchen (authors,
editors, etc…) and that makes adapting to new processes more difficult, but
definitly not impossible.

The pattern here is that our media is getting richer and PDFs are just a first step in that direction.

The future is open.

Rob

The Rails Cookbook is finally available! I wasn’t sure how the timing of the book’s production schedule and that of the release of Rails 1.2 would work out, but it looks like I nailed it. I had a blast working on it and with all the people in the community that helped make it a reality.

I know that many of you are waiting for the PDF version and I’m working with folks here at O’Reilly to make that happen by a week from Monday (Feb. 5th). Please watch the book’s catalog page or my blog for updates.

Andy Oram has been talking to some people who are interested in hiring Ruby developers for
work on a patent reform project.

Perhaps we should have a separate forum for job and project postings.

I just received this message from Brian McConnell. Brian is an O’Reilly author and blogger, and generally a smart guy. I didn’t know he was working in Rails–I’ve always thought of him as a Pythonista. Anyway, if you’re interested in this project, let him know. Description follows…

RubyForge has been growing fast. As the primary resource for project hosting in Ruby, it’s been expanding with the language. One thing that is interesting about it as a service is that it is more-or-less maintained by just one person (Tom Copeland) with the help of a few other folks and some RubyCentral funding.

A few months ago I joined the RubyForge team to try to lighten Tom’s load a bit, and have been monitoring the support forum since then. I think a whole lot of folks don’t even realize we have one while some others have mistakenly assumed it was a general Ruby forum. This post is meant to explain a little bit about what the forum is for and how you can use it to get the help you need.

Yet another series attempt

I think my NubyGems series has gone over pretty well, so I figured I’d try my luck with something else.

This new series, digging deep, will be targeted towards the more experienced developer, or at least folks who want to know a little more about some deeper concepts in Ruby. I’m going to do what I can to make these as clear as possible, but I’m relying on input from gurus and skeptics to help improve these posts and make them a good resource for folks.

So this post will focus on a recent topic on RubyTalk, the merit of using Mixins as a suitable replacement for multiple inheritance.

I’ve written before about how cool it is to see the JRuby and rubinius guys working together (Nick Sieger also posted a piece about it). (It can be mind-bending to follow a discussion across multiple irc channels though.) I’m even more encouraged to see that Kevin Tew (the Cardinal hacker) and SASADA Koichi (the YARV hacker) have joined the fray.

(correction): fixed Upton Sinclair quote it is ’salary’ not ‘job’ (thanks for the correction)

Even with all the buzz, it is still a tough sell. If you’ve suggested Rails as an alternative to (Java|.NET) at work, you’ve probably experienced some reactionary pushback. Convincing a set of established “Enterprisy” engineers that Rails is worth paying attention to it is like convincing a Texas oil baron that he should purchase a Subcompact hybrid vehicle and become a Vegan. Why is convincing a highly paid (Java|.NET) programmer to look at Rails that difficult? I’ll steal a quote from Al Gore’s Inconvenient Truth that he, in turn, stole from Upton Sinclair:

“It is difficult to get a man to understand something when his salary depends on not understanding it.” - Upton Sinclair (1878 - 1968)

In an effort to convince, you may have sent people to some of the good Ruby on Rails blogs. This might have escalated the resistance. Asking your fellow enterprise developers to read DHH’s loudthinking.com, is like asking (the other) O’Reilly to sit down with Colbert - Mr. Enterprise isn’t going to appreciate the message because he’ll be focused on the ridicule. Rails, rightly so, is positioned as the challenger, and it makes good use of hyperbolic ridicule to gain converts. This works for most of us, but I’ve also seen it push some entrenched Java developers further away.

Common Responses

So, you are in “The Big Planning” meeting, and your boss says something like, “There is no time to finish this project, we’re going to have to tell the customer we won’t meet the deadline.” You wearily offer up the suggestion: “We might be able to deliver something on time if we used Rails to implement the web application”. And, an entire room full of Java programmers is now trying to tell you every reason from here to the North Pole why your suggestion is naïve. Here are some of the common responses:

1. Freedom (Too Much) - “Our developers are not disciplined enough to use a scripting language.”
2. Rigor / Formality - “Our systems are serious and require a much more rigorous approach.”
3. Performance - Our systems need to perform, and Ruby (specifically Ruby on Rails) doesn’t perform to our standards.
4. Flexibility (Not Enough) - (Rails) We can’t afford to follow the database standards that Rails would impose on us

Let’s take each one individually…read on…

A comparison between the #5 language (ranked popularity by Tiobe on Jan/07) and the #1 framework (ranked lovability by me!).

My hometown, St. Louis, is hardly one of the great meccas of the computing world. Places like San Francisco, Seattle, and New York were the first to have local training available. Yet, even here in St. Louis, if you want Ruby on Rails training you now have more than one choice (competition is good). Last year OCI unveiled local RoR training, and now Inspired Horizons is doing the same. I’d be willing to bet that this is quietly happening all over.

Help prove me right. Do you live in a place that is not considered one of the computing hot spots, yet you still have local Ruby or Ruby on Rails training available? If so, post a comment and tell us about it!

You’ve probably heard that RailsConf 2007 will be May 17-20 in Portland, Oregon.

Since my company CD Baby depends on Rails, and since we’re based in Portland, I decided to spend some company money to reward the people that MAKE Rails. Not just the ones who invented it, but the people who are actively improving it by contributing patches to Rails code.

* - We bought 20 full RailsConf registrations from O’Reilly. ($800 value)

* - We pre-paid for 20 rooms at the Jupiter Hotel, an incrediby cool funky modern hotel, a few blocks from the conference, with free wi-fi everywhere - for three nights : May 17, 18, 19 (a $300 value)

* - We reserved the DreamBox conference room at the Jupiter Hotel for the nights of May 17, 18, 19, for elite Rails hackers to gather, plug in, hack, eat, drink, etc. (priceless)

These 20 registrations, 20 hotel rooms, and access to the DreamBox will go to the top 20 contributors of Rails patches (as measured here) between January 1 and January 22!

(RailsConf is opening registration soon after January 22 - that’s why we have to make the Jan 22 cutoff date.)

In other words : if you want CD Baby to save you $1100 on RailsConf, sprint!

If you’re not already signed up at workingwithrails.com, sign up now. In your workingwithrails profile, mark yourself as a core contributor and enter your Trac username. Then all of your patches will be linked to your account.

Bookmark http://workingwithrails.com/contests/hackfest2007 to watch progress

Also see Jeremy’s announcement at http://weblog.rubyonrails.org/2007/1/8/hackfest-2007-and-cdbaby-sprint

UPDATE : winners announced here

This was actually inspired by some thoughts at a new_haven.rb meeting I wasn’t able to attend, reintroduced in a RubyTalk thread, and solidified in another blog entry that’s worth a look.

The topic here is simple, and it’s that for most common needs, there is absolute no reason to use class variables. I will show how you can use class instance variables to avoid the problems associated with class variables in most cases at the end of this article, but first, take a look at two compelling and mind melting reasons for *not* using class variables.

From Gary Wright:

>> class A
 >> @@avar = 'hello'
 >> end
=> "hello"
 >> A.class_variables
=> ["@@avar"]
 >> A.class_eval { puts @@avar }
NameError: uninitialized class variable @@avar in Object
        from (irb):5
        from (irb):5
 >> class A
 >> puts @@avar
 >> end
hello
=> nil
 >> class A
 >> def get_avar
 >> @@avar
 >> end
 >> end
=> nil
 >> a = A.new
=> #
 >> a.get_avar
=> "hello"
 >>   a.instance_eval { puts @@avar }
NameError: uninitialized class variable @@avar in Object
        from (irb):16
        from (irb):16
 

And the real scary one, from David A. Black:

   @@avar = 1
  class A
    @@avar = "hello"
  end
  puts @@avar  # => hello

  A.class_eval { puts @@avar }  # => hello

Yes, there are reasons why both of these problems occur. Yes, they are likely to give you a headache.

If you’re just looking to store some data in a variable which is unique to your class, but accessible from instances or externally, why not just use instance variables?

>> class A
>>   @foo = "bar"
>>   class << self; attr_reader :foo; end
>> end
=> nil
>> A.foo
=> "bar"

Yup, classes are just regular old ruby objects, and class instance variables are just regular old instance variables. This avoids the above problems, as well as simplifies the concepts of where your variables actually live.

Yeah, maybe @@foo is easier to type than self.class.foo
But good luck debugging it! :)

Ruby is now in the top ten languages in the TIOBE index, and has been declared Programming Language of the Year for 2006 because it had the largest popularity increase in 2006 of all the languages tracked:

We are glad to announce that Ruby has become “Programming Language of the Year 2006″. Ruby has the highest popularity increase in a year of all programming languages (+2.15%). Runner up this year is JavaScript with +1.31%. Both languages are boosted by their corresponding frameworks, Ruby On Rails and Ajax. This might be a new trend. In the recent past it was necessary to have a large company behind the language to get it in the spotlight (Sun with Java, Microsoft with C#), but nowadays a killer app appears to be sufficient. Viral marketing via the Internet works! The winners of the last 2 years, PHP and Java, are the losers of this year. Other trends that are observed are the growth of dynamically typed languages and the fact that the difference in popularity between languages is getting less.

This is awesome… ‘nuf said.

Beauty is in the eye of the beholder

In my experience, there are a few different attitudes when it comes to beautiful design. Many consider Rails to be a beautiful framework to work with. In it’s own right, I certainly would agree with these folks. If you’re willing to accept the 80/20 divide and the tool fits the job, it could be dreamy to work with Rails. But in my limited experience, I sort of feel like a decision to work with Rails is more or less an all-or-nothing decision.

Like a train that wants to go east but only has tracks running North to South, a change in course is going to create some major problems. I don’t think this is a bad design, that’s what a train is meant to do. But maybe for some jobs, you need a dune buggy. That’s where the little wheels come in.

The camping framework is designed in light of another definition of beauty, and that definition is closer to the austere. When I started a job in it, I asked the usual questions one might run into when dealing with a small web app. “Does camping support sessions|file uploads|static files”

The answers were, ’sort of’,'nope’,'nope’. But all three were also appended with a “but it’s easy to roll your own”. The rest of this article will show you one way to do all three, and hopefully show some appreciation for the simplicity of the task.