A link on digg gets us to a page about Germany’s new Water Bridge, an impressive aquaduct.
So, today’s Thanksgiving dinner question: what happens to the load on the bridge’s supporting columns as traffic enters an empty bridge? Do they feel additional weight? Does the load on them stay the same? (Please don’t e-mail me: just a question to get the family thinking.)
It was an intense three days, but it’s over! We just finished the very first Rails Studio in sunny (if chilly) Reston, VA. The site couldn’t have been better. FGM, Inc hosted us, and they did us proud. The meeting room was great (it even had windows :), and they laid on a network and plenty of power (we were initially surprised at how many folks came with laptops, but FGM came to the rescue with additional power strips and we just squeaked by).
The course itself seemed to go really well. We learned a lot along the way (Dave now knows not to start a new topic and delay lunch). We also adapted the presentation style as we proceeded based on the prior day’s feedback. This lead to probably the biggest overall lesson learned. We originally had people coding along with us as we developed our Rails application, but at some point or other just about everyone went down a rabbit hole and had a hard time catching back up. Next time we’ll have checkpoint versions of the application available so everyone can sync back up before we move on to the next topic.
I think everyone came away having picked up a lot about Rails coding (not to mention the “I’d Rather Be on Rails” bumper sticker and the exclusive Golden Spike T-Shirt). On the final day, everyone coded their own Rails application—some of these had components and Ajax support!
We’ll be announcing the next studio shortly: we’re probably looking at the west coast next, with a possible return to the east coast shortly thereafter. In the meantime, there’s a bunch of pictures up on flickr which give a pretty good idea of the fun atmosphere.
Thank you, golden spike members, for coming along and making this a success…
The Ruby Extensions Project contains an absolutely wonderful hack. Say you want to convert an array of strings to uppercase. You could write
result = names.map {|name| name.upcase}
Fairly concise, right? Return a new array where each element is the corresponding element in the original, converted to uppercase. But if you include the Symbol extension from the Ruby Extensions Project, you could instead write
result = names.map(&:upcase)
Now that’s concise: apply the upcase method to each element of names. So, how does it work?
It relies on Ruby doing some dynamic type conversion. Let’s start at the top.
When you say names.map(&xxx), you’re telling Ruby to pass the Proc object in xxx to map as a block. Ifxxx isn’t already a Proc object, Ruby tries to coerce it into one by sending it a to_proc message.
Now :upcase isn’t a Proc object—it’s a symbol. So when Ruby sees names.map(&:upcase), the first thing it does is try to convert the Symbol :upcase into a Proc by calling to_proc. And, by an incredible coincidence, the extension project has defined a to_proc method for class Symbol. It looks like this:
def to_proc
proc { |obj, *args| obj.send(self, *args) }
end
It creates a Proc which, when called on an object, sends that object the symbol itself. So, whennames.map(&:upcase) starts to iterate over the strings in names, it’ll call the block, passing in the first name and invoking its upcase method.
It’s an incredibly elegant use of coercion and of closures.