We're at Euroko in Prague, with some of the guys at New Bamboo. It's been pretty good so far (crippling flu aside) and Prague is a lovely city.

I gave a talk today on Aspect Orientated Programming in Ruby using Aquarium, it quickly covered what I mentioned in my last post on AOP, and went into more detail with actual code examples this time!

The slides are on slideshare, the demo code is currently in a git repo . The demo app is Merb/Datamapper and I'm currently trying think of more examples of cool aspects to put in there, feel free to add some.

If anyone saw my talk, I'd love to hear what you thought of it so drop me a line matt@new-bamboo.co.uk or leave a comment on this post.

| View | Upload your own

I’ve just spent the last week at QCon and I’ve just about fully recovered (it was pretty intense). Considering there was only one Ruby track I was a little worried that I wouldn’t find most of the talks interesting, however this wasn’t the case. The most interesting talks had very little to do with Ruby.

When I go to conferences, my main goal isn’t to learn lots of things it’s to be inspired and generate new ideas, consequently my “things to do in my spare time” list has grown exponentially.

The two underling themes that I detected from the conference was developers are people too and scaling is important. It was interesting to hear Java guys talk about how to make developing easier (more fun), because this is one area Ruby (in my opinion) excels over most other languages.

One of the main criticisms about the Ruby community is we don’t care about scaling, and scaling is something that the Java guys have been working on for years. So when Ola Bini says that JRuby will be the best stack/platform around, I’m starting to believe him.

Imagine having your Ruby app with objects persisting in something like Terracotta?

Or being able to use existing Java aspects on Ruby code (and visa versa).

There was talk about GemStone porting their Smalltalk VM to Ruby so we may have an ‘enterprise’ stack.

And where the hell are the Ruby Specs? I mean the tests for the language itself. There should be one central repository where YARV, Rubinius, JRuby, GemStone and every Ruby developer out there can contribute to Spec’in out the language.

They are just a handful of ideas that popped into my head. I had a great time at the conference and met many interesting people, hopefully I’ll be able to do it again next year!

The slides (videos soon) from the talks are going online so take a look. Please excuse me while I go play with Erlang.

UPDATE I’ve put some of the slides that are available on the QCon site onto slideshare tagged with QCONLONDON2008 , enjoy.

| View | Upload your own

First a simple solution using throw_content and catch_content.

This is what sublayout.html.erb looks like

<% throw_content :sublayout do %>
  <div class="header">
    ...
  </div>

  <%= catch_content :for_layout %>

  <div class="footer">
    ...
  </div>
<% end %>

<%= render catch_content(:sublayout), :layout => "application" %>

Your main layout contains <%= catch_content :for_layout %> as usual.

You might find it handy to use catch and throw content in a few more places. For example, in your sublayout you could <%= catch_content :sublayout_title %> and throw it in the view with

<% throw_content :sublayout_title %>
  Hippos
<% end %>

As a little bonus I wrote a helper so that you can use the same syntax as you're used to from the rails plugin. Just add this snippet into Merb::GlobalHelpers

def inside_layout(layout, &block)
  content = render(capture(&block), :layout => layout)
  concat(content, block.binding)
end

Then your sublayout looks like

<% inside_layout :sublayout do %>
  <div class="header">
    ...
  </div>

  <%= catch_content :for_layout %>

  <div class="footer">
    ...
  </div>
<% end %>

Here's another idea which I think would be even better: What if you could say layout ['application', 'sublayout'] in your controller and have each layout rendered inside it's parent all up the chain? Then sublayout.html.erb wouldn't be constrained to always render inside application.html.erb and you could use it in a much more flexible way. However Damien things it's a mad idea. What do you think?

Frozen gems in Merb == gems installed inside the application.

That's clever because now you can use the standard tools for installing and managing the installed gems. For example, you get dependency checking and so on for free. Add -i gems to the command line options to specify the install location.

gem install merb-core -i gems

That's the simplest case (run it from the root of you merb app). It fetches the merb-core gem from the gem servers and installs it inside a gems directory.

However, in many cases that's not what you want. Really you want to freeze the version you're currently developing on. Maybe one you've installed from the merb-core git repository. That's really easy because you have the gem package files on your system already. For me they're in /Library/Ruby/Gems/1.8/cache. Get your location by running gem environment gemdir and look for a cache folder. Install the package with

gem install /Library/Ruby/Gems/1.8/cache/merb-core-0.9.1.gem -i gems

You should add /gems/doc to your .gitignore since you definitely don't want ri and rdoc files in your repository. Alternatively add --no-ri --no-rdoc to the gem install command.

The final challenge is actually getting merb started. Right now I'm relying on a pastie that google found for me (I'm sorry I have no idea who the author is). Make that executable and use it to run merb with the usual merb command line options. That's surely a bit of a hack though and I'm hoping that someone will point out a better way :) Update: Thanks Steve - I hadn't spotted the generator. Run merb-gen freezer frozen-merb and then run Merb with ./script/frozen-merb passing the usual merb command line options.

I'm assuming that you're using private key authentication for git and that you've got an ssh agent set up (if you're running Leopard then you automatically have this).

The trick is to use ssh agent forwarding, now supported in capistrano. It allows the server to pull the latest code from github using your local private key and ssh agent. To understand how this trickery works take a look at this illustrated guide.

set :ssh_options, { :forward_agent => true }

One of the great things about git is that it's really fast, even if you're cloning an entire repository. However you can go even faster by using the repository_cache option in capistrano. This essentially keeps a clone of your app on the server and then just does a git pull to fetch new changes and copies the directory across when you deploy.

set :repository_cache, "git_cache"
set :deploy_via, :remote_cache

Another recommended strategy is to specify a git branch. Otherwise you'll default to deploying HEAD which might be some crazy experiment.

set :branch, "stable"

In case you haven't used remote branches they're really easy. Say you have a local stable branch. Push this to github using

git push github stable

So the complete capistrano file should look something like

set :application, "your cool app"

# Source code
set :scm, :git
set :repository, "git@github.com:githubusername/gitrepo.git"
set :branch, "stable"
set :repository_cache, "git_cache"
set :deploy_via, :remote_cache
set :ssh_options, { :forward_agent => true }

# Deployment servers
role :app, "your server"
role :web, "your server"
role :db,  "your server", :primary => true
set :deploy_to, "/var/www/#{application}"

In the past year we've probably gone through about 3 different wikis. Either they don't have things like email notifications with a diff, have their own special markup language or cost what is unwieldy amount for just a wiki.

We've scrapped all of these and have now migrated to a private Github repo containing markdown files managed with the help of the Textmate Wiki Bundle. The simplest solutions are the best.