Jake Scruggs

writes ruby/wears crazy shirts

(or the second day if you count the tutorials)

To start things off Jim Freeze got up and announced that there are 282 attendees and seats for 280 -- So make friends. The the first talk of the day was "The Next Ruby" by Bruce Williams and he (of course) discussed the difference between Ruby 1.8.6 and 1.9

Bruce recommended a good test suite if you're planning to move to 1.9 and I have to agree. Tests are good for lots of reasons (including design) but they pay for themselves 100 times over when you need to do a big tech migration.

Because of changes to string, anything string heavy (such as parsers) is gonna need some love. On the plus side:
"ruby"[0] => 114 in Ruby 1.8.6
"ruby"[0] => "r" in Ruby 1.9
Yep, I've been burned by that and I'm glad to see sanity carry the day.

In other news:

  • Hash.select now returns a hash
  • Hashes will maintain order
  • :this === "this" #true
  • Because of Multinationalization Strings now have each_chr or each_line not each (gotta support those Japanese, Chinese, etc. characters)
  • Threads are moving to native threading model
  • Fibers introduced: lightweight user threads (Check out NeverBlock)

But there's a Huge Problem:
There exists a monstrous pile of unmaintained gems out there that everyone uses which need to be migrated to 1.9. So how are we going to get there? Bruce didn't have any solutions. Last night at dinner Dave Thomas suggested that Rails will need to have some sort of killer feature that relies on Ruby 1.9 to get people to switch. He might just be right.


The next talk was "Hidden Gems" by James Edward Gray II and it featured lots of Battlestar Galactica photos whilst James talked about some of his favorite underused Ruby Gems.

NArray is high on his list because it borrows C's numbers for speed. He had an array, used for an image, which was taking a few seconds to compute. When he switched to NArray he got hundredth of a second times. Nice.

James also likes SQLite for data processing. It's surprisingly fast to load a bunch of data into SQLite and then use db power to search and process said data. You can even run it in-memory for even faster results.

And of course he talked about Rinda. Rinda is a fairly easy way to farm your tasks out to many different computers. And we all like more power.


Rein Henrichs then talked about "Ruby Best Practice Patterns." He started out with a talk about how to De-factor your code for increased job security. Pretty funny stuff. He did some line by line examples of how to make code worse (example: use Pig Latin to name your methods). Then he segued into his real talk about how to write good Ruby code. His main point seemed to be that patterns are not just huge things that define architecture, they are an everyday practice. I totally agree with that and it's kinda of cool that I get to follow his talk. I sort of pick up where he left off.

Then was lunch and a bunch of me getting nervous while looking over my slides. I had already given my talk in front of two different small groups of programmers, so I felt pretty good about it in the rational part of my brain. However, I had been scheduled to talk in the big room on the same stage Matz himself would later occupy -- which is a bit of pressure. About a half hour before my talk I ran into Gregg Pollack and he shot a video of me summing up my presentation in 30 seconds. I was a bit keyed up so I have no idea how that came out. But now I get to be a part of his "#{whatever} Conference in #{some} minutes" series -- a series I really enjoy. A few minutes before I was to get up and talk I heard some guys right next to me talking about how they were gonna ditch this metrics talk to go hear about javascript. Damn their black hearts.

I was pretty keyed up and the body mic was behaving weirdly, but I settled in after a few slides and I feel it went fairly well.


Next up in the main room was "Care and Feeding of Ruby Developers" by Steve Sanderson.
Steve comes from old school programming culture so this talk started off with some observations on these crazy young developers:
  • Aesthetics matter
  • Collaboration is important
  • Physical location is not that important (I disagree)
  • The doing is close to the planning
  • Programmer as Stars
  • Maybe you give away the code, but that doesn't mean you don't make money

And his advice for businesses employing Ruby devs was:
  • Be out there in the community
  • Empower the developers to make changes or at least have access to those who can make changes
  • Plan for people who blend technical and aesthetics

After that I headed over to the alternate room for "Creating Desktop Applications With Ruby on Mac OS X" by Brian Cooke

He started out by extolling the virtues of Cocoa. He loves and wants to marry Cocoa because it lets you create commercial grade apps without a ton of training. Then he talked about using Xcode and Interface Builder with Ruby Cocoa. Ruby Cocoa is a way to write slick looking Macish apps without having to learn Objective C. However the syntax looks a bit unlike Ruby because it has to be converted into Objective C.

It's hard for me to follow these presentations about Interface Builder because the Object-Cish syntax gets in the way. Also the drag and drop stuff kinda freaks me out. To wire up a button you drag a blue cube somewhere, tell it what class to use, then you drag a blue line to somewhere else. Does that skeeve anyone else out?

He used the Faker gem to generate fake names. I saw Gregg use it in his ActiveRecord talk and I like the idea of having real-looking data in my tests. I'll have to check that out.

Brian finished up by saying you really need to learn Objective-C because Ruby Cocoa is not fast, its files are available to anyone who gets the app, and debugging is no good.

Huh.

He then went on to say that MacRuby is going to be much better because it's Ruby in the OSX runtime (kinda like JRuby). So you should get all the benefits of writing in Objective-C. When will it be out? No one knows 'cause Apple is writing it and they're all about the secrets.


Hey did I mention there was a "green room" for speakers? And that when I went in there no one yelled at me and told me to get out? Excellent. Also they had Coke Zero instead of the oppressive ice tea or water choices everywhere else. Although I do have to say that the food was pretty good. Excellent even, if you consider that it was conference food. I just don't like ice tea.

I returned to the main room for "Ruby in the Cloud" by Mike Subelsky:
Mike had his start-up running on a single server when he realized he was running out of space. Faced with the choice of more servers, managed hosting, or the new and exciting "cloud" of EC2 he chose the cloud. Mike claims that it only took a few hours to build the server images and then only 20 minutes to migrate the code to be able to run all cloudy style. In case you don't know, EC2 is a service offered by Amazon that lets you rent servers by the hour. You create a virtual image and fire one up as needed. They can bust at any time, and won't be repaired, so plan for redundancy. Why would anyone put up with that? Because it's crazy cheap and very scalable (Need more servers? Just fire up more and get a bill)

They made decision to use Ruby for all their server management. They used: Capistrano, Rufus-scheduler, God, FileUtils, Rush, Rake and a bunch of plain old ruby scripts.

Mike spent some time talking about how cool and readable rufus-scheduler can make your scheduling. Think of the last cron you wrote and compare it to this:

scheduler.every "10m10s" do
#stuff
end

Nice.

The big win of using Ruby everywhere is decreased context switching, leveraging of knowledge in Ruby, and OS portability.

Dinner was brisket. This would be the second night in a row I've had brisket. With any luck I can go 3 for 3.

The first keynote was given by Evan Phoenix and it was about memes in the Ruby community. Apparently, the Ruby community loves a good meme.

Dependency injection was a rash in 2004 caused by Java developers. DI wasn't needed, sez Evan, because of the very nature of Ruby (as you can define stuff as late as you like).

Another meme: What's this called:
class << self; self; end;
metaclass, singleton-class, or eigenclass?

Then he discussed the Singleton Pattern which he claimed was almost always a bad idea (more blaming of the Java folks for bring it up) and always bad for testing

Aspect Oriented Programming was a big topic for awhile. (He said that alias_method_chain is all the AOP you really need)

Evan discussed _why the lucky stiff as a meme. There's so many rumors about _why. Who is he and what he does he do when he's not dropping off excellent Ruby code in the middle of the night?

"Chunky Bacon" is a meme in its own right.

Here's a somewhat exhaustive list of other memes he talked about:

  • Zed Shaw
  • git
  • Ruby is too slow
  • Macintoshes
  • TextMate
  • Rails can't scale
  • Pixaxe
  • Ruby CPAN
  • rubygems vs rpa
  • ARGV parsers
  • DSLs
  • BDD
  • RSpec Backlash
  • Metaprogramming is cool

Evan's take on all this was that the Ruby community loves to have fun. It's a very light on its feet community. This can scare a lot of enterprisey people, but he finds it awesome.


The second keynote of the night was given by Matz on Ruby's "Past, present, future"

I always find it hard to sum up Matz's presentations. They are funny, inspirational, and touching in a way that doesn't lend it self to summary. You come away with the feeling that this man really wants to write a language that will make you a happier person.

Topics he discussed include:
  • Why Ruby is simple, but not too simple (or Ruby vs Lisp)
  • Interpreters
  • 1.9 features
  • 2.0 notions
  • The primary goal of Ruby is to enjoy programming
Then he graciously answered questions for 30 minutes. And got a standing ovation.

1 comments :

Brian said...

Hi Jake, thanks for attending my session (RubyCocoa). And thanks for presenting yours, I enjoyed it.

I just wanted to reply to one thing:

> Also the drag and drop stuff kinda freaks me out...

IB has been around since 1988 and a large majority (80-90% (guesstimate)) of all the apps you run on your mac were built with it. It's pretty solid.

As far as developing with it: It does take getting used to and can be difficult to debug if you forget what you wired up, but I think it's very much worth it.