Driving elsewhere

From "3 posts in 3 days" to 1 post in 1 week, I hate being a fickle blogger. Alas, like many RoRers, our Rails project is a part time affair, and this week other work was paying the bills.

Also contributing to my IDE-absence is last weeks addition of a valuable new Dev team member, referred to herein as Voon (for reasons that shall remain unclear). Unlike this pretender, Voon's got the goods: solid web app development experience, strong knowledge of a variety of programming languages and methodologies, and a keen interest in using Rails. We're lucky to have him.

On arrival, Voon introduced us old-schoolers to the concept of Test Driven Development (TDD). The software development process lying at the heart of XP, TDD focuses on developing incremental chunks of system functionality by writing test code before real code. These tests are effectively executable system requirements. Write them first, and you end up with "Code that works". More importantly, refactoring is easy and safe - your regression tests are already there. So, the theory goes, you end up with "Clean code that works".

Of course, this approach mandates you know your requirements. A statement of the bleeding obvious perhaps, but here's the key: in TDD, the test documents the requirement. So before (and while) you code, you need to know not only what system functionality is required, but how it can be tested.

Why the hell am I writing all this? Voon's introducing TDD has forced us to stop arsing about and focus on documenting our requirements in solid testable User Stories. And that, my friends, is a Good Thing ™.

Any thoughts or experiences employing different software development methodologies? Feel free to comment...

IOC comes to town

Dave Thomas (the Pickaxe forger) explains in plain simple English what Dependency Injection (DI) and Inversion of Control (IOC) can do for an implementation that uses RoR.

I'll admit I read Jamis' article (see Rails, Injected) after picking it up from the wiki yesterday but, not being a true propellerhead, I was left scratching my head wondering what to make of it.

Dave distills it down to this: IOC means the controller is not so tightly coupled to the model.

What does this mean? Well, unit/ functional testing of a controller is easier, as a mock class can be substituted by the DI framework (in this case, Needle) at runtime. Also, your datasources are more flexible as different (non-AR) backends can used in place of certain models, but not others. Shared services and application configuration are more intuitive and flexible, even dynamic (ie. application logic can contribute to the configuration, like "an object can add itself to an array of parties that are interested in being notified of some event"). Very nice.

Thoughtworks

DHH has always acknowledged the influence of Martin Fowler's patterns in the design of RoR. Indeed, I believe "Active Record" is Fowler's own terminology.

I noticed today that Julias from Thoughtworks, where Fowler is Chief Scientist, announced on the wiki that they're actively seeking RoR projects. Very interesting.

Gotchas (Part 1)

I thought I’d list a few random tips, problems & fixes I’ve discovered over the last few weeks on setting up and using my RoR development instance. Before I do, three caveats:

• I’m no Apache or Ruby expert
• My development platform is Windows XP (yes, I know… not all of us have the luxury of a Nice Computer)
• This list just a brain dump, and far from exhaustive. If you like, feel free to contribute your own

To business:

• If you’re doing a gem install, make sure you have the latest version of Ruby Gems ~ I didn’t, and kept getting a Gem::FormatException error when Rails tried to update it’s dependencies (namely rake). I believe it has something to do a change in the way gems are packaged.
• Make sure you follow the Getting Started page to the letter, especially if you’re on Windows ~ In my rush to try and set things up, I missed setting up the c:/tmp directory and updating the shebangs of ~/script/new_controller and ~/script/new_model. Headaches insued.
• Consider avoiding Apache ~ Setting it up can cause unnecessary pain for the uninitiated. I dug around for ages with my hosts and httpd.conf files trying to get VHosts working. Then I realised that Rails already ships with a webserver called WEBrick that works really well for development purposes, no configuration required. I’ve not had a problem since.
• Don’t forget to require your models in your controllers ~ Pretty basic, I know, but sometimes it’s the bleeding obvious can trip you up
• Use “Show session dump” under Request when ActiveRecord or the ActionController returns an error to your browser ~ This is how I figured out what was going wrong when I had problems getting authentication to work

Update: Alex maintains a very useful list of RoR gotchas. Some of them are pretty low level, but you'll be surprised at how quickly you start coming across them. Good stuff

Loudthinkers

Someone had some kind words about my blog on his blog. Thanks David, both for the recognition, and for making our lives easier by releasing your baby to the world at-large.

For the Loudthinkers, thanks for dropping by. Content is somewhat thin on the ground at present, but hopefully that’s excusable given On The Rails is only a couple of days old :)

Please keep checking in or, even better, stick the feed in your favourite newsreader.

My RoR are skills greener than this blogger template, so there’ll be plenty of places where my example code could be improved, or where I’ve just plain got it wrong. Don’t be shy, leave a comment and let me know. Sharing is a wonderful thing.

I’m feeling all warm and fuzzy… think I might go cut some code…

An Informative Rails Presentation

I have no idea who Curt Hibbs is, or where the presentation was given. But its a nice intro to Ruby and RoR, especially for you mugs who like to see lots of code (Hat Tip: GNUVince).

Update: Curt lets us know he's responsible for maintaining the fantabulous One-Click Installer for Ruby on Windows, and for contributing to the original development of FreeRIDE. Apparently, he's:

...given this presentation twice to groups of hardcore Java developers...

Thanks Curt. Here's to hoping it inspires others to do the same.

Authentication

After a few frustrations, I succeeded this morning in getting authentication working.

Most of the examples I’ve come across are some form of variation on the example posted on the wiki. It generally goes something like this:

Setup the login controller:

class LoginController < ActionController::Base

  def index

    # show login screen

  end



  def authenticate

    if @session["person"] = Person.authenticate(@params["name"],
@params["password"])

      redirect_to :controller => "main" 

    else

      flash["alert"] = "Login failed!" 

      redirect_to :action => "index" 

    end

  end

end

…and the model:

class Person < ActiveRecord::Base

  def self.authenticate(name, password)

    find_first(

      [ "name = '%s' AND password = '%s'", name, password ]

    )

  end

end

However, what they miss is the code for the view. “Pretty simple”, I hear you say.

The problem came when I wanted to use ActiveView’s FormHelper. An example:

<form action="login/authenticate" method="post">

    Name:

    <%= text_field "login", "name", "size" => 20 %>



    Password:

    <%= password_field "login", "password", "maxsize" => 20 %>



    <input type="submit" value="Save">

</form>

The above code builds the following HTML:

<form action="login/authenticate" method="post">

    Name:

    <input type="text" id="login_name" name="login[name]"
size="20" />



    Password:

    <input type="password" id="login_password" name="login[password]"
 size="20" maxsize="20" />



    <input type="submit" value="Save">

</form>

All looks good, right? No. Hook these up with the example authentication code: you’ll get no error, but you’ll never authenticate either. Why?

It’s because of the way the textfield and passwordfield helpers created our input fields. Have a look at the name attribute, eg. name="login[name]". As a result, the data entered in these inputs gets passed in as attributes of a @login object, which is in turn part of the @params hash.

However, our example LoginControler expects them to be directly in the hash, @params. Change the controller code to reference the login hash within the params hash, like so:

class LoginController < ActionController::Base

  def index

    # show login screen

  end



  def authenticate

    if @session["person"] = Person.authenticate(@params["login"]["name"],
@params["login"]["password"])

  redirect_to :controller => "main" 

else

  flash["alert"] = "Login failed!" 

  redirect_to :action => "index" 

    end

  end

end

…and all of a sudden we’re in business.

Admittedly, none of this is rocket science. In fact, you may be there thinking "that's obvious". It is… in hindsight.

Getting Started

So, maybe you've heard about this Rails thing. Maby you've watched the movie, and gone "Wow...". Maybe you've even followed the instructions on the wiki and discovered a gem or three.

What now?

Well, here's a list of sites/ resources I found useful when I first started out. It's by no means definitive, so feel free to leave a comment if there's anywhere else you'd recommend budding RoRers dig.

On RoR

• rubyonrails.org ~ pretty obvious. But there's some good stuff kicking around the wiki. In particular:
  • The Rails Academy ~ tutorials created by the masses, for the masses
  • Example Applications ~ watch and learn from others
  • the Wiki feed ~ subscribe to it with your favourite RSS reader. It's not perfect (there's something dodgy going on with the links), but with the wiki starting to sprawl a little, it's a good way of picking up on stuff you'd otherwise miss
• irc ~ still best place to get instant help from fellow RoRers. Play nice and they'll treat you with kid gloves. Well, almost
• mailing list ~ one bulk mail worthwhile diverting from the spam folder. Very active & informative
• "ToDo" tutorial ~ I've not yet worked through this in it's entirety, but Vince, my first commenter has some excellent tips and tricks
• Testing with Ruby On Rails ~ testing is an integral part of RoR, and another area I've but dipped a toe in. Steve makes it all seem so easy in this draft tutorial. Good stuff

On Ruby

• ruby-lang.org ~ Ruby's official residence
• Ruby Garden ~ A community blog from Ruby's English-speaking luminaries. They've also got an excellent wiki filled with stuff for noobs and pros alike.
• The PickAxe ~ the definitive guide to Ruby. No two ways about it: get it. Get it? (Dave & Andy, the authors, have just released a much-improved 2nd Edition, available at pragmaticprogrammer.com
• DHH's resources ~ David lists some other excellent places if, like me, you're still getting started with Ruby