Jake Scruggs

writes ruby/wears crazy shirts

I was talking to a friend of mine the other day and he mentioned that his wife had been turned down for some dentistry that she needed performed. It turned out he had been paying for family dental coverage but his company had only signed him up for single. Once the mistake was realized, his company corrected the error. He might have to re-fill out some forms, and her surgery will be delayed, but all will be put right.

I mean it was a simple mistake, how could he possibly hold it against them?

You can spend lots of dollars on big gestures, perks, and what-not but it can all be wiped away by a bit of faltering on the basics. People need to know that the ground beneath their feet is solid -- That they can trust the people who employee them to take care of certain details. When that trust is shaken they start asking themselves questions about other things.

It reminds me of Maslow's hierarchy of needs:

Maslow's hierarchy of needs is often depicted as a pyramid consisting of five levels: the four lower levels are grouped together as being associated with Physiological needs, while the top level is termed growth needs associated with psychological needs. Deficiency needs must be met first. Once these are met, seeking to satisfy growth needs drives personal growth. The higher needs in this hierarchy only come into focus when the lower needs in the pyramid are satisfied. Once an individual has moved upwards to the next level, needs in the lower level will no longer be prioritized. If a lower set of needs is no longer being met, the individual will temporarily re-prioritize those needs by focusing attention on the unfulfilled needs, but will not permanently regress to the lower level. For instance, a businessman at the esteem level who is diagnosed with cancer will spend a great deal of time concentrating on his health (physiological needs), but will continue to value his work performance (esteem needs) and will likely return to work during periods of remission.
Which is a long winded way of saying that if you don't nail the small stuff your grand plans are all for naught.

I used to be a High School physics teacher and so people often ask me why I left teaching and to become a programmer. You'll get a different answer from me every day you ask that question, but today's answer is Sunday nights.

When you find yourself picking fights with your wife, kicking the cat, and generally needing a few drinks every Sunday night it's because you know there's a week of pain coming. This pain may or may not materialize but there's a fair percentage that it will. Once, when I was a teacher, I had a 6'3'' football player in my class who would sometimes take to getting up and screaming at me. One time, after an altercation about talking in class had turned into a huge blow up, he pushed past me on his way out of the room. Now getting knocked aside by someone who could probably kill me in a fight wasn't a daily occurrence in teaching, but that's not the point. The point is that after that day it was always a possibility in my mind. There were other altercations in my 7 years of teaching and each added a little more weight to my Sunday nights. Toward the end of my time as a teacher the mass was unbearable. My job was making my non-job time painful so I had to leave.

Angry Sunday nights mean your job is beginning to smell.

Something I didn't mention when I announced the re-launch of metric_fu as a gem is that now, because it's a gem, you have more options when installing it in your project.

First option:
Vendor Everything. Lots of people are big fans of unpacking gems into the vendor directory of their Rails project (or a similar folder in a non-Rails project) so that everyone who checks out the code gets the right version of the gem. You can then require it in your Rakefile like this:

require 'vendor/gems/jscruggs-metric_fu-0.7.6/lib/metric_fu'


Second option:
Conditionally require the gem. When I announced metric_fu back in April, a lot of commentors bemoaned the fact that they would have to install something into their production code that wasn't really necessary for production. I don't really mind doing this as metric_fu does not modify any classes: It's mostly just a bunch of Rake tasks (and some report building code). However, I see their point. So if you don't want to put metric_fu into your project, you can simply make sure the gem is installed on your CruiseControl machine and then conditionally require metric_fu in a rake file like so:
begin; require 'metric_fu'; rescue LoadError; end

So anyone who has the metric_fu gem installed on their box can run the reports, while keeping everything else pure.

I recently discovered Caffeine for the Mac and it's pretty cool. When I'm giving presentations, listening to streaming audio, or performing some operation where I don't want my mac laptop going to sleep I could mess with the system preferences... Or I could click on a friendly little coffee cup to tell my computer to stay awake. When the coffee cup is full, my computer won't go to sleep or activate the screen saver. Empty coffee cup means my normal preferences are in control. Nice!

Many thanks to Todd Webb, for pointing this out to me.

Yesterday, I talked about the first half of the first ever Windy City Rails conference that happened on Saturday at IIT. Tonight, I'll pick up where I left off with my summary of the presentations I attended.

Virtualization and Elastic Servers -- Yan Pritzker of CohesiveFT

The gist of this talk is that the Rails stack is not well known so why not let CohesiveFT handle deployment for you. It's a virtualization factory, that lets you put together a custom Rails stack and they can deploy and maintain it for you for as little as 10-15 bucks a month. Also, he pointed out that virtualization is a solution for your front end guys getting a working version. Which, having tried to get many a design person's computer up and running, I think is a pretty cool idea.

Ten Things I Hate About Web Apps by Micah Martin

Short list of things Micah hates about Web Apps:

  • You need to know css, html, js, and the actual programing language just to get started.
  • Html -- only 3 fonts to chose from
  • Css is not implemented the same on browsers
  • Javascript and will it be supported
  • Multiple browser support
  • The Photoshop dependancy (why should rounded corners and gradients be so hard?)
  • The statelessness of http
  • Flash/silverlight are not open source
  • Ruby on Rails -- a pretty mask on top of the ugliness

His solution is Limelight -- A platform for writing rich ruby apps. It's all Ruby all the way down. He showed off a simple demo of how easy it is to create apps with Limelight. Then he showed a tower defense video game his brother wrote using Limelight. It looked pretty cool, but it's very audacious to propose a new platform.

Slight of Hand for the Ruby Man by Aaron Bedra, Relevance

I missed a bunch of this presentation 'cause I'm a dumbass. The cool thing I did manage to see is "the-inspector" which is a gem that can tell you where some monkey patcher has redefined a method. So you can call this:
Inspector.where_is_this_defined {Klass.method_to_find(:something)}

Very cool. Check it out at: http://github.com/spicycode/the-inspector

The Morph App Space lightning talk was next.
Morph can help you deploy RoR in five minutes, it's fully managed, and elastically scalable for $1 a day.

Rails Security by Aaron Bedra, Relevance

Aaron talked about using Tarantula to crawl your app and attack it. It's particularly good at finding cross site scripting and sql injection attack vulnerabilities.

There are a number of solutions to preventing cross site attacks (aside from remembering to use 'h' everywhere):

His general recommendations for security:
  • Keep your framework up to date
  • Build security from the ground up
  • Audit your code

Test Last Development -- Noel Rappin, Pathfinder

Regular TDD is Red-Green-Refactor and yet it often goes wrong and Noel spent some time talking about typical ways in which it does.

  • People often skip the refactor step -- he calls this test driven mess as TDD is supposed to be about design
  • Data driven testing -- fail the test, get the output, then put into test
  • Code then test -- Which useful in exploration, but it's easy to slip. It also leads to coverage gaps
  • Test last development -- when you check in without tests and then later try to wrap tests around your code.

Noel uses two coverage suites:
  • One models only
  • And the other is everything else

He does this because controllers hit models a lot so they can hide lack of model coverage in tests.

Generally, I had a great time at Windy City Rails. I think Ray Hightower and everyone involved did an amazing job pulling this together.

This weekend was the first ever Windy City Rails Conference and I was lucky enough to not only attend but also to speak. I thought I'd sum up the talks I attended in case anyone was interested.

After Ray Hightower, lead organizer of the conference, welcomed everyone Ryan Platte gave the first talk of the day: "Outside the sweet spot"

Ryan's talk was about getting Ruby and or Rails into a large organization which is committed to things like: Windows, Oracle, etc. I.E. not the typical Rails stack.

In Ryan's experience, Rails makes it's way into such an organization the following way: Some guy picks up a Rails book and says "Hey, this is way better than the excel spreadsheet we've been using." Then he talks one boss into the project, and maybe they hire some consultants to help. However the rest of the organization has issues with Rails (it's slow, not compatible with their stack).

Ryan's advice is:

  • Do top quality work quickly -- get out in front of criticism by having good early results
  • Communication -- talk to everyone
  • Model, model, model -- Spend some time on the soul of your application
  • Get to know the legacy tech and why it's there. Find out what will the people who wrote it feel about the changes? What will they hate. And what will they like. Get those arguments ready.
  • Use rest - it looks cool to the technical users

  • There's a temptation to add all the cool whiz-bang stuff Rails can do/is known for. Throwing in the kitchen sink is a good way to doom your project.
  • DBA's talk in SQL and will often times will refuse to run Ruby migrations.
  • While JRuby is cool - testing Ruby with object dependent on Java Objects means you'll have to test in JRuby and spinning up the jvm is slow.

Up next was Rails Q&A with David Heinemeier Hansson

This first question was about performance in Rails. David said this has been a big effort for 37 signals over the last few months and his advice is to optimize http first: gzip, minify js (use yslow to find problems. There's a google presentation about it you should see). There's a common problem with devs, they think about code speed first. 80% of rendering time of a page is http stuff. Code is only 20%. They are working on putting these into Rails. Ex: timestamping of assets (gotta set up your server to use this).

David said that a 200 millisecond response is the sweet spot for the user to feel like your web app is fast.

He talked a bit about Rails 2.2 thread safety -- good if you use JRuby or 1.9 (David thinks thread safety is optimizing the 20%)
I asked David whether Rails will be implementing any features from Ruby 1.9 that will force people to upgrade to a new Ruby. He said that there are absolutely no plans to abandon 1.8 support. There has been an effort to get Rails to run on 1.9 which is near completion. As for the speed boost of 1.9 (and YARV) he's only seen a 20% speed improvement in real world Rails examples.

David wants to pull out validations into their own thing (and you can add them into your own models) and he spent a little time talking about that.

There was a question about observers and David said the he thinks they are kinda are old to him as he uses now uses memcached so he's ripping out all his observers from his code. Expiring caches is a very hard problem and he really digs how memcached makes things easier.

Dave Hoover asked what David would have done differently if he had the last 4 years to do over again. David said he's not real big on regrets. He went on to say that if you had tried to do all the things you now know you would have to do, you never would have started. It would be too daunting. When he started Rails it was a 1000 or lines of code. Very doable. David is not a big fan of retrospectives.

Internationalization was like the 3rd feature requested ever. And it's a very hard problem. So they thought about it for a few years and let the people who really care about it sort it out. The Rails core team didn't much care about internationalization and they weren't experts. In this case the committee actually worked.

Asked about what he was excited about, David talked about memchached, http (the creators showed lots of foresight), and document databases (couch db and it's ilk)

David said that people often make the mistake of thinking that 2000 users is hard and so is 1 million so why not go for 1 million. They don't get that the scale of hardness is way different for 1 million. Basecamp was out for a year before it could even pay people's salaries. You win by staying in the game. Many companies self destruct trying to get too big too fast.

Then it was time for Dave Hoover's (of Obtiva) lightning talk. He admitted he was stealing from Uncle Bob's 2008 Agile keynote as he talked about software craftsmanship. Which was weird as I was sitting next to Micah Martin -- Uncle Bob's son. Dave cited the analogy of doctors washing their hands vs getting started on surgery. There was a time when hand washing was viewed as a needless use of time for a busy doctor. And we face the same problems as developers: Deliver features vs refactor/write clean code. Obtiva is trying to be about craftsmanship.

Well, that's all I feel like typing tonight. I'll wrap up the rest of the presentations tomorrow.

I just released version 0.7.6 of metric_fu and there's all sorts of new stuff:

First, MetricFu is now a Ruby gem on GitHub at:

Also, the Flog task can now flog any set of directories you like. Just put this into your Rakefile:

MetricFu::DIRECTORIES_TO_FLOG = ['cms/app', 'cms/lib']

And, the Flog reports are much nicer:

The Flog report generator now looks at a MD5 hash of the files its examining to determine if they files need to be re-Flogged -- which saves time.

The Saikuro report generator can also look at custom directories like so:

MetricFu::SAIKURO_OPTIONS = {"--input_directory" => '"cms/app | cms/lib"'}

MetricFu started its life as a Rails Plugin, but I'm trying to turn it into a flexible gem that can be used in any Ruby application (but still have defaults that enable easy use in a Rails project). Eventually I'd like to create something that could tell you about methods that have high complexity (Flog and Saikuro scores) but low test coverage. But that's going to be a challenge. Feel free to help, if you like.

I'd like to thank Sean Soper for contributing a ton of work to this project. He's responsible for the gemification, the new Flog reports, and the MD5 hashing. And David Chelimsky was nice enough to come over and personally show me around git and GitHub.

Try it out with:

sudo gem install jscruggs-metric_fu -s http://gems.github.com

While checking out at the hotel I ran into Coby from confreaks.com They are recording the conference so you'll be able to see the talks online sometime soon. They're not cheap, but their videos are very good (they capture the output of the presenters computer and display it side by side with video of the presentation -- you seriously need to check out their site), and they offer a discount if the conference is willing to CreativeCommons license the talks.

Starting off the morning was "Ruby: A Year of Innovation" with Gregg Pollack & Jason Seifer. They had a lot to cover so it went pretty fast. I tried to keep up as best I could.

Jason Seifer was up first:

  • HPricot - awesome for scraping websites
  • Juggernaut - server push with rails -- keeps a connection open
  • Ambition - write your SQL statements in Ruby
  • Prawn - Ruby based PDF generation
  • Capistrano
  • Ruby VMs
  • roo - spreadsheets Excel, google docs
  • Dtrace and Ruby -- memory stack live
  • Skynet - map reduce for Ruby
  • Data Fabric - easily shard your db with rails
  • Merb - the non-opinionated framework
  • Mack - Framework
  • Sinatra - good for restful
  • Webby - good for static websites
  • Shoes - dsl for gui apps
  • Hackety Hack - coding for kids

Gregg Pollack took over and talked about:
  • Redmine - Trac replacement in Rails
  • Pool Party - cloud computing config and maintenance in Ruby
  • Rad - robot control
  • Adhearsion - Voip
  • Rack - if you have a Ruby process you want to run on Mongrel, Thin, or whatever you just write one handler for Rack.
  • Phusion Passenger - servers up anything that supports Rack (including Rails)
  • Github - source control where you can see what others have done with your code and merge it back in without the modifier having to submit a patch (as they often forget)
  • make_resourceful and resource_controller - are two ways to puts resource handling in your controller
  • Starling - lightweight reliable message passing
  • EventMachine - Executes processes in one thread instead of trying to slice everything up. Works great for short tasks.
  • NeverBlock - can run SQL in parallel
  • Screencasts - Railscasts, PeepCode, PragProgrammers, EnvyCast

"Using jQuery with Ruby Web Frameworks" with Yehuda Katz

Yehuda used screwunit (a BDD javascript test framework) to BDD an implementation of a live updater in JQuery (which is an alternate Javascript framework). He had trouble with getting his tests to fail (some sort of caching problem). That's rough in front of a 100 people. JQuery and screwunit look interesting, but I found it hard to focus on what he was doing ignore the difficulties of getting specs to pass. He finished his presentation with a declaration that you should never attempt to do a live coding presentation.

I thought it might be nice to step out of my comfort zone and take a look at "Resource-Driven Web Development With Waves" presented by Dan Yoder. Alternate title: "When Functional Programming Meets HTTP"

So, why use waves? Well, you can have more control over your app, use functional programming, and be very RESTful. Waves has Functor as much of its processing. It helps matching requests to response actions. You can have some pretty spare code that defines a bunch of restful paths.

Things that don't fit anyone else:
  • I heard that there's such a thing as Chicken Fried Bacon. Where the hell has this been all my life?
  • Joe O'Brien's wife likes to say "Holy wow"
  • It was freezing in the conference center and 97 degrees outside. This is very Texas.
  • There was this clearing throat guy who would loudly clear his throat during every presentation. It totally caught me off guard when I was talking as I thought I had just said something terribly stupid. After my talk I noticed all the other presenters had the same reaction.
  • Where are all the ThoughtWorkers? I saw lots of ex-ThoughtWorkers but no current ones. All the cool kids must have gone to Rails Conf Europe, I suppose.
And now for Lunch. Which is Chicken fried Chicken.

(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.


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


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.

First, I'd to extend a big thanks to Joe and Jim for giving me a ride to the conference today.

The two tutorials I decided to attend today were:
"The Advanced ActiveRecord Workshop" with Gregg Pollack & Jason Seifer (the Rails Envy Guys) and "The Ins and Outs of Ruby I/O" with James Edward Gray II and Gregory Brown. Both of which were excellent.

The Advanced ActiveRecord Workshop covered:

  • Loading large data sets (the 'ar-extensions' gem helps lots).
  • A gentle reminder to properly index your freakin' database.
  • How Rails optimizes multiple :includes in finds and how that goes to hell if you combine lots of :includes with :conditions
  • The super awesome Named Scopes (which you need to look up right now, if you haven't already because it's not just about defining custom finders -- it's about defining custom finders that you can chain together and get optimized queries)
  • Polymorphic Associations, Single Table Inheritance, Dirty Fields, Association Proxies, Callbacks, and creating AR plugins.
I was really impressed by the smoothness of their presentation. It was a great balance of funny/informative/challenges. The challenges were a good way to make the audience think about what had just been presented. If I had one criticism it would be that the later challenges seemed too hard for the time allowed. I found that if I made one stupid mistake (which I then had to track down) I would not finish by the time they gave out the answers. I suspect they were rushing to finish on time. Overall it was great stuff and they say that this talk was an elongated version of their recent EnvyCast on ActiveRecord so I would say that it is definitely worth your 9 bucks.

The Ins and Outs of Ruby I/O was also very informative. Since Ruby has such easy file IO it's easy to forget about the underlining structures and the problems that can crop up. Topics include:
  • The most efficient way to read in a file (generally foreach)
  • Random access inside a file
  • Overcoming buffering problems with file.fsync || file.flush (fsync returns nil if it doesn't work)
  • A resonably through regex explanation
  • A compare and contrast of how to handle unicode on Ruby 1.8 vs Ruby 1.9
  • How to use Marshall or Yaml to serialize your objects.
The talk was being video taped so I assume it will show up on confreaks which, btw, is my new favorite site. You can see the whole freakin Ruby Hoedown on there. And you really should check out Rick Bradley's "flog << Test.new" talk. He takes Flog, forks it into a new project called Flame, puts it under spec, and refactors it to be less complex (nice bit O' irony there).

Later we had some excellent Bar-B-Q at Rudy's and discussed how the hell the Ruby world is going to migrate from 1.8.x to 1.9. We had no good solutions. The Bar-B-Q was excellent, however, so we left in good spirits.

Tomorrow I'll be speaking at 1:30 on "Using Metrics to Take a Hard Look at Your Code" so I'm pretty excited as this will be the first mass presentation of this talk and I think its turned out nicely.