Rails Chronicles – Part 1

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.