We love Gollum, the new Sinatra based wiki product from Github. It's still a very new product, and in its current state it's really only useful for running a personal wiki server. So we spent a few hours hacking it about a bit and came up with two handy articles for Gollum users:
* Howto: Run Gollum under Passenger & Apache
* Howto: Use Github to authenticate your Gollum users
Enjoy!
We are big believers in the Agile philosophy and so were delighted to come across one of the best online project management tools we've seen in years at PivotalTracker. Of particular interest is its powerful and growing list of integrations. We prefer Jeff Tucker's integration with git but there are also integrations with Lighthouse, Zendesk and Jira. Highly recommended.
Rails provides us with some handy features to use when optimizing page downloads: Asset Servers and Asset Caching. Combining these features with a Content Delivery Network (CDN) and minification will result in much faster page download times. Making all four work together though can be tricky. This is how we did it.
Asset Servers are a way of telling Rails to host all your graphics, css and scripts somewhere else. This way the server actually running your app isn't burdened by hosting static images and stuff. It's simple to setup, just add this line to your environment.rb and you're done.
ActionController::Base.asset_host = "http://assets.yourdomain.com"
You can get your assets onto this new node by setting up a Content Distribution Network. The most popular option here is the pay-as-you-go Cloudfront product from Amazon. It's simple to setup, the only tricky part being the need to keep your public folder sync'd with Amazon. As usual with Rails this has already been done for us. If you use Capistrano you can setup a recipe to auto-sync your assets on each deployment.
Asset Caching combines multiple css & javascript files into a single file, speeding up your page downloads significantly. It's also very easy to do, just add :cache => true to the end of your javascript_include_tag and stylesheet_include_tag entries in your layouts.
Minification compresses your scripts and css files into the smallest possible space. For CSS this is simply removing comments and extraneous spacing, but for javascript this has been taken to a whole new level, shortening variable names and other advanced stuff. It can really reduce your file size: the production (19K) version of Jquery is 6 times smaller than the development (120K) version.
This technique used to be a pain to maintain as you needed to keep lists of your scripts and/or run rake tasks. This led to all kinds of dead ends when you debug some new feature and forgot to update your minified version of your scripts. The Smurf plugin fixes all of this very nicely indeed, but also introduces some problems (see below).
The biggest issue is that the Asset Helper that implements caching & asset servers doesn't play nicely with itself. The caching mechanism creates a new combined file rather than processing the files on every request (which is sensible) but this file typically won't be on your asset server. As it's implemented you're left to choose between using an Asset Server or Asset Caching. The issue was pointed out two years ago when the features were first implemented (see here and here for instance) but the obvious solution - ignore the Asset Server setting for cached files - has yet to be implemented as far as we can tell.
Our solution was to hack it thus:
ActionController::Base.asset_host = Proc.new { |source, request|
if source.include?('all.js') || source.include?('all.css')
"#{request.protocol}#{request.host_with_port}"
else
"#{request.protocol}assets.yourdomain.com"
end
}
This checks to see if the file being processed by Asset Helper is one of the cached ones. It's a definite hack, and we'll improve it (e.g. so it looks for any file in the cached directory maybe) but it works fine for now.
The other thing is to check the cache & compression settings on your CDN. With Cloudfront it's very difficult to compress or optimize the cache settings.
Not everyone will want to do all of the above. In particular, if you are currently compressing your graphics and getting a big boost from this you'll want to find a CDN that supports gzipping. I suspect Amazon will provide this at some point.
Whatever you decide to do, it's important to test the results and check you are actually running faster. Safari has a good tool for this built in (see Developer Tools) and Pingdom provide a cool web page we used extensively in putting this article together.
Our testing showed up that we were providing 169K of scripts with each page! This was for Prototype and it's associated eye-candy and was being pulled in automatically by the instruction javascript_include_tag :defaults We swapped it out for javascript_include_tag 'application.js' and saw a 160K drop in page size which will make a difference to even those on a fast connection.
We use a number of analytics tools here including the ubiquitous Google Analytics and encountered a strange problem. We turned on the overlay feature (where G-A overlays boxes showing which elements got what percentage of clicks) but then couldn't turn it off! Even when we clicked 'close' on the overlay, it still kept coming back. Opening the page in another browser made it go away in that browser, but the problem remained with our original browser. Clearing the cache and the Google cookies didn't work either.
It took a bit of Googling to figure out what was going on. When you enter Overlay mode the Google Analytics web bug drops a cookie in the domain of your site. This cookie is called 'GASO'. Delete it and the problem goes away.
Hopefully this will save someone else a half hour.
One of the projects we are working on here at Tecnh is a reworking of a site from PHP to Rails. A big part of this is migrating the data from the old system.
John Beynon at his blog Confessions of a code Junkie covers the basics very well in this article. The steps are pretty straightforward:
We tweaked John's original article in two ways. First, we had so many php tables that we put all the legacy models in a a separate folder for each group of tables. This prevented them from cluttering up our shiny new Rails app.
Secondly, we had to wrap the base class declaration in the second step with a module statement as follows:
module LegacyPapers class LegacyPapers::Base < ActiveRecord::Base self.abstract_class = true establish_connection "papers" end end
Now you can access any of your php tables like it was a Ruby model. You can take this even further, for example you can associate these legacy models with each other or even your new models. We plan to use this feature to associate an old record with its migrated replacement, so we can see which records got cutover and which ones didn't (oldrecord.migrated_record.nil?)
All in all this part of our project was much easier thanks to this very neat feature of Active Record.