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

Judging by Josh Catone's post and its comments
There is No Web 3.0, There is No Web 2.0 - There is Just the Web, people really don't like the terms "Web 2.0", "Web 3.0", and the like. But I'm not sure I fully understand why.

If it's because people have a natural aversion to labeling anything, I can somewhat agree with that. Determining the definitive characteristics and exact point of inception of a fluid event like the evolution of the Web into "Web 2.0" is difficult. Being hesitant about focusing too much on nomenclature and not enough on application is also somewhat valid. The more time spent arguing about what the web is, the less time building applications for it.

But ironically in avoiding or vehemently opposing labels such as "Web 2.0" in order to focus one's effort on producing real output, one may become less efficient and effective because he or she has unwittingly denied that there wasn't a drastic shift with the internet as we know it. And by not recognizing pertinent aspects of the current web and its shift from previous incarnations, one is less apt to deal with the next major shift. And there is definitely going to be another big change in the internet and its use, most likely pretty soon - that has to be taken as a given at this point. And by studying the web today, which I think can be correctly named "Web 2.0", and its variance from the initial incarnation of the web, there are some key lessons to be learned.

First, increased bandwidth opens doors. When we were all using dialup, static html pages were all we could handle. I can definitely recall visiting huge pages on my family's 500 series Mac via AOL dialup and completely crashing my Netscape browser. The kind of interactivity available today just wasn't possible with yesterday's internet. Today around 3/4 of the country has broadband internet access so sites are able to deliver that much more data to the user and not have it take 3 hours. This completely changed the UI philosophy of the web and today the intricacy of the average user experience is exponentially greater. Now with that in mind, if the average internet speed jumped from 1MB/s to 10MB/s, what would that mean for the actually look and feel of the internet? Something pretty drastic right? Imagine an experience like the one seen in this recent TED talk.

Secondly, massive amounts of data have completely changed the way we consume information. I haven't opened an encyclopedia since College (ordering OED Compact Edition soon however). Web 2.0, despite a few niche mashups, is mostly about the quantity of information. And now that the amount is there, I definitely think Web 3.0 will be about integrating these stores of data even more intricately. Not just simple mashups, but gigantic, intelligent search engines and maybe even *gasps* the beginnings of true artificial intelligence.

Finally, there's a (somewhat shocking) move towards openness going on. In the first iteration of the web personal outlets were somewhat minimal. We had chat rooms and personal web pages - mine was on Tripod and was a Gators fan site. Web 2.0 has brought us, of course, social networks and the importance of building "networks". I think Web 3.0 will involve the creation of complete online personas, distributable everywhere. This ties in to the sharing of information touched on in point 2, but on a more personal level. It will involve sharing personal information, social data, favorite pieces of web content - basically everything you do that involves the web - on all the sites you visit. Clearly this'll bring up questions of privacy, safety, etc. but it seems to be the way the web is moving.

Obviously there will be other changes than the ones listed here, but I think these will be drastic enough that the web will look totally different from the web of today. And when something evolves out of something else, taking on different characteristics and unique features, we generally label it as something other than the former. In this case, the label will be "Web 3.0"

In Conclusion,

I CAN'T WAIT!

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!