Media72 Hosting Articles and Tips

Archive for October, 2007

Anyone that has used Rails 1.2.3, 1.2.4 or 1.2.5 may have noticed a number of deprecation notices in their development logs. Whilst these deprecated methods still work as expected in 1.2.x versions, you will come-a-cropper when you try to upgrade to Rails 2.0. So what do you need to do and what tools are out there to help you with the move? Glad you asked.

The first thing you can do it run your code through a code checker — Geoffrey Grosenbach has released a great rake task which digs through your code looking for the old methods. It will give you hints of how to fix the issues, but lets look at them a little more closely.

@params, @session, @flash, @env

As of Rails 2.0, you won’t be able to directly access the above instance variables. They have been replaced with methods, which makes customising their actions much easier. It also allows the internals of Rails to change without breaking the API. This is very easy to fix - just remove the @ in front of those variables - they will work exactly the same.

find_all, find_first, render_partial

In earlier version of Rails there were a number of grouped methods, that do very similar things - find, find_all and find_first all fetch records from the database, the only difference is the number of records they return. It was decided to combine these methods in to one where they are differentiated by passed in options. So find_all becomes find(:all) and find_first becomes find(:first) and render_partial becomes render(:partial).

Forms

Out of all the HTML helpers, the form tag was an anomaly because it required a start AND end helper. To make it fit in with way the rest of Rails works and to facilitate dynamic form generation, a block method called form_tag was created. This particular update has a trap in it through - because blocks don’t return values, the ERB tag you use must not have an = sign, so

<%= start_form_tag %>
<!-- Form stuff -->
<%= end_form_tag %>

becomes

<% form_tag do %>
<!-- Form stuff -->
<% end %>

Notice the omission of the equals sign in the latter example?

Also note that passing :post => %gt; true is deprecated. With the push for RESTfulness, the form needs to know about the other HTTP verbs, put and delete, so a new option has been created:

<% form_tag :method => :post do %>
<!-- Form stuff -->
<% end %>

Plugins

A number of what used to be core components of rails have been moved out into plug-ins so as not to clutter the core with stuff that you don’t use very often. It also means that the development of the plugins can be much quicker than that of the core. Probably the major extraction is the third-party database interfaces. Now, by default only MySQL, SQLite and PostgreSQL are supported out of the box. All other databases are supported via gems named activerecord-database-adapter. If you want to use an Oracle just run

gem activerecord-oracle-adapter

and you will be peachy again.

Other extractions of note are the acts_as plug-ins. If you use acts_as_tree or acts_as_list in your model, you will need to script/plugin install them and the built-in pagination has now become the classic_pagination plug-in. Note that by the developers own admission that plug-in is slow (and was slow when it was in core), so if you use it, you may want to think about migrating across to the new and improved will_paginate plug-in.

So Apples new operating system comes with Ruby and Rails pre-installed along with a few standard gems. It does however lack a few things you may need to get your computer running as a development machine.
In this mini tutorial we are going to cover:
Updating to the latest version of RailsInstalling MacPortsInstalling ImageMagickInstalling the Rmagik gemInstalling MySQLInstalling the MySQL gem
Firstly lets upgrade rails to the latest version of rails, open up a terminal window and enter:
sudo gem update rails --include-dependencies
Next MacPorts is a package manager for OS X and is needed to install ImageMagick, you can skip straight to the MySQL install if you do not need to manipulate images. I'm not going to explain how to install this as there is excellent instructions on the MacPorts Wiki, be sure to download MacPorts-1.5.0-10.5.dmg for Leopard.
After installing MacPorts we can get on with installing the rest of our software, fire up a terminal window and enter the following commands (enter your admin user password when requested):
sudo port install tiff -macosx
sudo port install ImageMagick
sudo gem install rmagick
These commands, especially installing ImageMagick, will take some time so it would be a good time to take a break. If all goes well you should now have ImageMagick and the Rmagick gem installed.
To install MySQL download the MySQL package labeled 10.4 for your architecture. Then run the mysql-5.0.45-osx10.4-architecture.pkg installer package. Next run the MySQL.prefpane file to install the preference pane.
At the current time the MySQL preference pane does not work without modification on Leopard so in the terminal enter:
sudo chmod -R 777 /usr/local/mysql/data
This gives everyone read/write/execute access to your MySQL data files, this is NOT recommend for anything other than a local development environment and is only intended as a quick fix until MySQL release and updated version for Leopard.
Finally, all we need to do now is install the MySQL gem:
For intel computers
sudo -s
ARCHFLAGS="-arch i386" gem install mysql -- --with-mysql-dir=/usr/local/mysql
For PPC computers
sudo -s
ARCHFLAGS="-arch ppc" gem install mysql -- --with-mysql-dir=/usr/local/mysql
When asked which version choose the most recent ruby version. If you have any issues getting the MySQL gem to install or run see this Mac OS Forge page.
You should now have a fully working Ruby on Rails development installation Rmagick and MySQL.

The seed has been sewn for the next major release of the Ruby on Rails framework. Towards the end of last month, the Preview Release was announced and now that I have had a chance to play with it, I thought it timely to outline some of the new features.

Multiple Views

In version 1.2 of Rails, the respond_to block was introduced, which made serving up differerent data types, like XML or JSON really easy. All you needed to do was something like this:

Then, on the web browser, if you appended the file extension (eg /stories/index.xml) and you would get the content delivered in the requested format. You could even create your own custom types by adding MIME::Type.register to the bottom of your environment.rb file.

One of the problems with this approach though, was there was no way to serve up different HTML pages based on the file extension. Because of the way the MIME::Type parser worked, adding another content handler with a mime type of text/html clobbered the default handler which meant the above code would serve up the wrong view.

Enter Mime::Type.register_alias

Now you can tell Rails to respond with HTML to as many file types as you like! Say you are designing a mobile version and an iPhone version of your site, you can create two new formats by dropping the following code in to the new /config/initializers/mime_types.rb file:

Of course, having to manually render a different version in every respond_to block isn’t very DRY, so a new naming convention has been created for all of the view files. Rather than calling the view file in the example above index.rhtml, you can create three different versions based on the format that you are serving up, eg: index.html.erb, index.iphone.erb and index.mobile.erb.

If rails finds a matching view it will serve that up, if not it will serve up the default .html.erb or .rhtml file. This makes serving up different versions of your site even easier.

Hot on the heals of the 1.2.4 release rails 1.2.5 is now out, as usual all of our servers have been upgraded. Rails 1.2.5 is a security and maintenance release that fixes a JSON XSS vulnerability, fixes a couple of minor regressions introduced in 1.2.4, and backports a handful of features and fixes from the 2.0 preview release.
From the Riding Rails Post:
Summary of changes:

acts_as_list: fixed an edge case where removing an item from the list then destroying the item leads to incorrect item positioning

Hot on the heals of the Ruby on Rails 2.0 & 1.2.4 announcement the Rails team have released Rails version 1.2.4. At Media72 Hosting we always keep bang up to date with our Rails software so that you guys always have the option of using the latest release. Customers now have the option, on most servers, of using Rails 1.2.4, 1.2.3, 1.2.2, 1.2.1, 1.1.6, or 1.1.3, along with our large number of installed gems.

Ever wanted to be able to publish your events calendars online using Apples iCal but don't want to subscribe to Apples .mac service? With Media72 Hosting you can publish calendars from iCal, and any other application that supports publishing via webdav, just like you can using .mac. Read on for instructions...
Firstly you will need to login to your Media72 Hosting control panel, if you don't already have an account why not take a look at our range of hosting offerings. Once logged in click on the "Web Disk" icon in the "Files" section, here you will create a web disk user and select a folder the user can connect to.

Enter a login name, this can be anything you want. We will enter the name "chris" for this tutorial

Choose the domain name from the drop down after the @ symbol. Our domain is media72.co.uk

Choose a password, again this can be anything you want. We will enter "chris474" for this tutorial

The Directory will be automatically completed for you, if you want to change this so something different go ahead. Remember that anything inside a public, web accessible, folder will be visible to anyone unless you password protect it. Also make sure that the directory you enter here actually exists or you will get an error when you try to connect, you can create if if necessary. We will enter public_html/chris for this tutorial

Click "Create"

Click the "Go Back" link

You are now ready to tell iCal to publish your calendar. Open iCal, or the application you want to publish from.

Select the calendar you want to publish and choose Calendar > Publish... from the menu

Choose a name for your calendar. We will use "Birthdays" for this tutorial

Select "a Private Server" from the Publish on: menu

In the base URL you will need to enter your domain name followed by the port 2077, in our case this would be http://media72.co.uk:2077

Enter the login you created earlier, in our case chris@media72.co.uk

Enter the password you chose earlier

Select any options you want to use the click "Publish"

You will now see a dialogue box informing you the calendar has been published with the option to with "Send Mail" or "OK", if you use the send mail feature you will need to edit the url of your calendar before you send it as iCal will not have the correct public url.
The url of your newly created shared calendar will be your domain name plus the public part if the directory you entered when setting up your web disk user, along with the name of your calendar. In our case this will be webcal://media72.co.uk/chris/Birthdays.ics you can send this link to anyone you want to share your calendar with.
If you would like to publish your calendar using a secure web disk connection instead of using your own domain for the base URL in step 4 enter your server name and change the port to 2078, e.g. https://server.media72.co.uk:2078, all communications to the web disk will now be encrypted.
We hope you find this article useful, if you would like articles on other features please let us know.

The preview release of Rails 2.0 has been announced by DHH and says the 2.0 final release is on the way.

"Behold, behold, Rails 2.0 is almost here. But before we can slap on the final stamp, we’re going to pass through a couple of trial release phases. The first is this preview release, which allows you to sample the goodies in their almost finished state."

The announcement goes into quite some detail about the features to be included in this new release, head over to the Riding Rails blog post for the full run down. Keep in mind this is a preview release and is part of edge rails so not suitable for production use, unless you like to live on the edge.
While you are waiting for 2.0 final you might want to look at this little ruby program that checks if your 1.x rails application is 2.0 compatible.
Last, but not least, Rails 1.2.4 is set for release in the near future, this is a bug fix release and will also include more depreciation warnings to make the transition to Rails 2.0 easier.