Elliott J Draper, Freelance Developer

This is a tutorial guided towards those who are new to Rails, or those who have not used it since v1.x and who might want a newbie-style refresher. I’ll be working my way through to some more advanced and interesting topics soon, so for those of you who know all of this already, please stay tuned!

I’ve now been using Ruby on Rails for almost four years, and have seen it progress from version to version. In doing so, I’ve kept up with the changes between each version, and the new features that updates have brought to the table.

For newcomers though, the scene is a little different. Much of the information out there pertains to older versions, from really out of date stuff related to Rails 1.2, to things that may or may not still work as expected when talking about Rails 2.0 features.

I figured that even though it will one day be outdated as well, some Rails newbies might well find it useful to have a straightforward, simple up to date getting started guide for Rails 2.3.5. I’m going to do just that, and a few other articles on the Rails basics, before getting into some more advanced stuff. This article will start specifically dealing with setting up an app, before building our first REST resource using scaffolding.

To begin with, let’s install Rails. I’m assuming you have Ruby and RubyGems installed, but if you have issues with the base setup on Mac OS X, then there is an excellent tutorial here. Once you’re all setup, install Rails as follows:

sudo gem install rails

This will install the latest version of Rails, which at the time of writing is 2.3.5. To specifically install version 2.3.5, for example if 2.3.5 is no longer the most recent version, use this instead:

sudo gem install rails -v 2.3.5

If you don’t want to install local ri and RDoc documentation (i.e. you’ll be looking up API docs online, for example), then you can save a little disk space and a bit of time on installation by doing:

sudo gem install rails -v 2.3.5 --no-ri --no-rdoc

That works for any gem installation.

Once it’s installed Rails 2.3.5 and it’s dependencies, it should leave you with the “rails” command available from the terminal. If you already had a previous version installed, you can make sure that you’ve got the right version at your fingertips by running:

rails -v

That should print “Rails 2.3.5” to the console.

Now on to the exciting part; to create an application, it’s as easy as running:

rails <appname>

So for example:

rails my_new_test_app

I’ll be going over a new feature, Rails templates, and how they can speed up your typical Rails application creation process, in a future post. For now, the default application skeleton created by that command will do.

Let’s go ahead and test our new application. Change into the directory for the new app, and fire it up.

cd my_new_test_app
ruby script/server

This will fire up a development server on port 3000 by default, and by visiting

http://localhost:3000

in a browser, you’ll be able to see the app running. You should be greeted with the default Ruby on Rails page.

Let’s do something a little more exciting, and build something interactive. Rails uses some sensible configuration decisions out of the box, and also provides a fair few generators to get you going with some code. We’ll use one of these generators to provide what’s called a “scaffold”, an automatically built representation of an entire resource, giving you everything you need to get something going quickly. In time, the scaffolding will become less useful as you get used to building the resources yourself more quickly to suit your exact requirements - however to get up and running really quickly, it’s a great start.

We’re going to build a basic note resource, allowing the creation, retrieval, update and deletion of notes (these four actions are referred to as CRUD). To scaffold the resource, run:

ruby script/generate scaffold note body:text

This basically is creating a note model with accompanying controller and views, and we’ve also told it that it should have a single column - body, a text field. It will also be given some timestamp columns (created_at, updated_at) which are updated automatically and can be very useful.

Now let’s go ahead and run the command to bring the database up to date with our changes:

rake db:migrate

This will setup the notes table that was created as part of the scaffold. Now if we visit http://localhost:3000/notes, we can see our fully working notes resource in action!

You can play around with creating, updating and deleting notes and see that it all works straight off the bat.

If we revisit http://localhost:3000 though, we still see the landing page. Let’s set it up so that the root of the site displays the notes index page. We need to do a couple of things to make this happen. Firstly, we need to remove that placeholder landing page, so run:

rm public/index.html

However this still leaves you with the following error when accessing your app now:

We now need to tell the application to use the notes resource for the root of the site. Rails routing can be as complex or as simple as you need it. If you open up config/routes.rb, you’ll see that at the top there is the line:

map.resources :notes

This is the line that exposes your notes resource at http://localhost:3000/notes. So how do we hook up the root of the site to hit the index page for the notes resource? We just need to add a single line to the top of our config/routes.rb file. Right below this line:

ActionController::Routing::Routes.draw do |map|

add in the following line:

map.root :controller => :notes, :action => :index

This tells the app that the root URL (/) corresponds to the index action of the notes controller, which is the one responsible for displaying the list of all notes (the same as seen at http://localhost:3000/notes). Now if you reload http://localhost:3000, you’ll see that it shows the same content as http://localhost:3000/notes.

As before, you can play with the notes to see that it all works correctly - it doesn’t look too pretty, and is almost rarely exactly what you want out of the box, but when getting started with Rails it can provide an exciting and quick way to get new things up and running quickly, and to toy around with.

Now that we’ve got a basic, working application running on Rails 2.3.5, we’ll draw this article to a close. In future articles we’ll delve into more detail on some of the configuration choices you can make when setting up your application, some further detail on building out REST resources, testing your application, and some other more advanced stuff.

For a more in depth and lengthy look at getting up and running with Rails, check out the Rails guide for Getting Started with Rails.

As usual, if you have any comments, queries, suggestions or questions about the above, please get in touch!

So I guess it would stand to reason that a day after blogging about how awesome my new blog routine is, and how it helps me to post every day now, I get busy enough not to find time to really polish the draft I have going at the minute. Not wanting to lose my streak (just), I figured I’d at least try to post something useful today, even if it’s just a link to someone else.

This excellent article about MongoDB is well worth a read. I’d already used Mongo and MongoMapper a little bit on a pet project just to try it out - it powers a basic URL redirector, and runs on Heroku and the (so far excellent) MongoHQ. However after reading John’s article, I’m itching to build out something more substantial using Mongo, to take advantage of some of the really cool things that can be done using it, namely array/hash keys, and GridFS file storage.

Check out the article, then take a look at MongoDB if you haven’t already!

As some of you may have noticed - I’ve been blogging a lot more in the last few days. This is me attempting to start a New Years resolution early, and that’s to try and publish a new post everyday.

However, I always found writing a new post from scratch, checking it twice, proof reading it and publishing it all in one day very daunting. Two different things have helped me with this.

The first, is that while reading Gary Vaynerchuk’s book Crush It!, I took the tip he outlined and wrote down 50 blog post topics that I could think of straight off the bat to talk about. At first I thought 50 was a lot, but when I got going I realised there was a huge number of interesting things I could write about. In the end I wrote more than 50 topics down, and since then have been adding almost as many to the list as I have been crossing off. This means I always have a list of cool things to write about and put down in a post.

The second thing was that I’ve altered my workflow slightly. I used to sit down and try to write a post from start to finish and publish it. This too meant that it always seemed like a big task to try and write something up. However now, I try to simply write “half a post”, or rather, get my initial idea down in rough draft format, and then tidy it up, proof read it, and publish it the next day. Now this means that each day, I finish off one post by simply checking it over, making a few tweaks, and publishing it, and then put another idea down in draft format ready for the next day (if I have time, I might put a couple of drafts down).

Thanks to these two steps, it never seems like too much effort to get a post out each and every day. That, combined with how easy to use Tumblr is, means that I’m now back to writing content regularly, enjoying it, and hopefully some of you are finding it interesting too!

It suddenly dawned on me that something interesting, and in some ways very paradoxical, is occurring with current application trends. Over the last few years, there has been a marked movement towards rich user experiences in web applications - more and more web apps are using Flash and/or AJAX as well as other modern concepts to really make web sites behave and feel truly like first class applications on your computer, with advanced and intricate user experiences. In many cases now web apps have been able to replace their desktop counterparts for a number of users.

Contrast and compare this with the state of mobile development. For years now, wide ranging and patchy HTML support has hampered mobile website development, but the iPhone brings a much more advanced and impressive web browser to the table, and other smartphones such as those running the Android OS now have very full featured browsers too. And yet there doesn’t seem to be much of a focus on advanced mobile web apps. Sure there are some good offerings on the web, and a fair few iPhone optimized sites - but none that as a user you’d lean on in the same way as you might on your computer. Instead, the focus is on native applications, built to service the platform directly - such as the iPhone, or devices running the Android OS, for example. Most platforms are now running app stores that let users search, browse and download apps too, increasing convenience for obtaining native applications.

So why the difference in approach between apps on your computer, and mobile apps? Why do many users now look to advanced web applications instead of native apps where possible on a computer, but when using their mobile, the focus is on native applications?

One of the biggest reasons is probably connectivity. On a desktop computer, many of us now have always-on connections, so we take for granted our web apps always being there. I myself run a fair few different web apps using Fluid, as their own “separate” applications (this includes Google Mail, Google Calendar, Google Reader, Pivotal Tracker and TVCatchup). I always expect them to work, and so I almost treat them like native applications running on my machine, and not on the web. On a mobile of course, while you usually have a connection of some sort (3G, perhaps degrading to Edge or GPRS in certain areas), there still isn’t that complacency when dealing with content you know is being accessed over the air. And in some areas, there is no signal at all, making it almost impossible for many people to completely rely on mobile web applications. Considering the vast majority of applications run fine offline (either they don’t need an online component, or are fine with a sync later approach), it’s easy to see the appeal of offline, native applications on the mobile platform, as opposed to optimized web application offerings.

Interesting though how these two very different viewpoints seem to have come about at almost the same time, and gone in opposite directions to suit user expectations on each platform.

What do you prefer to use on your desktop computer? And how about on your mobile? And where do you see it all going?

I recently embarked on an openings course with the Open University, with a view to it being the first step for me on the way to a distance learning business degree. The openings course is mainly designed to get you into a studying frame of mind, and is perfect for someone like me who is returning to studying after six years. However, as the choices for the two openings courses on the way to a business degree seemed fairly dry (Understanding Management, or Understanding Society), I figured on the most interesting thing about the course simply being getting to grips with studying itself. I opted with Understanding Management.

As I’ve gotten through the first part of the course however, and with my first assignment submitted today, I’ve found that actually the course material has provided me with some rather interesting thoughts and concepts. The general idea that is presented throughout the first half of the course is that we are all managers. Management is made up of distinct, identifiable processes and roles, and we all implement a mixture of these processes and roles while managing tasks, however big or small they might be. We simply use a different set of these processes dependent upon the job at hand.

Instead of thinking about the stereotype of stuffy management and managers, it is important to understand what the concept actually is, and further to that, how it can be effectively applied, and become something useful for everyone who might happen to be “in charge” of something. And that really is anyone - whether it’s managing your finances, managing your workload, managing a party, or managing Christmas dinner. We’re all managers of something, and the sooner we can understand the processes that make up how we manage, the quicker we can improve them and become more efficient at it.