Here’s an example:

require 'ostruct'

s = OpenStruct.new
s.name # => nil
s.name = 'James'
s.name # => 'James'

Note that we don’t need to initialise the ‘name’ attribute: we just set the value and Ruby takes care of the rest. Want to add a new attribute? Easy.

s.age # => nil
s.age = 29
s.age # => 29

We can add any attribute we want to our objects, on the fly, and different instances of the OpenStruct class can have different attributes. Importantly, we don’t have to worry about what methods we send to our OpenStructs, because anything that doesn’t have a value just returns nil ¹:

s.location # => nil
s.hobbies # => nil

Clearing Values

To unset a value, we can do one of two things: in most cases, it’s the obvious…

2.age # => 29
s.age = nil
s.age # => nil

…but to grab the value before setting the attribute back to nil, we can use delete_field ²:

# Returns 29, and sets 'age' to nil
age = s.delete_field('age')
age # => 29
s.age # => nil

Initialising With Values

We can create new OpenStruct objects with attribute/value pairs by providing a hash:

s = OpenStruct.new(:name => 'James', :occupation => 'Rubyist')
s.name # => 'James'
s.occupation # => 'Rubyist'

How It Works

Behind the scenes, Ruby uses a hash to implement OpenStruct’s easy access so we get all the flexibility of a hash with a nice, clean, method-style access laid on top. Don’t worry about the details: just throw whatever you want into your OpenStructs, and let Ruby take care of your data.

Advanced Initialization

If you want object with the flexibility of OpenStructs but with default values for some attributes then something like the following would work:

require 'ostruct'

class MyStruct < OpenStruct
  # Hard-code age and status
  def initialize(hash = {})
    super hash.merge(:age => 29, :role => 'Manager')
  end
end

s = MyStruct.new(:name => 'Bob')
s.name # => 'Bob'
s.age # => 29
s.role # => 'Manager'

# We can override the default values
s = MyStruct.new(:age => 45)
s.age # => 45

OpenStruct vs Struct

Ruby’s Struct is subtly, but importantly, different to OpenStruct. How to use Struct is another blog post, but put simply Structs are less flexible. Check the Struct docs for more info :)

If you’ve reached this post by searching for something similar, I’m guessing you want to do one of two things: either 1) run Ruby on an iPad, or 2) develop for the iPad using Ruby.

1) Run Ruby on the iPad

Never going to happen.

Like the iPod and the iPhone, the iPad is a closed system. The only near-possible way to run Ruby on an iPad would, I’m guessing, be to create an app which bundled Ruby and provided a command-line interface to it. But that’s not going to happen either. Can you imagine Apple approving an app which allowed users to run any code they liked — even within a sandbox? Neither can I.

2) Develop for the iPad using Ruby

This is less clear-cut: there’s obviously no support for Ruby in the Objective-C iPad SDK, but we do have MacRuby: “a version of Ruby 1.9, ported to run directly on top of Mac OS X core technologies”. I think the key words there are “Mac OS X technologies (my emphasis)”; Mac OS X is different to iPhone/iPad OS X, and right now there’s about as much chance of using MacRuby to develop iPad apps as there is of Bill Gates coming to work at Apple.

That might change though (the MacRuby thing, not Bill Gates) — which change would depend on MacRuby becoming a popular way to develop for the Mac. If enough developers use it, Apple may — may — decide it’s worth their time an effort to port MacRuby to their other platforms.

So, Googler: there’s some small hope.

1. Routes are important

The app that I was asked to rebuilt had no routes. Nothing.

That’s not to say that no URLs worked with the app, just that the mappings between URLs and controllers/actions was defined in the code itself — mostly using the old Rails convention:

This makes it very difficult to discover how a Rails app responds to a particular URL, without hunting through the controllers to find a corresponding action. It also makes working with REST a nightmare!

Lesson learnt: use routes.rb

2. Conventions are important

Rails is all about convention over configuration, of course. But when you’re coding a Rails app — especially if you’re new to Rails — it’s easy to ignore those conventions, or just be plain unaware of them.

This leads to a lot of unnecessary work. I’ve spent a lot of time over the past few months translating unconventional code into code that more closely fits the Rails way of doing things: the result is code that’s easier to test, easier to maintain, and much, much faster.

Lesson learnt: take some time to understand Rails’ conventions

3. Simplicity is important

The more I write code, the more I find myself thinking: complicated code is a Bad Thing. Of course, as a kind pedant once told me, there’s a difference between complicated and complex.

(If you don’t have a dictionary handy, “complicated” roughly means messy, difficult to understand; “complex” means many interconnected parts, or a large system. The key difference is that complex systems can be well designed: complicated systems are not.)

OK, dictionary rant over :) Messy, complicated Rails applications come about when a developer doesn’t take the time to think things through. Simplicity is normally easy if you take some time to plan your work upfront — messy code happens when things are rushed or not thought through.

Lesson learnt: think before you start coding

4. Ruby is important

Obvious, but very true: Ruby is important to Rails applications. If you’re new to coding, or new to Rails, then take some time to learn Ruby first: otherwise, you’ll miss out on the power (and beauty) of a great language and a great framework.

Lesson learnt: learn Ruby and Rails, not just Ruby on Rails!

You are important, too

Conclusions? All of the above (and more) is important when you’re developing a Rails app. And you, the developer, are important too — have fun, keep learning, and don’t work too hard. Rails should be fun :)

Ruby doesn’t have the built-in server-side support that PHP has (PHP code will run automatically on most hosts; Ruby code won’t) — but it’s still very easy to code a website using Ruby, and I think the long-term benefits in terms of maintenance and cool code tricks are definitely worth the effort.

Yet another ‘Hello World!’ example

Ruby’s CGI class will be the base of any attempt to serve web content with Ruby. It provides an easy way to access server environment variable and request headers, and just as importantly CGI objects allow you to output HTML (or anything else) very easily:

[ruby]
require ‘cgi’

CGI.new.out(‘text/html’) { "Hello world!" }
[/ruby]

Simple enough for you? We create a new CGI object and call its out method with two arguments: the type of the content we’re sending, and a block which returns the content itself. Here I’m sending HTML, but I could also use ‘text/plain’, ‘text/xml’, etc — depending on what content I was sending.

The out method also lets you do various clever things to create HTML elements: check out the CGI documentation for more details.

Add more code and mix well

I can send textual content, but what if I want to get more involved and start putting Ruby code into HTML files, like I could with PHP or Rails? ERB to the rescue:

[ruby]
require ‘cgi’
require ‘erb’

CGI.new.out(‘text/html’) do
# everything between the <% %> tags is evaluated as ruby code
ERB.new("<p>1 + 1 = <%= 1 + 1 %></p>").result
end
[/ruby]

That should output:

[html]
<p>1 + 1 = 2</p>
[/html]

From this point, it’s easy to build up more complicated ERB templates and mix complex Ruby methods and their results into your HTML. Before you know it, PHP is long forgotten and your website is running on Ruby!

Brining it all back home

There are a few more things you need to know before you can really use these techniques to get a webpage up and running: I hope to post a follow up article soon to run through deploying, creating helper methods, separating layout and content, and more.

For now, though, read the CGI docs and play around — it’s fun, honest :-)

My random password generator is a ruby-powered web page: check it out for an example of what Ruby can do.

If you need to seriously extend the functionality of existing Ruby classes, it’s much cleaner and safer to use proxies, so this article is a must-read.

1. Ruby-Lang.org: Ruby’s website has some great tutorials for developers coming from other languages. They’ll help you to take your first steps as a Ruby programmer.
2. Ruby-Doc.org: here you’ll learn what Ruby is capable of. RubyDoc has documentation for all of Ruby’s classes and modules: you’ll always learn something new.
3. why’s poignant guide: a cartoon guide to Ruby. Funny and informative!
4. Ruby Inside: this Ruby blog is a great way to discover new code created by the Ruby community.

And of course, if you’re bored, you can always browse Github!

Which is where Rails comes in.

It’s possible to clone TinyURL using Sinatra, but I’m more interested in Rails (I think Rails probably scales better). The basic setup is so simple, it doesn’t take long to write the code, and with Rails you can always add extras like an admin interface later without much fuss.

The code

(If you’re feeling lazy, the entire URL-shortening app is available on Github)

My TinyURL-like Rails app — I call it “Shrink” — has three main components: routes, controller, and model. Routes first:

[ruby]
ActionController::Routing::Routes.draw do |map|

map.resources :locations, :only => [:new, :create]

map.with_options :controller => ‘locations’ do |map|
map.root :action => ‘new’
map.preview ‘/:shrunken/preview’, :action => ‘preview’
map.location ‘/:shrunken’, :action => ‘redirect’
end

end
[/ruby]

“Locations” are the web pages we’ll be redirecting people to when they click on a short URL.

As you can probably tell, this routes file gives us RESTful routes for creating new locations, along with a catch-all shrunken route which we’ll use to intercept our short URLs and redirect them. There’s also a preview route (more on this in a bit), and I’ve mapped the root path (‘/’) to the new action on LocationsController — this will expose the form for shortening URLs on our site’s home page.

The Controller

We only need one controller, with just a few short methods:

[ruby]
class LocationsController < ApplicationController

def new
@location = Location.new
end

def preview
@location = Location.find_by_short_url(params[:shrunken])
end

def redirect
@location = Location.find_by_short_url(params[:shrunken])
redirect_to @location.url
end

def create
@location = Location.new(params[:location])

if @location.save
redirect_to preview_path(@location)
else
flash[:notice] = ‘Invalid URL’
render :action => "new"
end
end

end
[/ruby]

That’s simple enough — the only thing to note is that we’re using Location. find_by_short_url instead of Location.find, so we can use slugs like ‘a1b3c’ instead of database record IDs in our URLs.

The preview action, by the way, just renders a view which shows the user the shortened version of their URL so they can copy and paste it into Twitter (or whatever).

The Model

[ruby]
class Location < ActiveRecord::Base

validates_presence_of :url
before_create :validate_url

class << self
def find_by_short_url(shrunk)
find(shrunk.to_i(36))
end
end

def to_param
id.to_s(36)
end

private
def validate_url
false unless url_valid?(URI.parse(self.url))
end

def url_valid?(url)
url.kind_of?(URI::HTTP) || url.kind_of?(URI::HTTPS)
end

end
[/ruby]

The model implements our find_by_short_url method, implements some validations, and overrides Rails’ default to_param to provide TinyURL-like short URLs. to_param is used in url_for; the method normally returns an object’s database ID, for URLs like /people/1, but here we return a short string like ‘a1c’ instead.

Note the calls to to_s(36) and to_i(36): these convert record IDs into shorter URL slugs, and back again, using base 36 numbering. By using base 36, we can keep our URLs as short as possible: 10000 in base 10 is ’7ps’ in base 36. Read more about this useful feature of Ruby at ruby-doc.org.

Putting it all together

The code for this app is open-source and is available on Github; download, run script/server, and go to http://0.0.0.0:3000/ and you’ll see it in action. Proof that you can clone TinyURL using Rails in less than an hour!

Update: if you’re using the plugin, have questions, or have found this post useful, take a moment to send me a message on Github, or email me (james at this domain). It’s always great to know how people are using my work :)

If you just want to get up and running as fast as possible, skip to the Plugin section at the end of the article. Feedback is always appreciated; if you use the plugin, or have questions, feel free to email me (james at this domain).

If you want to understand how the plugin works, read the full article.

Three Simple Steps

There are basically three steps to serving custom iPhone content from Rails:

1. Register a custom iphone format
2. Tell Rails how to recognize an iPhone request
3. Tell Rails to use the custom format for iPhone requests

Registering a custom iPhone format

Rails already knows about formats like HTML and XML, and all iPhones actually need from a Rails app is plain old HTML — but we need a way to distinguish our iPhone HTML from the HTML we send to other browsers.

To do this, we register a mime type alias — just a way of telling Rails that when we say ‘iphone’, we mean ‘HTML’. This is done in config/initializers/mime_types.rb:

[ruby]
Mime::Type.register_alias “text/html”, :iphone
[/ruby]

Now we can do something like format.iphone and Rails will know we want it to serve our views as HTML.

Tell Rails how to recognize an iPhone request

In order to serve custom views to iPhones, we need a way of recgonizing when someone is viewing our website on an iPhone. This is easy:

[ruby]
class ApplicationController < ActionController::Base

# other code here

private
# detect iphone requests
def iphone_request?
(agent = request.env["HTTP_USER_AGENT"]) &&
agent[/(Mobile\/.+Safari)/]
end
end
[/ruby]

The iphone_request? method looks for MobileSafari’s user agent string in the incoming HTTP request. Because MobileSafari runs on the iPod Touch as well as on the iPhone, this method will ensure that we serve our custom views to both devices.

Now we can identify iPhone requests, we just need to put everything together and…

Tell Rails to use our custom format for iPhone requests

Normally, when Rails receives a request from a browser, it determines what sort of response the browser is looking for (XML, HTTP, JSON, etc). Then it looks for corresponding templates — index.html.erb, index.xml.erb, etc. This behaviour is customizable using ActionController’s respond_to method.

In order to serve custom views to the iPhone, we need to tell Rails to switch to our custom :iphone format whenever an iPhone visits our website. This sounds complicated, but is easy:

[ruby]
class ApplicationController < ActionController::Base

before_filter :adjust_format_for_iphone_requests

private
def adjust_format_for_iphone_requests
request.format = :iphone if iphone_request?
end
end
[/ruby]

This little snippet calls our iphone_request? method and tells Rails to use our iphone format where appropriate.

That’s really all there is to it. You can now create index.iphone.erb, show.iphone.erb, etc, alongside your standard HTML views and layouts, and Rails will serve them up to iPhone users. Bon appetit!

The Plugin

Serving custom iPhone content is something I want to do from many Rails apps, so I wrapped the functionality outlined above into a plugin for quick and easy iphoneification. Install thus:

[bash]
script/plugin install git://github.com/jameswilding/iphoneification.git
[/bash]

To use the plugin, just add one line to your application controller:

[ruby]
class ApplicationController
responds_to_iphone
end
[/ruby]

If there’s a particular controller or action that you don’t want to serve iPhone content from, use

[ruby]
class NotAnIPhoneController
skip_iphone_response
end
[/ruby]

The plugin does most of the work: all you need to do is name your custom iPhone template {template_name}.iphone.erb.

Bowline works in combination with Titanium, which lets you:

Use Web technologies to create rich applications for Windows, Mac and Linux from a single code base.

I think Bowline looks awesome. Desktop apps using Ruby, WebKit, HTML 5 — all the best stuff if you’re a web development geek like me.

It’s difficult to summarise how Bowline works (although it’s a little like Rails), so I recommend that you read the author’s blog post introducing the framework. Let’s hope Bowline grows into a stable, mature framework that does for desktop apps what Rails has done for the web.

As you may know, Rails 3 is a major re-working of the Rails internals — and ‘internals’ is the important word. Rails 3 will not introduce any major changes the the way Rails works for the normal Rails developer. If you compare Rails 3 application code to Rails 2 application code, you won’t see much difference.

Where you will see differences is in the Rails framework code – the stuff that implements features like routes, respond_to, render, and resources. Its fair to say that this code has undergone major changes — the guts have been ripped out and the whole framework has been put back together in a new way.

Of course it’s a testament to Rail’s strengths as a framework that a major refactoring of its code base is possible. It’s also testament to the skill of the people who are working on the code — the original Rails core team, plus new members from Merb. I’ve been following Yehuda Katz’s blog (he’s one of the guys who developed Merb) and the things he’s written about his work on Rails 3 have been really interesting.

In particular, Katz’s approach focuses more on the benefits of a well-organised Rails code base, and less on the pragmatic “make it cool as fast as possible” approach which seems to have characterised Rails up to now. That’s not to knock the later — Rails wouldn’t be where it is today if people hadn’t been willing to turn a blind eye to overly-complicated code or poor internal structures.

But these new changes are good: Rails will be as easy and as fun to use for serious developers (of plugins, for instance) as it always has been for front-end designers and application builders. It really feels like we’re getting the best of both worlds.

If you’re interested in learning more about the philosophy behind Rails 3, I recommend the following:

• Yehuda Katz’s posts about his work refactoring Rails
• DHH’s RailsConf keynote
• This presentation from a London Rails conference, which explains more about the thinking behind the Rails refactor. Treat the video like a radio show, because the picture quality is pretty bad.