Rails 2.0 (i wonder how long until the trolls think Rails 2.0 is a Rails mash-up or something) brings with it lots of new features, polish, fixes and sexy, here are some of my favourites:

• Namespaces in ActionPack
• Seperation of view-type and renderer (ie. show.html.erb or show.html.haml)
• Automagic record routing: form_for(person)
• HTTP Authentication baked in!
• Request Profiler
• Sexy Migrations, say a big thanks to err.the blog for this one
• ActiveRecord XML deserialization and JSON serialization
• ActiveResource (like AR for REST api’s)

There are (obviously) tons more features to the release, i suggest you check out the official announcement as well as Ryan’s awesome post. Happy coding bitches!

it relies on the requested path to work out how to split the breadcrumbs, it alsoo requires that every component of your path is accessable, should be a good starting block though.

  def breadcrumbs(sep = "»", include_home = true)
    levels = request.path.split('?')[0].split('/')
    levels.delete_at(0)

    links = "You are here: "
    links += content_tag('a', "home", :href => "/") if include_home

    levels.each_with_index do |level, index|
      links += " #{sep} #{content_tag('a', level.downcase.gsub(/_/, ' '), :href => '/'+levels[0..index].join('/'))}"
    end

    content_tag("div", content_tag("p", links ), :id => "breadcrumb")
  end

Community

RailsConf rocked, so much more than I could have hoped for an so many levels, the content was brilliant the people were amazing, organizationally the thing was a stunning success and what was achieved by the community and what was achieved by many people on an individual basis was amazing.

The feeling was very community focused, the Rails community has grown exponentially over the past year, and this was definitely reflected in the mix of and volume of people. I spoke to at least hundred Java developers, as well as some .NET folk and a whole mix of people from other languages. All here to have a little look at this web app frame work written in this crazy Ruby language.

The numbers as well, this year there were over 1600 people in attendance, last year 500, the year before there was no conference. In one year Rails as a community has grown so quickly, many many people are getting wealthy off the back of it, and I think this was Chad’s point on the first day, if we were all to use that for good, we can show the rest of the IT tech, hell the world, we can show them that we can make a difference. Well I think we were all listening, last time I checked we had raised over $33,000 in donations.

The community, as well as the framework have grown and matured, and it’s good to see companies like Adobe, Sun, O’rielly and Amazon making their presence at this conference for a framework only 2 years old.

Enterprise

As larger companies start to pay more attention to us it’s important to make sure we are ready to deal with what the enterprise world wants, through projects like JRuby and others.

Although this is good, in a way, I hope Rails will maintain it’s Opinion as it is spun off in all sorts of directions. It’s a little bit over my head if truth be known. But interest from larger companies can only mean good right? Probably wrong? I don’t know.

Enterprise anxiety was definitely a strong theme running the conference.

REST

REST was covered heavily at RailsConf also, there were over 4 separate talks on the subject. This is important I guess, as we hurtle towards Rails 2, REST is going to become more and more central to what it is the core team are thinking.

Plugin’s like Hamilton’s make_resourceful have already started popping up all over the place and getting knowledge on it all know while it’s still all EDGE-centric, is going to prove really useful down the line. DHH’s keynote actually helped to clarify one of my biggest concerns, nested resources, or something. Either way I have a better understanding of it all now.

RailsConf was an amazing experience, something I wouldn’t have changed. The best thing to come out of the whole thing was meeting 3 wonderful human beings, Anthony Ramm, Dan Tripp and Jeremy Sydik. You three are amazing, Thank You for making the experience so welcoming and warm.

To summarize, I’ve met some amazingly talented, clever and inspirational people over the past 4 days. I’ve felt the power of the community to truly do something amazing and make a real difference, and above everything I’ve left with 3 brilliant friends.

Roll on RailsConf 2008.

The Rails Way

Jamis Buck and Michael Koziarski of the rails core team presented a rundown of some of the more common questions they get asked on the Rails Way website.

They sorta tackled the thing from a tag-team perspective, each taking it in turns to walk through a page of code and give lots of great advice.

There was an irc channel you could post questions to whilst the talk was going on, these were answered at the end.

The thing I found really valuable was with_options stuff for routing, I’m totally gonna be re-writing some killer route files.

Take this for example:

 map.create_message "/msg/create/:id", :controller => "message", :action => "create"
 map.create_message "/msg/edit/:id", :controller => "message", :action => "edit"
 map.create_message "/msg/delete/:id", :controller => "message", :action => "delete"

And turn it into this:

 map.with_options :controller => "message" do |msg|
   msg.create_message "/msg/create/:id", :action => "create"
   msg.delete_message "/msg/edit/:id", :action => "edit"
   msg.delete_message "/msg/delete/:id", :action => "delete"
 end

I think it’s much clearer, and way more descriptive.

Choose Your Battles and LetIt::REST

This was Hampton’s talk about REST (there was lots of REST talk at RailsConf) this one was more about implementation than theory, or practice. Which was good. It also took from the perspective of the current REST code in EDGE (unlike Vonage). Again refreshing.

The focus was on a new plugin they had developed (ham an the guys at unspace) originally called letItRest, now renamed make_resourceful. The plugin addresses the amount of duplication necessary to implement a RESTful interface, it seems to be a bit like a scaffold/code-generator type thing, which is cool, and although we’re promised it’s very easy to still get your edge-cases/exceptions in there, I can’t help but wonder how it “feels”. I’m definitely going to give it a go though.

The talk it’s self seemed over quite quickly, there were some funny slides, which helped break up the code slides, the pace was good and Hampton is a great talker.

Rubber, Meet Road

Amy Hoy’s talk focused on finding the comfortable place between designer and developer to let communication flourish, as well as touching on the two mindsets, how they work together, how they fight and why.

Amy (like myself) is a programmer with a designer background. This was really useful for me to help identify the thought patterns in my mind that are clearly designer and those that fit squarely in the dev head box. It also helped to reveal how far work (as in my 9-5, not just work in general) has yet to go to be truly productive.

The talk itself was very fun, lots of funny slides, some jokes and healthy dose of sarcasm. Great fun.

Dave Thomas’s Keynote

Dave Thomas’s ending keynote was good, i’d like to say I was paying him 100% attention but me and ant were buying domains for an upcoming project I’m going to be collaborating with him on.

From what I can gather the keynote was about community, charity and cargo-cult mentality. It ended with Dave asking us all to have fun. Which is cool.

After the final keynote was a meet and greet in the reception area, me, ant dan and jeremy ditched in favor of mexican and beer. Awesome.

Bring Ruby to the Enterprise. Not the Other Way ‘Round

Cyndi Mitchell’s opening keynote was very good, although the community may not like It (in certain circles) there Is a need to educate and support enterprising companies about the virtues of rails/ruby.

Cyndi’s talk was very well paced and touched on some humorous comparisons between pop culture and tech-industry, some of her slides were awesome too. A good start to the day.

Tim Bray

Tim bray’s keynote was again on rails / enterprise, sun’s position on It, his passion for It. To be honest a lot of went over my head, I was really tired. That guy seems awesome though.

Custom Rails Helpers: Keeping Your Views DRY

The first session of the day focused on DRYing up your views with custom helpers, this was cool, not from a “i’m learning something new” perspective, more from a “I do this already, I’m so glad I’m doing right”

Although the session taught me nothing new, It did validate a lot of the work of been doing on helpers, so It felt kinda cool. was very busy.

Memcaching Rails

Chris Wanstrath, of err the blog fame (that’s where I heard of him anyway) presented this talk.

It focused on the probleming of caching, and his solution cache_fu. It was a really Insightful session with some wicked slides, and chris himself Is super animated, which Is always good.

It left me with enough knowledge to know where to start with caching, that Is when I need It.

The Dark Art of Developing Plugins

This session was really cool, It walked through making a simple plugin and was themed like a horror flick. wicked.

The really Insightful stuff was about ruby, extending and overwriting and all that jazz, was way cool. that class_eval method Is some crazy ass ninja kung fu.

Makes me wanna wrap up some common stuff Into plugins now.

Data Warehouses with ActiveWarehouse

This was way more high brow than I was expecting, and although I was following along alright top begin with, as soon as the concept of cubes and dimensional data aggregation started I had to walk.

But If the need every came along to churn through piles of data and make It relevant, this would be my starting post.

The day ended In a chinese restaurant, with my sipping beer from a tea cup.

Chad Fowler’s Intro

The day kicked off with chad fowler opening the keynote with an important message: “Everyone thinks we are a bunch of arrogant bastards.” People laughed at this at first, but as he kept talking what he was saying become apparent, as our community grows more and more of us are becoming wealthy off the back of rails it becomes important to prove to the rest of the world that we can make a difference.

It was an important message, there are nearly 2000 people at RailsConf and if we each donated $100 to the Pragmatic Studio’s Charity of Choice we can prove to people that we can change the world.

Or something.

DHH’s Keynote

David’s keynote was good, the focus was on Rails 2, recapping the features introducing some minor new features, and indicating which features are going to be removed.

One of the things he highlighted which definitely got me excited was some further clarification on and enhancements to the way that RESTful routing works, my biggest gripe with that was admin/backend routing and implementing REST in all situation.

This has been cleaned up a lot and you can now namespace your RESTful routes / resources.

Another neat thing was the respond_to stuff, it now seems (i might be wrong) that this has become transparent in detecting and routing mime types. which is nice.

ActiveResource looks sweet. It’s going to be replacing ActiveWebService and is completely focused on consuming REST interfaces. REST is one of the main focuses of Rails 2, it’s the new opinion, if you’re going to be devleoping an app, it should be REST routed, APIs should be based on REST. Good opinions.

respond_to :voice

This was the first session of the day, at it fucking rocked.

It was an introduction to using the Asterisk PBX with rails, using a new plugin called Telegraph.

I looked into Asterisk a while ago, and the AGI config files are just horrible, hundreds of lines of extraneous repetitive code. nasty.

Telegraph takes these AGI/AMI config files and wraps them in clean MVC ruby code. The thing that really got me going was the possibilities, the guy gave some demo’s and it’s really exciting. The general idea is that you can take your rails app and another interface for your users to interact with it in. Voice, using Asterisk and Telegraph will allow you to have your app call out to people, have people call in, consume data over the phone, maintain session data between the web and the phone network (super sweet).

I really cant wait to get going with it.

Doing Rest Right

I really really wanted this to be good. It wasn’t. Although it was insightful, and gave some brain food to chew over, it was a bit high-level and philosophical. I left early.

Apollo

This talk was kinda good, although not really Rails-centric, it was a nice introduction to the new Adobe cross-platform runtime for Flash/Flex/HTML/JS/PDF apps.

The really interesting thing is that all of the separate technologies supported inside of the runtime are treated as first class citizens with a common cross technology DOM to use.

You could basically have an Apollo app with an HTML viewer, and Flex/Flash component side by side, and cross-script between the two of them with a common DOM. Very neat.

Flex in general is something that I really need to get into (again)

Avi Bryant’s Keynote

Avi Bryant has been in and out of the Ruby community for a while, he’s a smalltalk advocate that works on the seaside project.

His talk was focused on the future of ruby, performance etc.

It was kinda good, a prompt to think of the future of our language. meh.

Ze Frank’s Keynote

Ze Frank, simply put is the fucking funniest thing ever. His keynote was more of a stand up comedy routine, with slides. The topic was accelerating anxiety.

I really can’t explain how good it was, you just have to google some of the stuff this guy has done. It was the perfect end to the day.

Intro to Test Driven Development with Rails

This tutorial was awesome, presented by David Chelimsky this really helped to solidify my understanding of TDD, as well as touching on and clarifying some aspects of Rspec.

The pace was good and the tutorial didn’t seem long enough, there was lots of good discussion and the code examples were great.

Part of the tutorial featured us “Pair Programming” (a practice from eXtreme Programming (XP)) The basic concept is one person writes a failing test, then the next writes just enough code to pass that test, then writes a another failing test for the previous person to fix, gradually the code is written and tested and passing mechanisms are refactored into useful clean code.

It was a really great exercise and provided a lot of value.

Harnessing Capistrano

The second tutorial of the day was presented by Jamis Buck, the creator of Capistrano and core member that works at 37 Signals.

I was really looking forward to this tutorial and although offered a lot of insight into the new feature of Capistrano 2.0, it was a little slow and dry.

I guess it’s kind of difficult to get excited about something without having a hands on experiance (there was no code writing in this tutorial) but it definitely left me with some ideas.

The day ended with Dan Tripp, Ant (another brit from Birmingham) and myself having dinner, drinking beer and talking g33k in a mexican joint downtown.

Getting here was easy, Portland has a tram system called the Max Light Rail, it’s free for most of the city, and only took like 20mins.

There are a lot of people here already and I expect there will be even more tomorrow.

Portland is a beautiful city, I could honestly see living here, image paris without the dirt and smog, make the roads and paths wider, take away the awkward angles and turn them into blocks and you have portland. Why paris? The trees, image the Champs-Élysées only every block is like that. It’s really beautiful, I had a good wonder around yesterday, the sine was shining, the trees were green, it was lovely. A woman at the airport told me that portland has the feel of a big-town rather than a city. She was right.

My hotel (the hotel lucia) is stunning. drop-dead-gorgeous. I also found a fabulous all-male designer underwear shop called Under U 4 Men, I dropped like $200 dollars in the already and I know I will go back.

All in all I’m having a great time so far.

The way these tools work by default they only allow you to deploy one instance of your application, which is fine, that’s all they’re are intended to do. But in the client facing world you’re probably going to want to have at least two versions of the same application at different stages of development running on the same server.

A live forward facing version (my-app.com) and a staging version (staging.my-app.com) for client approval / production testing (not code testing, that should stay on your development box) / progressive reviews etc.

So how do we achieve that? The idea is to determine what context you are deploying your application in, and use the fact the capistrano tasks can be chained together to set everything up ready for deploying a revision of your application to a targeted url, independent of other deployments.

Step 1

The first thing to do is to require the railsmachine recipes and setup some variables, as you will see later some of these variables are redundant, and the code has a fair bit of duplication, but this is a work in progress and I hope to clean it up when I have some more spare time.

require 'railsmachine/recipes'

set :application, "my-app"
set :deploy_to, "/var/www/apps/#{application}"
set :main_domain, "my-app.com"

set :user, "deploy"
set :repository, "svn+ssh://#{user}@my-svn-server.com/var/svn/#{main_domain}/trunk"
set :rails_env, "production"

role :scm, "my-svn-server.com"

You’ll notice that I’m keeping my my project on separate svn server, by default the railsmachine gem will create an svn repo for you as part of the project tree, this is really useful at first, but when you’re deploying multiple instances of the same application you’re going to want your svn repo independent.

Step 2

Now comes the clever bit, creating the tasks which will be called before our regular cap commands, like so $ cap -a staging deploy (which would deploy the current revision of your application to the staging server)

desc "Set staging instance variables"
task :staging do
    set :application, "my-app-staging"
    set :domain, "staging.my-app.com"
    set :apache_proxy_port, 8010
    set :database_yml, "database-staging.yml"
    set :deploy_to, "/var/www/apps/#{application}"

    role :web, domain
    role :app, domain
    role :db,  domain, :primary => true
end

desc "Set production instance variables"
task :production do
    set :application, "my-app-production"
    set :domain, "my-app.com"
    set :apache_proxy_port, 8000
    set :database_yml, "database-production.yml"
    set :deploy_to, "/var/www/apps/#{application}"

    role :web, domain
    role :app, domain
    role :db,  domain, :primary => true
end

What this does is set all of the variables which any command you’ll call after staging or production will need, it’s pretty ugly at the moment and I hope to clean it up and make it a lot smarter, but for the moment it works, and in it’s ugliness it does make it clear what it’s doing.

Step 3

Next we overwrite the railsmachine setup_scm task and one of the tasks it calls, we’re doing this because we are using a custom location for our repository and not the one which the railsmachine gem tries to create for us.

In my particular situation I have an external server used for svn, but the repository could just as easily be on the same server as your application just so long as the folder you create the repo in is in the deploy group. Also in my situation I am creating a new repo for each project I deploy, if you already have a repo that you deploy all projects to you could easily just remove the setup_svn_repo task call from the setup_scm task.

Enough talk, on with the code:

desc "Setup svn repository"
task :setup_svn_repo, :roles => :scm do
  dir = "/var/svn/#{main_domain}"
  run "mkdir -p #{dir}"
  run "chmod 770 #{dir}"
  run "svnadmin create #{dir}"
end

desc "Setup source control server."
task :setup_scm, :roles => :scm  do
  setup_svn_repo
  import_svn
end

Step 4

Because different instances of our application are going to need different databases we have to overwrite the method which read’s in the database configuration when setting up the database for the first time. The way it works at the moment we also need to remove the database.yml file from svn control, and recreate it from the correct file after every code update.

task :clean_db_yml do
  puts "removing database.yml from svn"
  system "svn remove config/database.yml"
  puts "ignoring database.yml"
  system "svn propset svn:ignore 'database.yml' config/"
  system "svn update config/"
  puts "committing changes"
  system "svn commit -m 'Removed and ignored database.yml file'"
end

def read_config
  db_config = YAML.load_file("config/#{database_yml}")
  set :db_user, db_config[rails_env]["username"]
  set :db_password, db_config[rails_env]["password"]
  set :db_name, db_config[rails_env]["database"]
end

task :after_update_code, :roles => :app do
   correct_db_yml
end

task :correct_db_yml do
  put(File.read("config/#{database_yml}"), "#{release_path}/config/database.yml", :mode => 0444)
end

Thats all there is to it, I run the following commands to set up an instance of my app:

cap -a staging setup
cap -a staging setup_scm
cap -a staging setup_servers
../[new directory]
cap -a staging clean_db_yml
cap -a staging cold_deploy
cap -a staging restart_web

cap -a staging deploy
cap -a staging deploy_with_migrations

The End

There you have it, it works, it’s not the most elegant solution and definitely something I want to work further on. The last section with database.yml stuff is by far the ugliest, but it is a work in progress, and I plan to make further amendments to it.