This post originated from an RSS feed registered with Ruby Buzz
by Jamis Buck.
Original Post: RubyConf: Day Two
Feed Title: the buckblogs here
Feed URL: http://weblog.jamisbuck.org/blog.cgi/programming/index.rss
Feed Description: Jamis Buck's corner of the blogging universe. Mostly about ruby, but includes ramblings on a variety of topics.
This morning started equally bleary-eyed. I just can’t seem to shake this jet lag.
At any rate, I managed to shower and stumble downstairs for another exciting continental breakfast, followed by…
Morning Panel
Patrick May: Narf, revisiting a 2 year old
Patrick spoke about his Narf web framework. It’s stated goal is “to trivialize web development,” and it looks like it does a good job of that. He stated that when he started doing web development in Ruby, he was disappointed by the lack of choices in that arena, and that the CGI library that comes standard with Ruby is…not very good. :)
One of his focuses has been on testability, and it looks like he’s done some good things in that area. I’ll definately give this project a closer look.
James Britt: ruby-doc.org, Now and the Future
James Britt is the maintainer of the fantastic ruby-doc.org websit
1000
e. It is a collection of various Ruby documentation, both of the core classes and the extended API. It even includes a version of the Pickaxe.
James talked about the inspiration for ruby-doc.org, citing a ruby-talk discussion from acouple years ago in which a former Python guy complained about the lack of organized Ruby documentation. Jim Freeze (who talked about Ruby training yesterday) volunteered to help organize the documentation, and ruby-doc.org was born.
James also talked about the iterations that ruby-doc.org has been through, and ended with a plea for help: he would like a more automated way to post new content, and to allow others to post content. I suspect we’ll see a new-and-improved ruby-doc.org in the near future.
David Heinemeier Hansson: Ruby on Rails
This was perhaps the most anticipated presentation of the entire conference. David Heinemeier Hansson (or DHH as he is affectionately called by many Rubyists) is the author of the revolutionary Rails web framework. It has been lauded and heralded by nearly everyone as the best new thing in Ruby. I have yet to do more than poke at it, but after the conference I’ll make some time to go through the videos and documentation that David has prepared. (And you should, too!)
David’s presentation focused mostly on the history of Rails—how and why it came to be. He was originally a PHP programmer, but became disaffected with PHP (and other web frameworks) as his projects got larger. Thinking there had to be a better way, he started looking…
He found Ruby, and was turned off by the lack of good web frameworks available for it. (There have since been many that have appeared, but at the time there was certainly a dearth.) What he wanted was something that was just enough to make database-driven web applications “tolerable.”
So he started work on Rails. “Frameworks are retrospectives,” David said. They are “not built, but extracted.” Many projects fail because the developers build the framework without having any application for it. David built Rails piece-by-piece, as it was needed, so Rails really is “just enough.”
He also believes firmly in “convention over configuration.” “Adhere to yesterdays’ weather,” he said. If it worked for you yesterday, put it in the framework so it can be reused. The consequence of this is that the framework becomes oriented around his way of doing things, but to be honest, his way of doing things is pretty good.
He spoke, half jokingly, about how part of getting people to adopt a framework like this (where you are more-or-less forcing people to do things your way) is to allow them to configure things just a little. They come to you and say:
“Hey, why can’t I do X?”
“Well, you can, if you tweak this setting here in every class that needs it.”
“Oh, cool,” they say, and off they go. Later, they come back.
“I’m getting tired of having to tweak this setting in every class. Can I make it a default?”
“Oh, you know,” you say, “you can’t, really. However, if you just build your application such that W, Y, and Z are true, then it will just work.”
“Oh, cool,” they say, and before they know it, they’re doing thin
1000
gs your way.
The trick, David said, was to get them to at least use the framework and see how cool it is. Once they’re hooked, they’ll conform. :)
A good quote from David: “Yes, some Java people are smart.” (Don’t ask for the context, just take the quote.)
Afternoon Panel
Jim Weirich: Thee Many Facets of RubyGems
Jim Weirich spoke about RubyGems, a great package manager for Ruby that has made great strides in the last 6 months or so. In fact, the 100th gem (Ruby package) was just released in the last week, so it has some great content, too.
Jim gave us all a tour of RubyGems’ functionality, and demonstrated how to install RubyGems in such a way that gem-installed packages can work seamlessly with other packages. Just install RubyGems, and then set your RUBYOPT environment variable:
RUBYOPT=rubygems
(You can set RUBYOPT to anything that you want Ruby to consider a command-line option every time it runs…just leave the dashes off the options.)
SASADA Koichi: YARV, Yet Another RubyVM
Koichi has come to us clear from Japan, and not only that, but gave a one hour presentation, in English. It was really great to have him here. He has a great sense of humor, and knows a LOT about compilers and virtual machines.
He hopes for his project, YARV, to be adopted as Rite (Ruby v2.0). Matz has apparently promised him that this would be so, if he finishes it. How’s that for motivation?
YARV compiles Ruby code to a byte code (or a “word” code, as he called it, since the instructions are native words, not bytes). It then executes the instructions. This uses the existing (1.9) Ruby C API, including the garbage collector and so forth, basically implementing YARV as a Ruby extension. This allows YARV to focus just on the VM, and not have to worry about implementing all the peripherals.
For compilation, it even uses the Ruby parser, taking the node tree that is produced and then walking it to emit the instruction sequences.
He showed us some benchmarks, which were impressive. There was between 50% and 300% performance improvements (depending on what was being tested) when a script was run via YARV, versus when it was run through the existing Ruby interpreter. Not bad!
Nathaniel talked about his “test/unit” testing framework for Ruby (which is actually bundled with Ruby, as of version 1.8). He talked about what he’s learned, and where he’s going with it.
He showed us and demonstrated some sample code from the upcoming “test/unit2”, and it looks great. You no longer have to create a class for each unit test. Also, you can create reusable fixtures, easily.
I’m really looking forward to this to be released!
Keynote Speaker: Brad Cox, The
610
History and Design of Objective-C
After dinner, we were privleged to hear from Brad Cox, one of the creators of the Objective-C programming language. (FYI, Objective-C is the language used to implement the MacOS X graphical interface.)
He talked about the rationale for Objective-C, and how it evolved. He only spoke about that for a half-hour or so, and then moved on to his more recent interests—DRM and how it ought to be implemented.
DRM (Digital Rights Management) is a hot (and controversial) topic, and I’m afraid Brad got rather bombarded by questions (some bordering on accusations) from the attendees. His main thrust is that dividing property into “tangible” and “intellectual” is insufficient, that a third division needs to be made: “digital”. He claims that “digital” property differs from the other two, and needs to be handled differently.
His proposal is that digital property be managed on a per-use basis. For instance, you can get the software for free, but you have to pay for it every time you use it. Although I’m not convinced, it was an interesting idea. You can read more about it at MyBank Digital Rights Management System.
Previous Topic
