Before you read any further: The purpose of this post is to capture how I went about learning how to create Web apps using Rails. I thought it might be interesting to look back in a few months and see all the things I got wrong and didn’t understand about Ruby and Rails when I started out. So, if you’re looking for enlightenment about Rails, you’re in the wrong place. I’d recommend you head over to Michael Harl’s Ruby on Rails Tutorial: that’s the site that really got me started.

Introduction

I have a stinking cold this weekend and, apart from dragging myself out to walk the dog, I’ve been fit for nothing else but sitting on the sofa (or lying in bed) with my laptop. But I thought I’d try to use the time profitably by finally getting around to learning how to use Rails. I’ve been meaning to do this for over five years now – i.e. since the days when all the tech podcasts I listened to hyped it up as the great new thing on the Web.

Back in 2006 I even bought my daughter a copy of the original edition of Chris Pine’s Learn to Program book – which uses Ruby to teach programming – on the off-chance that she might get interested in coding. We sat and went through some of it together but she really wasn’t interested so the book then lay unread for years, until a couple of months back when I packed it into one of several big cardboard boxes with all my other computer books and it went off to the Oxfam bookshop.

The trouble has been (apart from inertia, laziness and wariness about potentially wasting lots of time on yet one more thing I really don’t need to know about) that I’ve been doing most of the dynamic Web page goodness I need to do quite fine all these years using PHP (well, a combination of PHP, MySQL, Javascript, CSS and plain old HTML to be precise). So I haven’t had a need to learn about Rails. But PHP seems antiquated these days and I really feel like I need to move on. I also wanted to get a better understanding what Model-View-Controller (MVC) is all about. I understand the principals of MVC, but it’s not until you actually use a programming concept that you really understand it.

Before PHP I was a committed Perl devotee and it took me a while to switch to PHP because I really liked Perl and I was doing some fairly complex stuff with it. I got into Perl because I’d started writing Web pages in HTML, discovered you couldn’t do much with HMTL alone, started writing Javascript, discovered that that had its limitations (as well as being the source of a great deal of pain back then) and so I ended up, like many people who followed the same route, writing Perl CGI scripts. That was before PHP had really got going and, for hobbyist Web site creators like myself, Perl CGI scripts on Apache servers was about the only way to go. And I really enjoyed writing Perl. The only thing that did for Perl was the whole issue with modules: figuring out which modules you needed, which versions were installed, installing multiple versions of modules so as not to break someone else’s scripts, and so on. Modules were a bit of a nightmare. PHP just seemed to have everything built in and you could just crack on and do the coding.

So I switched from Perl to PHP and never looked back. But I do remember being horrified at first by the mix of HTML and code within PHP files. The recipe seemed to be: chuck all your ingredients (design, content, functionality) into one bowl and give it a good old mix. It struck me as having massive potential for confusion and maintenance issues. With my Perl scripts I’d used separate HTML templates. The Perl script requested by the browser called up other scripts as required, did the processing, worked with the database, gathered together all the dynamic content and then selected from a choice of templates and built the final HTML by replacing placeholders with the dynamic content. I really liked the idea of keeping the page design and static content as separate as possible from the code – it just seemed a lot cleaner that way. So that’s one thing I’m expecting Rails to have got right and I’m looking forward to getting back to that kind of way of doing things. We’ll see.

Starting point

I can’t code in Ruby. I’ve read up about it at various points during the past few years and I’ve written a few little Ruby programs in the course of dipping my toes in the subject. Specifically, I’ve spent some time with these resources:

• Chris Pine’s book, mentioned above (I recently downloaded the 2nd edition to my iPad)
• Beginning Ruby: From Novice to Professional by Peter Cooper
• http://tryruby.org/ – a great, try-it-online-as-you-go, getting started tutorial
• why's (poignant) Guide to Ruby – better experienced than described; the story behind this is as intriguing as the book itself

But, as of today, I have to say I really can’t code in Ruby. Should I have concentrated on this for a bit before jumping into Rails? I’ve read conflicting advice answering this question definitely yes, and no, it’s not necessary. It’ll be interesting to see how much this lack of knowledge holds me back or trips me up.

As far as Rails goes, before this weekend I’d watched pretty much every video I could find about Rails at one time or another – including all the ones where someone zips through and creates a (seemingly) fully functioning social media Web site in about ten minutes. For non-macho programmers like myself that kind of thing (where someone is talking super fast and typing commands even faster, and things are zapping past you on the screen: zap, there goes validation, blink and you miss it, there goes authentication …), that just puts me off, because what it says to me is: only ubergeeks will really find this as easy as this guy seems to – the rest of us would doubtlessly only get mired in bizarre error messages before we ever got anywhere near creating a working Web page.

Anyway, I’d heard a podcast a while back where Michael Hartl was being interviewed about the Rails tutorial he’d written and the screencasts he’d created, and how he makes a really good living from people buying the screencasts and the PDF of the tutorial, even though the same content that’s in the PDF is available for free as Web pages. So this weekend I finally went and looked up http://ruby.railstutorial.org/ruby-on-rails-tutorial-book and started reading the first chapter of the tutorial book. And so far so good. I’ve done the first two chapters now and I like it. It’s up to date and it works.

gvim

The other thing I spent some time on was downloading, setting up and relearning vim (actually gvim). This is a lightly updated version of the UNIX vi editor. There’s a Windows version of gvim that lets you relive the experience of using a text editor originally created by a 22-year-old Bill Joy back in 1976. It might sound crazy to choose to go back to using vim, but I think it might make sense – there are some definite benefits.

I started using vi in 2001 when I got a job as a technical author and discovered, first day on the job, that I wouldn’t be using Word or even Notepad. I had a choice between vi and Emacs, neither of which I’d heard of before. I tried them both and settled on Emacs at the time, but since leaving that job I’ve never used Emacs again but I’ve used vi regularly over the years just because it’s always available on any UNIX/Linux server you ever connect to.

For a long time my text editor of choice was UltraEdit. I then switched to Notepad++ and I’ve stuck with it for the last eight or nine years now. But I thought I’d tie in learning Rails with brushing up my vi expertise (in the shape of gvim on Windows). I should point out that I’m working on Windows 7. So, after some tweaking of colours and window setup, and spending a little time revising the subject and creating a personal cheatsheet on vim (in vim), I’m using it quite happily now. I’ve never really been a mouse lover. I like keyboard shortcuts, and the great thing about vi is being able to keep your hands on the keyboard all the time: it really does allow you to get things done far quicker than you can by pointing, clicking, dragging.

git

git is another of those things I’ve been hearing about a lot over the past five years or so and felt I should find out more about. Back when I was learning vi and Emacs I was also learning about CVS, and I found it a steep learning curve. Fast forward a few years and, at my current job, we switched our version control from CVS to SVN and I came to really like SVN. I particularly like TortoiseSVN and its repo browser. But I’ve been thinking about looking at git for a while now – just to find out why people seem to like it better (it seems to be the most-used version control system for software source files now).

So I was pleased to discover that Michael Hartl’s tutorial gets you committing your Rails code to github right from the start. The only trouble I’ve had with the tutorial so far has been that I couldn’t push code up to github successfully to begin with and I struggled for a while (and posted a question on stackoverflow about it) before realising that I’d screwed up with one of my initial commands, meaning I had to delete the .git directory and start over. The problem was that I’d tried to push up my code before going to the github Web site and creating an account and a repository. Yes, I know: duh! But the problem seemed to be that having made this error, even though I then went and created the account and repository, something in my .git directory must have been messed up. So that held me up for a few hours, but – after backing up and redoing it – it now works fine.

The git commands are (like much in the world of Ruby on Rails, I suspect) the kind of thing that you just have to learn. It’s not obvious and you can’t just guess and figure it out. You need to know that exact words and syntax or it won’t work.

One of the things I like about having installed git from github is that I now have a bash shell on my Windows 7 machine. I can press the Windows key, type bash, press Enter and I get a console window with the bash shell, which allows you to do a lot more, a lot more easily than the standard Windows DOS-type command console.

Heroku

Finally, for this inaugural Rails Chronicle post, something else I’d heard about in a podcast but never used: Heroku. I spent a few days up in Glen Esk earlier this year and I remember one day walking the dog across the field to the river and than back up along the side of the Tarf listening to a podcast about Heroku, which is a hosting service for Web applications. Actually it’s more than that. It’s a system for continuous deployment of Web applications that’s intigrated with git to make it easy to push files up to Heroku’s cloud service and build a deployment that you can immediately browse to.

It seems to work incredibly easily and smoothly – but, again, working from the command line, you need to know the right commands; although these seem to amount to:

$ heroku create
$ git push heroku master
$ heroku rake db:migrate

Conclusion

So far so good. I’ve only done the first two chapters but they cover a whole lot of ground and I feel like I’ve learned a lot already. What I haven’t learned however, is any Ruby – so far.

This is a little reminder for me for next time this happens. I create a lot of PHP/MySQL stuff, mainly for database-driven Web pages. XAMPP is brilliant for this because it allows me to write/test stuff locally on my laptop. It’s dead easy to install and has a nice little control panel for turning MySQL, Apache Web server and Filezilla on and off. If you develop Web pages then you probably already use XAMPP. I swear by – have done for years.

However, periodically, after I haven’t used my local Web server for a while, I go to the XAMPP control panel, click to start Apache, but nothing happens. It doesn’t tell you there’s been a problem, but the “STARTED” indicator doesn’t appear.

The problem is that something else is hogging port 80. It might be IIS if you’re running that already, but more likely (in my case anyway) it’s Skype.

To solve this problem:

1. In Skype, go to Tools > Options > Advanced > Connection.
2. Clear the check box labelled “Use port 80 and 443 as alternatives for incoming connections”.
3. Click Save.
4. Quit and restart Skype.

Shorteners in brief

If you use twitter you'll be familiar with the concept of URL shortening. You want to tweet about that video where the dog thinks its own leg is trying to steal the bone but you've only got 140 characters to say what the video is and include the link to YouTube. URL shorteners allow you to change:

http://www.youtube.com/watch?v=tJgMueh-zLM&feature=youtu.be
to:
http://bit.ly/dfzFE6

Even if you don't use twitter URL shorteners can come in handy. For example, at the beginning and end of the ITauthor podcast I use some music by Amplifico and I like to put a link to their page on musically.com in the MP3 description that you can read on your iPod when you're listening to the podcast. It's much nicer to give the URL http://tinyurl.com/amplifico, rather than http://www.musicalley.com/music/listeners/artistdetails.php?BandHash=cdef1ecef0d12844ed816b922fcada5d.

Some popular URL shorteners

• tinyurl – This was the first URL shortener most of us will have come across - way back before twitter appeared and ramped up demand for short URLs, leading to a proliferation of shortening services.
• bit.ly – twitter supported use of bit.ly which made it a popular service. Recently there have been doubts raised about the wisdom of using a Libyan registered domain (.ly) as the Libyan government have said they will take down domains that contain immoral content.
• j.mp – This is just bit.ly but with 2 fewer characters. If you already have a bit.ly URL you can use the same shortened path, stick it on the end of the j.mp domain and save yourself those 2 precious characters. For example, the dog video gets shortened to http://j.mp/dfzFE6.
• goo.gl – Google are one of the many big companies that have now got into the URL shortening business.
• is.gd – just a nice simple Web page that produces nice short URLs.
• ... I could go on, but there's not a whole lot of difference between these services.

Your very own URL shortener

Shortening URLs isn't difficult to do and there are a selection of free URL shorteners that allow you to produce your own short URLs. All you need is your own Web site and your own domain name. So, for example, I own the domain name itauthor.com, so I can produce short URLs like http://itauthor.com/1 or (more descriptively) http://itauthor.com/podcast36.

The solution I'm using is called yourls. It's a series of PHP scripts with a MySQL database behind it. So if you're already running a Web site based on PHP and MySQL (for example, a WordPress blog) then you've already got everything you need. Just upload it and browse to the admin page. The yourls contains all the instructions you need.

The only problem I had was as a result of some changes not getting written to my .htaccess file in my root Web directory. I had to go and manually add the following at the start of the .htaccess file :

# BEGIN YOURLS
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{HTTP_HOST} !^itauthor.com$
RewriteRule . - [S=3]
RewriteRule ^([0-9A-Za-z]+)/?$ /yourls-go.php?id=$1 [L]
RewriteRule ^([0-9A-Za-z]+)\+/?$ /yourls-infos.php?id=$1 [L]
RewriteRule ^([0-9A-Za-z]+)\+all/?$ /yourls-infos.php?id=$1&all=1 [L]
</IfModule>
# END YOURLS

You don't need the two lines highlighted in red if you're not running WordPress, or anything similar that relies on being able to rewrite URLs. The yourls documentation says, in this situation, you need to put all the yourls files and directories in a subdirectory of your root Web directory (e.g. in a directory called "u"). However, this means that you need to include the subdirectory in the YOURLS_SITE configuration setting and it'll then be part of the shortened URL (e.g. http://itauthor.com/u/123, which kind of defeats the purpose. So the two red lines get around this by diverting URLs without "www" to yourls.

The first of the red lines says "only apply the following rule if the URL doesn't begin http://itauthor.com". The second red line says "if the previous condition resolved as true then skip the following three rules".

This seems a bit like a double negative but it's necessary because RewriteCond only applies to the RewriteRule that immediately follows it, so we need the skip rule. The result is that, on my site, the three RewriteRules that divert page requests to the yourls PHP scripts are only applied to URLs beginning http://itauthor.com. The "[L]" means "last" - in other words, if this RewriteRule is applied don't go any further, so we never reach the rules that WordPress uses, which are further down the .htaccess file. If a URL begins http://www.itauthor.com then the yourls rules are skipped and the URL is processed using the WordPress rules.

This means that http://itauthor.com/2 is sent to yourls to retrieve the original, long URL from its database, whereas http://www.itauthor.com/podcasts is sent to WordPress to create a Web page using content from its database.

What's the point?

Well, okay, there's really no point other than a bit of personal domain name vanity. Why have your tweets full of bit.ly or goo.gl URLs when you could have your own domain name showing up – even if clicking the link doesn't take your tweet readers to your Web site.

And to finish, just because I find it very funny, here's that video of the back leg bone thief:

Yesterday I made a recording and posted it up to AudioBoo as a couple of recordings. I forgot about the 5-minute maximum so I had to chop and edit my 12-minute ramble into two and then post up the second of it.

Today I posted an ITauthor podcast onto this site. And the comparative ease and difficulty of the two process became immediately apparent.

Although I have some niggles with AudioBoo (there are some very obvious improvements they could make), it certainly does make publishing a podcast very, very easy. This is especially true if:

a) you have an iPhone
b) you're happy to record your podcast episodes directly into your phone and post them without any editing

Editing is the bane of podcasting - so I actually see a lack of editing as a good thing. However, the bad thing is that you can't slip over 5 minutes. If you try to post a recording that's longer than 5 minutes then it just stops dead after 4.59.

I don't have an iPhone, so my experience was a degraded one of recording onto a little digital recording, uploading to my computer, uploading a photo from my Blackberry, then uploading recording and photo to AudioBoo via the upload web page. But even still, it was way, way quicker than how I currently produce my ITauthor podcast. Here's the ridiculously complicated process I trawl through for that:

1. Record the podcast.
2. Upload it to my PC.
3. Edit it in Audacity.
4. Export it as a .wav file (I've tried exporting to MP3 but the sound quality is rubbish).
5. Convert the .wav file to MP3 using Format Factory.
6. Add tags and photo to the MP3 using ID3-TagIT 3.
7. Upload the MP3 to my Dreamhost server using WinSCP.
8. Open a previous ITauthor podcast blog post in Live Writer.
9. Copy it and use this to create a new blog post.
10. Post this to my WordPress blog as a draft.
11. Go to the web page for editing the blog post and add the MP3 using the Blubrry PowerPress plugin.
12. Publish the blog post.

This is a long and tedious enough process to discourage me from podcasting regularly.

There's got to be a better way. And if all you want is a mini, 5-minute podcast then AudioBoo probably is that better way.

In July 2002 I read the following in Russell Beattie's blog:

Hi, I'm playing with a new idea - or actually a retread of an old idea of mine - an Audio Blog! I just quickly recorded a bunch of my thoughts and put them into a MP3 file to post here:

That was three years before podcasting really started to take off. And the thing that I really liked was the idea of listening to someone rather than having to sit there reading. The internet is still quite a texty medium (think of Twitter, and even FaceBook - although some people, insanely, keep all their photos there - is still largely just text), but back then in 2002, boy did you spend a lot of time reading off a flickering CRT! I spent most of my working day reading, so, although I liked the idea of blogs, sometimes the reading of them felt like a bit of a chore. Hearing the voice of a blogger you'd been reading for a long time was wonderful. As Russell says: "instead of just reading their thoughts you could hear their voices ... their inflexion and their enthusiasm". I was really surprised that audioblogging didn't take off and even Russell Beattie gave it up after a short while.

Then of course podcasting came along and for a while everybody who leapt on the idea thought they were broadcasting to the world when in fact, to begin with at least, the only people listening were other podcasters. And yes, I've made sporadic stabs at podcasting myself - and hope to do so again. My plans are currently on hold thanks to the utterly abysmal internet service I currently endure from Sky Broadband which makes any sort of internet experience tedious at best and renders the recording of Skype interviews completely unfeasible ... but I digress.

Now there's an easy way to do pretty much what Russell Beattie was doing back in 2002, it's called Audioboo. It's an application for the iPhone, Android and the Web that allows you to record up to 5 minutes of audio, tag it and post it to your Audioboo profile. They've branded these recordings "boos" - which gives you a clue as to how this must have been pitched to the venture capitalists who no doubt funded the site: trendy social media, with an audio twist. However, for podcast lovers like myself a really nice feature is that every tag and profile has an RSS feed, which means you can subscribe to any of these as a podcast.

Sounds great. And it could be great if it wasn't so difficult to find anything worth listening to. The problem is the lack of classification. I want to find people who generally record stuff on a certain subject, but there's no way to do this, other than stumbling upon something by blind luck. The only way to find "boos" is to browse:

• everyone's boos (the most recent boos: completely random)
• featured boos (also seemingly random - you just don't get all the "This is a test" recordings of people trying out AudioBoo)
• popular boos (a perplexing selection if these are really the most listened to recordings - the list is also strangely static)

On the iPhone you can also browse for boos that have been geotagged to somewhere near to your current location. I can see how this might occasionally throw up interesting recordings. Unfortunately I don't own an iPhone.

However, there's no classification of booers (boozers?), so it's impossible to find people who might be talking about things you want to listen to. Yes there's tagging, but try searching for "software" and you just get a ragbag of boos that people decided to tag as "software". What I'm looking for are people who generally record their thoughts about software.

This highlights the problem with tagging versus less free-for-all methods of classification. If AudioBoo allowed people to choose to classify their profile with a maximum of three keywords, only the people who generally talked about software would choose "software" as their classification. Then I'd be able to find them.

It's frustrating because I'm sure there is a lot of audio in Audioboo that I'd enjoy listening to. I just can't find it. I can try, but all the rubbish and nonsense is going to put me off the effort very quickly. It's like a going into a huge library to find something to read, but the books are stacked in a completely random order and they have unmarked spines so I have to open them up, one by one, to find out which book each one is. After opening a couple of cheesy romances, a car repair manual, several books in foreign languages and a biography of a 1980s cricketer I give up and head home to buy something off Amazon.

Good luck Audioboo, but I can't see me visiting very often until you put a bit of thought into usability.