Media72 Hosting Articles and Tips

We have now installed Ruby on Rails 2.1.2 on all servers. As this release contains security fixes it's recommended that all users of Rails 2.1.x switch to the new 2.1.2 version ASAP.

Rails 2.0.5 has been release which contains security fixes. It's advised all customers using a 2.0.x version of Rails update their applications to use the 2.0.5 version as soon as possible.

It's been a little over two months since we switched our Ruby on Rails hosting packages from FastCGI to mod rails (Phusion Passenger), what better time then for a debrief on how the switch went and what we have discovered two months on. I'm sure no one will be surprised to hear mod rails is far superior to FastCGI in pretty much every way. Firstly the initial switch, for the most part it went very well, nearly all rails applications worked exactly the same under mod rails as they did FastCGI. A very small number of applications had issues, all of which were easy to fix within a few minutes. Overall the switch went very smoothly only requiring an apache rebuild and the mod rails installation. Initially we started using the 1.x branch of mod rails, with a large number of rails applications running we noticed Apache would locking up periodically and require a manual restart. This issue only occurred on production servers running many rails applications and was not apparent on our test servers. The problem turned out to be fairly wide spread on servers with a lot of traffic. The Phusion Passenger guys were quick to respond to feedback and remedied the problem with a 2.x beta release. Since upgrading to the 2.x branch of mod rails it's been rock solid!

What benefits have we seen since switching to mod rails hosting?

Firstly, startup time has been greatly reduced. Where as FastCGI needs to load the rails core code as well as the applications code into memory each time it's started, mod rails keeps the rails core code in memory so only the applications code needs to be loaded. This has reduced rails application start up time from around 5-25 seconds to about 2-10 seconds depending on the size of the application. A huge difference I'm sure you will agree. Another benefit of mod rails is the reduced memory usage and better process management. When running FastCGI we needed to keep watch for runaway processes using too much memory, spawning too many children or processes that had simple become stuck. Mod rails has none of these issues, in our experience processes are stopped correctly when not in use and memory usage is always within acceptable limits. Mod rails keeps rails applications in check meaning there is little external process management needed. Our customers are much happier using our mod rails offerings. Deployment is easier, applications are more stable, faster and more responsive, and don't suffer form any of the FastGCI setup peculiarities. In a nutshell customers can do more themselves without needing to contact us for help or guidance. Customers are also loving the faster application startup time, when running FastCGI we would often get emails from customers asking why their application took so long to load the first time it was requested, since switching we have not had a single email regarding application startup time, it's simple not an issue any more. To find out more about our range of mod rails hosting accounts in the UK take a look at our rails package page. Why not take one for a spin? With free setup and our 30 day full refund money back guarantee can you think of a reason not to give us try?

Media72 are very excited to announce we have teamed up with the guys at PeepCode to give away free PeepCode screencasts. Simply signup for one of our Ruby on Rails accounts and receive a PeepCode coupon code entitling you to any screencast absolutely free. For those that don't know PeepCode produce very high quality screencasts tutorials for Ruby on Rails developers covering topics from Ruby on Rails basics, rSpec, Git, Merb and much more. To receive your free screencast sign up for on of our Ruby on Rails accounts hosted on our UK servers.

After a number of requests the javascript_auto_include plugin now has additional functionality, many people wanted to be able to use the same javascript file in more than one view. It's now possible to do this by naming files like new-edit.js, you can string as many views together as you like using the "-" character as a delimiter. Install the plugin using one of the following methods:

script/plugin install http://kernowsoul.com/svn/plugins/javascript_auto_include

Using rails 2.1 and above:

script/plugin install git://github.com/kernow/javascript_auto_include.git

Thank you to all the people who requested this feature.

Greg Pollack from Rails Envy has posted a nice Railsconf in 36 minutes video for all the people that could not make it, like us.

It's great to see Apple supporting and promoting both Ruby and Rails. At their upcoming WWDC08 conference they have a Ruby on Rails Labs session on Wednesday morning and a RubyCocoa Labs session on Friday afternoon. No help for us in the UK but nice to see all the same.

This plugin has been updated to include additional functionality. We are very pleased to announce the javascript_auto_include plugin for ruby on rails written by our very own Jamie Dyer. This plugin automatically includes javascript code that is specific to a single view or controller which means you don't have to pass anything to your template telling it which javascript files are needed for each page. Working with unobtrusive javascript in Rails can be somewhat difficult. While Rails default javascript helpers are easy to use they produce javascript that is not unobtrusive. When writing unobtrusive javascript in Rails it's often necessary to include a javascript file that will be used by a single view or controller. This can become problematic, messy and very un-Rails like if not managed well. With the Rails philosophy "convention over configuration" in mind I decided to create a plugin to automatically including javascript files that correspond to the view or controller name mirroring the view structure within the javascripts folder. The javascript_auto_include plugin is born and is probably among the smallest Rails plugins available, aren't all the best plugins tiny? To use the javascript_auto_include firstly install the plugin:

script/plugin install http://kernowsoul.com/svn/plugins/javascript_auto_include

Or if you run EDGE rails or rails 2.1 and above:

script/plugin install git://github.com/kernow/javascript_auto_include.git

The plugin will create the directory "views" within your javascripts directory in which you can place javascript files for auto inclusion. Using javascript_auto_include is simple, in the layout file add < %= javascript_auto_include_tags %> to the header. There are two types of javascript includes, view specific, and controller specific. The first is achieved by creating a folder with the same name as a controller, inside this create a javascript file with the same name as a view. The second type, controller specific, are simply files inside the views folder with the same name as the controller. For example:

/public
  /javascripts
    /views
      articles.js # will be included in all views of the articles controller
      /users
        new.js # will be included in the new view of the users controller

The plugin will also include both controller and view specific javascript at the same time, in this example both users.js and new.js will be included when the new view is loaded.

/public
  /javascripts
    /views
      users.js
      /users
        new.js

If you have any comments or suggestions for improvements we would love to hear them. I may add a generator to make adding new javascript files easy.