has_many :thoughts

Below is the schedule I came up with when going over the sessions available this year at RailsConf… Going to try to make these, if not switch with Colin so we cover the conference well… very glad to see some advanced classes! Would have loved a REAL advanced Rspec session though.

8:30am Thursday, 05/29/2008
Meta-programming Ruby for Fun & Profit Portland Ballroom 252
Neal Ford (ThoughtWorks), Patrick Farley (ThoughtWorks) Ruby is the revenge of the Smalltalkers. Not since Smalltalk has a language had such powerful meta-programming facilities. While this may seem like a minor feature, it turns out that surgical meta-programming allows solutions to problems that are clearer, more concise, more maintainable, and take orders of magnitudes fewer lines of code. Read more.

1:30pm Thursday, 05/29/2008
Powering AIR Applications with Rails Portland Ballroom 252 Tony Hillerson (EffectiveUI), Daniel Wanja (Nouvelles Solutions, Inc.) Adobe’s AIR platform offers developers familiar with web technology the tools to create desktop applications. Come and learn how to drive an HTML and a Flex AIR application with Rails using RubyAMF. Read more.

10:45am Friday, 05/30/2008
Entrepreneurs On Rails Portland Ballroom 251
Dan Benjamin (Rails Machine) Many of the people working with Rails are independent developers, doing freelance work or running small development shops. This makes sense – Rails provides a great framework for an indy developer, making it easy to work with with designers and other developers. Read more.

11:45am Friday, 05/30/2008
Hosting and the Woes Portland Ballroom 255
Ezra Zygmuntowicz (EngineYard), Jamie van Dyke (Engine Yard), Tom Mornini (Engine Yard) What are the day to day issues with Rails hosting. How can they be solved, and what are the best practise methods of avoiding them. Engine Yard have extensive experience with high volume Rails applications and would like to talk about what we’ve learned and what our customers have learnt. Read more.

1:50pm Friday, 05/30/2008
Faster, Better, ORM with DataMapper Portland Ballroom 256
Yehuda Katz (EngineYard) This session will cover using the DataMapper ORM with Ruby on Rails, and go in-depth into its code. It will focus on integration with Ruby on Rails and provide an advanced-level overview of the codebase and design philosophy. Read more.

2:50pm Friday, 05/30/2008
Rubinius – Under the Hood and Behind the Curtain D135-136
Evan Phoenix (Engine Yard), Brian Ford (Engine Yard), Wilson Bilkovich (Engine Yard) Rubinius is a virtual machine built from the ground up to provide a robust, high-performance runtime for Ruby code. The Rubinius team is guiding the development of 20,000+ specifications that define the Ruby language. Read more.

4:25pm Friday, 05/30/2008
The Launch: Dos and Don’ts of Real Life Deploys Portland Ballroom 255
Chris Wanstrath (Err Free) There’s more to launching an app than “cap deploy”—the process is as much a psychological challenge as a technical one. So, what does it take to launch an app you can depend on and be proud of? With a handful of production launches under his belt, Chris will talk about the big picture and little details of bringing your site to life. Read more.

10:45am Saturday, 05/31/2008
Assembling Pages Last: Edge Caching, ESI & Rails Portland Ballroom 256
Aaron Batalion (Hungry Machine LLC) When working on scaling Rails to millions of users/day with complex personalization, caching becomes essential. This talk will cover edge caching, edge side includes (ESI) in Rails, and partial page caching higher in the stack. It will also cover ESI as a fabric for assembling heterogeneous applications into a single, cacheable web experience. Read more.

11:45am Saturday, 05/31/2008
Advanced RESTful Rails Portland Ballroom 252
Ben Scofield (Viget Labs) Designing RESTful systems in Rails carries many benefits. It is not a problem-free approach, however; there are accessibility issues with the standard conventions, and some functions are more difficult to map to resources than others. In this session, we’ll look at solutions for these (and other) problems that arise when you take REST beyond the standard examples. Read more.

1:50pm Saturday, 05/31/2008
Build Your Own Distributed, Self-Configuring Rails Cluster Portland Ballroom 251
Dave Fayram (Powerset, Inc), Tom Preston-Werner (Powerset, Inc.) Fuzed is a Rails server stack written in Erlang that can replace standard mongrel/reverse proxy architectures. It focuses on reliability and ease of deployment in distributed environments. Read more.

2:50pm Saturday, 05/31/2008
Custom Nginx Modules: Accelerate Rails, HTTP Tricks General Portland Ballroom 251
Adam Wiggins (Heroku) Got a Rails app that needs even more speed? Adam Wiggins of Heroku will show you how to write a custom Nginx module to bring blinding speed to critical code paths (and do HTTP tricks that can’t be done with Rails and Mongrel alone), using examples from Heroku’s own authentication module ngx_heroku_gate. Dust off your C compiler and prepare to push the limits of nginx, Rails, and HTTP. Read more.

4:25pm Saturday, 05/31/2008
Metaprogramming and Ruby Internals for Rails Programmers Portland Ballroom 256
Patrick Farley (ThoughtWorks) Rails programmers are Ruby programmers. In this session we’ll cover some useful Ruby metaprogramming techniques as used in real world Rails applications and extensions. Then we’ll dig deep into MRI and JRuby source to gain a nuanced understanding of the implementation details of Singletons, Mixins and the Ruby Object model. Read more.

10:45am Sunday, 06/01/2008
Scaling Ruby from the Inside Out Portland Ballroom 252
Ezra Zygmuntowicz (EngineYard) This is a talk about what it takes to really scale Ruby applications. We will not only examine all the aspects of hardware and web server configurations, we will also look at scaling the ruby interpreter itself. Including performance quirks of MRI and how Rubinius is set to fix a lot of these problems. Read more.

11:45am Sunday, 06/01/2008
Everyday DTrace on OSX: A Guide To Using DTrace for Your Full Application Stack Portland Ballroom 251
Scott Barron (EdgeCase), Chad Humphries (EdgeCase) Have you ever wanted to know why a part of your application is slow? How about how long that query takes? Wouldn’t it be nice if you could get this type of information for ruby, rails, and the database server in one place? You can now with DTrace on OSX 10.5. We’ll show you how to best use this tool-chain to debug, profile, and gather more information about your application. Read more.

1:50pm Sunday, 06/01/2008
Building an app in 48 hours – A Rails Rumble Case Study Portland Ballroom 251
Josh Owens (Intridea, Inc/Web 2.0 Show Podcast), Chris Selmer (Intridea, Inc.) So you want to build a Rails app quickly? Competitors in the Rails Rumble had 48 hours to design, develop, and deploy a complete application. We’ll take you through the development processes of the winning four-man Tasty Planner team, and compare it with those of the one-man Your Pet Records team. We’ll discuss techniques, short-cuts, helpers, and Rails plugins that helped speed development. Read more.

I especially love Ruby because I can quickly customize it to my tastes and likes. With out regard for anyone else’s feeling but my own. With that said, I do try and use this power for good. For the better of my office mates.

Earlier today I was doing some of this…

describe Admin::ModelsController do
  shared_examples_for 'all admin pages' do
    code code code here...
  end

  describe 'when logged in' do
    more specific controller specs here...
  end
end

...and I thought to myself that I would really just love to do this…

describe Admin::ModelsController do
  it_should_behave_like 'all admin pages'

  describe 'when logged in' do
    more specific controller specs here...
  end
end

Loading it from some separated out module underneath the specific MVC spec/ sub directories.

I’ll explain more in a second… but using some code I was working on before, thanks to storing it in Yojimbo, I quickly wrote this into my spec_helper.rb…

Dir[File.dirname(__FILE__)+'/**/shared/*'].each { |group| 
  require group
  include Object.const_get(group.match(/.*[\/]{1}([\w]*)[.rb]./).captures.first.camelize)
}

As you can tell from the code, it will go through all sub-directories of the current one (RAILS_ROOT/spec in this case) and rummage for “shared/” directories. It will then try and load modules, within these files, named after the file’s file name.

Without having to require and include each single file/module throughout your spec files (or the parent spec_helper).

Examples:

module AllAdminPages
  shared_examples_for 'all admin pages' do
    code code code here...
  end
end

Of course this is a smallish hack that I think really cleans out my specs. I generally got the idea from app/views/shared or app/views/layouts/shared directories in Rails. Keeping small shared view partials in separate, nicely organized sub-directories.

Let the flaming commence! j/k ;)

Like many, I was disappointed that the Highrise API does not support tagging of people. However, I found a way to easily add the capability to the 37signals-supplied Ruby wrapper class, even if it is unsupported. I added a #tag! instance method to the Person class and used a call directly to the site, not through the API.

class Person < Subject
  ...
  def tag!(tag_name)
    `curl -s -d 'name=#{tag_name}' #{ENV['HIGHRISE_URL']}parties/#{id}/tags`
  end
end

The output is a bunch of javascript to update the page to reflect the change, but one can safely ignore this. The tag is added and everything works great. Not sure how well this would work on Windows, as the curl command-line program is likely unavailable.

We use this method in our latest project to add appropriate tags to people as they are created. It helps us segment people added to Highrise for the project from the rest of our contacts in Highrise.

When I first heard about Thin I was slightly intrigued, but less enthusiastic when I attempted to run it (not sure what version). Anyway, now that Thin has matured a bit more, and Merb 0.9 is bringing the love of Rack to the masses… I’m really really really starting to see what all the fuss is about. 3000+ requests a second of fuss.

The Skinny

Thin is actually a mash-up of current back-end web serving technologies.

1. the Mongrel parser, I’m speculating its the Ragel executable state machine portion
2. Event Machine, and the tough, concurrent service request handling of the Reactor Pattern
3. and Rack, our new hero which brings a common web server gateway interface to all of our favorite Ruby web frameworks.

Fancy technologies (and citations), but how’s this going to help good’ole Geoffrey Grosenbach?

Installation

$ sudo gem install thin

...or if you know what your doing…

$ git clone git://github.com/macournoyer/thin.git

If not, go directly to FAIL…

Show’em Some Ruby

Lets take a quick glimpse at the adapter example that is included with the gem (examples/adapter.rb).

I’ll try not to ramble on about Rack too long but… This really shows you how damn simple it can be to plug and play applications into a Rack stack, and the power that Thin brings along with its speed!

require File.dirname(__FILE__) + '/../lib/thin'

class SimpleAdapter
  def call(env)
    body = ["hello!"]
      [      200,  
        {
          'Content-Type'   => 'text/plain',
          'Content-Length' => body.join.size.to_s,
        }, body
      ]  
   end
end 

Thin::Server.start('0.0.0.0', 3000) do  

  use Rack::CommonLogger

  map '/test' do    
    run SimpleAdapter.new  
  end  

  map '/files' do    
    run Rack::File.new('.')  
  end

  run Rack::Adapter::Rails.new(:root => ‘/Users/justin/apps/whatsyomammabeensmokin.com‘)
end

Very briefly, this example is a thin/Thin adapter specification and server initialization. Its also an insanely small example of a Rack adapter (which may, or may not work; reference the real examples in the gem).

We can see, after loading our necessary library file, we create a class used as an adapter, called SimpleAdapter.

This holds in it a means to handle status code 200 requests. With a simple output of plain text content-type, set in its header hash. It also includes a simple body of text, “hello!” to be returned as content. Literally the Rack adapter, handling a request, need only return this sort of array as a response. [status, header, body].

Finishing up the script is Thin’s server stack initialization. Resembling a Rack config.ru configuration file, Thin initializes a server for our localhost on port 3000. As well as some middle ware setups using our SimpleAdapter.

First, inside the setup block you should quickly notice a few “map” method calls that resemble Rails routes. “map” is actually just that, a simple way to set Rack::URLMap’s, or web URI paths, inside the main server start block.

Second, the “use” method actually adds middle ware to the stack.

Finally, notice “run”. This literally dispatches middle ware logic to the server.

I’ve taken the liberty of adding a call to a local Rails application to point out how easy it is to include new applications straight into a running Rack/Thin server stack. Pretty much just as easy as it is to “include” a mix-in into a class in Ruby.

If you would like to work more closely with some real code, take a look here…

Thin Rails

Ok… woosh, back to the easy stuff…

Since Thin supports Rails natively through what I believe is an included Rack adapter… you can start playing with it right out of the box on any of your current Rails projects.

Once you have the Thin gem installed, simply do a…

$ thin start

If you’d like to explicitly set your Rails environment…

$ thin start -e development

“—help” provides more information as usual. Thin’s main site has a lovely amount of info with a beautiful web design. Be it tiny lil text (get it, thin).

You can also try out a middle ware script that comes with Thin called “stats”.

$ thin --stats=/public_thin/stats start

This will give you a technical details of your Thin server stats, map’d to “localhost:3000/public_thin/stats”.

To Deployment, and Beyond

I have yet to really attempt a deployment with Thin, but I have one coming up shortly to assist with and will definitely be trying this out.

From what I’ve read you can just as easily replace mongrel_cluster with thin like so.

# thin config -C config/thin.yml --servers 3 --port 5000 --chdir ...
# thin start -C config/thin.yml

If anyone has tried this yet please let me know how it went.

The Year 2000

Hopefully your interested now and will check into this speedy fast Mongrel replacement. Did I even mention it was fast…? >;)

In the near future I’ll attempt to report back on deployments and middle ware scripts. I’m eager to see what useful little apps I can come up with that sit between the web server and my actual Rails application. But I can imagine 8 bazillion possibilities (especially logging and transparent statistics harvesting).

So yeah… cheers to the author!!

Justin had an idea that we should post to Twitter whenever we deploy a new version of our apps to either a staging site or the production app. Turns out, this is really easy with the twitter4r gem. I used a twitter account that Justin created expressly for our internal notices and set its updates to be private. Then I created this task:

desc 'posts to twitter that something was deployed'
task :send_tweet do
  require 'rubygems'
  gem 'twitter4r'
  require 'twitter'
  require 'twitter/console'
  twitter = Twitter::Client.from_config('config/twitter.yml',rails_env)
  status = twitter.status(:post, "deployed #{application} to #{rails_env}")
end

The twitter4r library loads a simple yaml file that contains the username and password of the twitter account to use. And one line of code posts the status update with the name of the app and the environment from previously-defined variables.

That’s it! The great thing about using Twitter for this, as Justin pointed out, is that each one of us developers can consume this information how we choose: IM, Growl messages with Twitterific, SMS, etc. So it’s really just the syndication technology that we’re taking advantage of.

Update

Chris’s comment below prompted me to come up with a new version

This is another one of those things I learned way too late:

$ gem environment

... tells you a bunch of things about your environment. Including where your gems are installed. Handy! It’s the little things like this that can make one so much more productive.