Sunday provided a wonderful conclusion to RailsConf 2008. Here are some brief notes for the sessions I attended to whet your appetite with links to their RailsConf pages (where you can grab slides).

Waxing Ballroom Floors on the Titanic (and Other Less Seaworthy Vessels) - Rick Bradley, Yossef Mendelssohn, Kevin Barnes (OG Consulting) (RailsConf page)
Plugins:
object_daddy
timely
shmemeter
autochronic
freshtrack
nihilist_bot
flame

Genomes on Rails - Matt Wood (Wellcome Trust Sanger Institute) (RailsConf page)
Frequently and rapidly changing data

• Don’t have fields – store data as Descriptor/DescriptorValue objects (key/value pairs)
• With careful indexing it’s not that slow
• If one field is consistent across versions, that can be added to the db
• Can map Descriptors between different versions

They specify task the same way and allow users to create pipelines for various projects
Throughput: Data → 320tb/450 cpu cluster → Archive (2 Petabytes of data)

• Multiple instances of multiple applications (loosely coupled)
• Deployment is difficult because you need to push to all your instances
• reverse proxying with fairnginx in front of mongrels, deploying with cap

The Profitable Programmer: Creating Successful Side Projects - Geoffrey Grosenbach (Topfunky Corporation), Tom Preston-Werner (Powerset, Inc.), Chris Wanstrath (Err Free), PJ Hyett (Err Free), Ben Curtis (Catch the Best) (RailsConf page)
Project Ideas:

• Build something simple
• Build something you want to use
• Take something that’s already popular in one area and move it to one where it doesn’t exist

Implementation:

• Build it yourself
• Sub-contract

Promotion:

• Allow free accounts with limited, but useful functionality
• Piggyback on already established people and sites
• Form symbiotic relationships with existing sites
• Drive traffic to their sites
• Promote their product through yours

Success:

• Don’t listen to critics as you go through issues while expanding
• Try to build apps that are a source of constant income and require little effort to maintain
• Avoid VC → basically just getting a boss

Notes:

• Donationware? Ads?
• Ads are tricky because you have to become a marketer
• Market Research
• Track how people interact with the app and not how they say they interact or are going to interact with it
• Try to do something where its easy to get to people you want to sell to
• Think about how often people will use it (including you)
• Keep in mind who’s actually going to be paying for it

That's it. What an amazing conference. Can't wait until next year!

More nuggets:

Advanced RESTful Rails by Ben Scofield (Viget Labs)
Pick out the nouns from your app to determine the resources
Decide what methods to expose to those resources
Ajax actions generally use middle man which is a join model

Fast, Sexy, and Svelte: Our Kind of Rails Testing Dan Manges (ThoughtWorks), Zak Tamsen (ThoughtWorks)

Unit Test

• one method or object being tested at a time
• Avoiding Unit Test Britleness:
• gem “unit_record”
• ActiveRecord::Base.disconnect! keeps tests from hitting db
• To avoid db you could use fixtures (Difficult because you need to go back and forth to the fixture file)
• Or you could construct the object

Functional Testing Speed

• Gonna be slower – involve more objects and hit the db
• DeepTest speeds up functional tests
• Read DeepTest gem ReadMe to set up distributed tests – SUPER FAST!

Integration Tests

• Sometimes useful for special purpose tests
  • performance tests
  • smoke tests
  • tests simulating multiple users

Acceptance tests

• Better for low levels of granularity
• Selenium RC – way to control the browser
• Writing Acceptance Tests:
  • Encapsulate Pages
  • Data Access:
    • Can use Factory again to create entries
  • Parallelization – multiple Selenium RCs

Integration Testing with RSpec's Story Runner by David Chelimsky (Articulated Man, Inc)

• Process
  1. Feature Injection
  2. Focus on outputs
  3. Acceptance Criteria – if tests pass, customer accepts it
• Popping the “Why?” stack – ask “Why?” until value comes out

Integration Testing:

• Make sure the component parts play nice together
• Automated User Stories/Scenarios
  • Document the expected behavior of the system
  • Verify that behavior by executing a thin vertical slice of the system
  • Narrative Format: identify goal, user, action
  • Should test edge cases!
    • ex. goal of 200, 1 should return 1% and 199 should return 99%
  • Store DOM in memory
  • manipulates DOM
  • builds POST from DOM

Webrat Ruby gem (http://github.com/brynary/webrat)

Selenium RC (lets you test JavaScript/AJAX & you can watch it!)

• Because it’s slow you should only use for AJAX and use Webrat otherwise
• Multiple Sessions

The Great Test Framework Dance-off by Josh Susser (Pivotal Labs)

• RSpec for the structural level
• Shoula for test cases
• Test/unit for assertions
• Refactor with shoulda

Let's talk about the nuggets. Quick note though - I heard the complaint that the talks weren't technical enough. I don't particularly agree with that criticism. There's only so much you can cover in 45 minutes or whatever it is so I think the real purpose of most of these talks was to show us what's out there and it's up to us to dig further. My two cents. Anyways, the nuggets:

"Multi-core Hysteria": FUD about CRUD? by Andrea O.K. Wright (Chariot Solutions)-
Learned Mongrel mechanism for handling concurrent threads
def initialize(dir, meme_map = {}{
@guard = Mutex .new
}
Mutex Doc
Got this little forking snippet:
walking = fork do
100.times do
puts “walking”
sleep 1
end
end

chewing = fork do
100.times do
puts”chewing”
sleep 1
end
end

Surviving the Big Rewrite: MOVING YELLOWPAGES.COM to Rails by John Straw (YELLOWPAGES.COM) -
(This talk was awesome for me personally as it dealt with moving a large, established Web site to Rails)
Why the move? Absolute control of URLs (of utmost importance for their site), stateless HTTP, being agile & writing less code
His team and their development process which was pretty cool: ~20 people (5 core developers), sat together, 3 week (approx.) cycles - 1 week wireframe development, 1 week UI design, 1 week+ development
Web Service performance issues they tackled:

• Slow page performance caused more by asset download times than speed of web framework
• Worked through the Yahoo! performance guidelines
• Minified and combined CSS and JavaScript with asset_packager
• Moved image serving to Akamai edge cache
• Apache slow serving analytics tags – moved to nginx for web tier

Also, they debated about other technologies (Java/EJB3, Django) but eventually chose Rails because, well, it's the bomb.

CRUD Doesn't Have an 'S' in It: Managing Complex Searching in Rails by Stephen Midgley (Hutz.com)
4 architectural steps (in order):

1. POST/GET Params representing Search Criteria
   • e.g. ?s=search_parameters
2. Merging Search Criteria with persistent criteria
   • Session/backend, hidden input tags or on the URL line
3. Converting Search criteria to Search Rules to SQL
4. Paginating the Search & Render

I loved this: For clean URLs use POSTs. Make sure your URLs are distinct for core search options. If your URLs aren’t clean, you’re doing it wrong!!!

1. Clean: http://mysite.com/find-vacations/p/1/United-States/Califronia
2. Not Clean: http://mysite.com/controller/action?wtf=is&all=this

You want to store your SQL in an object so that you can pass it around

1. This makes writing your Search Rules more modular
2. Doesn’t have to be session (maybe you want searches sshared across users?)
3. Caboose::EZ

SQL Tools

1. EZ-Where
2. Squirrel
3. Sequel

Alright so that's what I got for Friday. Saturday and Sunday coming soon...

**Please see my follow-ups on individual days: Friday, Saturday, Sunday**

RailsConf 2008, two words: passionate and fascinating.

I met so many people over the past 3 days who are absolutely in love with the work they're doing. I met pod/screencasters Gregg Pollack (Rails Envy Podcast), Ryan Bates (Railscasts), Chistopher Haupt and Michael Slater (Learning Rails), and Geoffrey Grosenbach (Peepcode & Ruby on Rails Podcast). Everyone's familiar with their work I'm sure, but needless to say their depth of knowledge and eagerness to help out and get others involved was amazing. I've got a whole list of tips & tools for podcasting and screencasting now and several friendly contacts to help me along the way. I met Evan Phoenix, Brian Ford, and Wilson Bilkovich from Engine Yard who are the lead developers of Rubinius. Their presentation was great and I feel like I have a much better understanding of why Rubinius is important and useful. And I'm actually itching now to get commit rights (it doesn't take much!) I also met David Chelimsky, fellow sports fanatic and RSpec guru. We had a really interesting 5 minute chat about the new story runner feature in 1.1 and I'm really excited to explore ways to integrate it into my development process. And that's just the tip of the iceberg! There are about 20 other people I had conversations with, learning about their projects, what tools they use, what they like (love) about developing with Rails, what they don't, etc etc.

And all of the talks were so interesting! There was a nugget or two (or six) of programming goodness in literally every talk I attended. I'll expand on the talks I attended in more depth coming up, but needless to say there wasn't a single striking disappointment among the bunch. They were all fascinating, which of course is a direct by-product of having so many people doing something they're so invested in and that's so much fun to do.

In Conclusion,

Can't wait for RailsConf 2009!