pingles

I’m sure everyone will be glad to know I’m up and running with the latest trunk revision of Typo—the blogging software I’m using. Although it was far easier than expected, here’s a little guide to how I did it (in case others aren’t so familiar with Subversion).

Firstly, I wanted to make sure that if it didn’t go smoothly I’d have a full backup of my MySQL database, so I ran the following

mysqldump typo_production > before_migration.sql

That scripts all of the database to the `before_migration.sql` file, which can then be restored (if necessary) as follows:

mysql typo_production < before_migration.sql

All of my Rails based apps are now running under Lighttpd (a good choice by the way), with the current application folder as follows:

/var/www/servers/_domain_name/current

In most sites this is just a symbolic link to the actual directory created by Switchtower when doing `rake deploy`. However, for Typo, since I don’t deploy via. Switchtower it just has a current directory that contains the 2.6.0 release. So, I renamed the folder and linked to it from current as follows (note this is within the domain’s directory):

mv current typo-2.6.0ln -s typo-2.6.0/ current

That ensured that I am now in a position to switch over to the edge revision whenever I want to.

Now, all I need to do is pull down the latest typo trunk as follows (again within the domain’s directory in my case):

svn checkout svn://leetsoft.com/typo/trunk typo-latest

That should display a little info about Subversion setting up your working directory, and at the end inform you which revision you’ve just checked out. Since at the time I did it, it reported revision 855, I then renamed `typo-latest` to `typo-rev-855`.

I then copied over my old `database.yml` configuration file, and double checked everything looked ok. As it did, I then performed the database migration:

rake migrate RAILS_ENV=production

You should see a little info as it goes through about what it’s migrating, and (assuming all went well) you should then be in a position to switch over from the 2.6 release to the trunk (again, within the domain directory for my setup):

rm currentln -s typo-rev-855/ current

Finally, I then gave Lighttpd a boot and watched it come back up. Although this worked in the main, I tried switching over themes and viewing the blog and came across some Rails errors. Checking in the `production.log` revealed the some entries such as:

Errno::ENOENT (No such file or directory -/var/www/servers/www.oobaloo.co.uk/current/cache)

Couldn't create cache directory: META/DATA/ACTION_PARAM/www.oobaloo.co.uk/articles/index/ (Permission denied - /var/www/servers/www.oobaloo.co.uk/current/cache/META)

To remedy, I created a cache directory with the necessary permissions for the app to write to, all now seems to be running well!

I’m sure everyone will be glad to know I’m up and running with the latest trunk revision of Typo—the blogging software I’m using. Although it was far easier than expected, here’s a little guide to how I did it (in case others aren’t so familiar with Subversion).

Firstly, I wanted to make sure that if it didn’t go smoothly I’d have a full backup of my MySQL database, so I ran the following

mysqldump typo_production > before_migration.sql

That scripts all of the database to the `before_migration.sql` file, which can then be restored (if necessary) as follows:

mysql typo_production < before_migration.sql

All of my Rails based apps are now running under Lighttpd (a good choice by the way), with the current application folder as follows:

/var/www/servers/_domain_name/current

In most sites this is just a symbolic link to the actual directory created by Switchtower when doing `rake deploy`. However, for Typo, since I don’t deploy via. Switchtower it just has a current directory that contains the 2.6.0 release. So, I renamed the folder and linked to it from current as follows (note this is within the domain’s directory):

mv current typo-2.6.0ln -s typo-2.6.0/ current

That ensured that I am now in a position to switch over to the edge revision whenever I want to.

Now, all I need to do is pull down the latest typo trunk as follows (again within the domain’s directory in my case):

svn checkout svn://leetsoft.com/typo/trunk typo-latest

That should display a little info about Subversion setting up your working directory, and at the end inform you which revision you’ve just checked out. Since at the time I did it, it reported revision 855, I then renamed `typo-latest` to `typo-rev-855`.

I then copied over my old `database.yml` configuration file, and double checked everything looked ok. As it did, I then performed the database migration:

rake migrate RAILS_ENV=production

You should see a little info as it goes through about what it’s migrating, and (assuming all went well) you should then be in a position to switch over from the 2.6 release to the trunk (again, within the domain directory for my setup):

rm currentln -s typo-rev-855/ current

Finally, I then gave Lighttpd a boot and watched it come back up. Although this worked in the main, I tried switching over themes and viewing the blog and came across some Rails errors. Checking in the `production.log` revealed the some entries such as:

Errno::ENOENT (No such file or directory -/var/www/servers/www.oobaloo.co.uk/current/cache)

Couldn't create cache directory: META/DATA/ACTION_PARAM/www.oobaloo.co.uk/articles/index/ (Permission denied - /var/www/servers/www.oobaloo.co.uk/current/cache/META)

To remedy, I created a cache directory with the necessary permissions for the app to write to, all now seems to be running well!

A while ago, Avi posted a message to the Test Driven Development Yahoo! groups list entitled “Testing form validation in ASP.NET”.

He was working around the Model/View/Presenter pattern, and was trying to discover a way to test form validation on the client-side. Although one could implement validation within the presenter itself, he was worried validation would be repeated in multiple locations—on the client-side, within the presenter, and finally the ASP.NET validation server controls themselves.

Rightly, he chose to ignore my advice—I tend to have a way of suggesting rather grandiose solutions to problems :), but the thought has stuck with me. ASP.NET doesn’t make testing easy, and validation is (but) one aspect that it would be useful to exercise independently of the GUI.

In my experience, I’ve not found a good way to test ASP.NET controls without needing to run some kind of through-the-GUI test, and by that I mean testing by exercising the web application the controls sit in.

Although this is useful for integration testing, when starting out it’s a little heavy-weight and requires me to move in larger-than-baby-steps, and often with bad consequence.

So I’m wondering how important testability of controls (and validation in particular) is to other ASP.NET developers?

I’ve written a few validators in the past, and I very am interested to improve the quality of the code now that I’m a little older and (hopefully) wiser. Since Avi’s post surfaced (and I thought about what I’d like to do if it were me), I’m considering widening the scope of my current validation control re-writes—to include a more generic validation framework that is simpler to plug into ASP.NET, reduces the coupling, and more importantly, increases testability outside of the GUI.

Anyway, just wondering whether any other ASP.NET developers have had any validation testing nightmares? Is it enough of a headache to move to a different set of validator controls?

A while ago, Avi posted a message to the Test Driven Development Yahoo! groups list entitled “Testing form validation in ASP.NET”.

He was working around the Model/View/Presenter pattern, and was trying to discover a way to test form validation on the client-side. Although one could implement validation within the presenter itself, he was worried validation would be repeated in multiple locations—on the client-side, within the presenter, and finally the ASP.NET validation server controls themselves.

Rightly, he chose to ignore my advice—I tend to have a way of suggesting rather grandiose solutions to problems :), but the thought has stuck with me. ASP.NET doesn’t make testing easy, and validation is (but) one aspect that it would be useful to exercise independently of the GUI.

In my experience, I’ve not found a good way to test ASP.NET controls without needing to run some kind of through-the-GUI test, and by that I mean testing by exercising the web application the controls sit in.

Although this is useful for integration testing, when starting out it’s a little heavy-weight and requires me to move in larger-than-baby-steps, and often with bad consequence.

So I’m wondering how important testability of controls (and validation in particular) is to other ASP.NET developers?

I’ve written a few validators in the past, and I very am interested to improve the quality of the code now that I’m a little older and (hopefully) wiser. Since Avi’s post surfaced (and I thought about what I’d like to do if it were me), I’m considering widening the scope of my current validation control re-writes—to include a more generic validation framework that is simpler to plug into ASP.NET, reduces the coupling, and more importantly, increases testability outside of the GUI.

Anyway, just wondering whether any other ASP.NET developers have had any validation testing nightmares? Is it enough of a headache to move to a different set of validator controls?

so we’ll be good TDD citizens and the first thing we’ll do is to get a functional test that will fail. All of my functionality is in my `StoreController`, so the following test is in my `store_controller_test.rb` file:

def test_error_displayed_on_incomplete
post :create_order,
:customer => {:first_name => ””,
:last_name => ””, :email => ””}
end

assert_tag :tag => "div",    :attributes => {:id => "errorExplanation"}

This will `post` the empty string values to the controller, and then tests that we have a div with an id of “errorExplanation” in the resultant rendering.

A pattern has appeared through following this example. My view for this stage of the process is called `RegisterDetails` and has a corresponding `register_details` method which is part of `StoreController`. However, when registering, the form input is taken to the `create_order` method on the controller. Conceptually, there are 2 stages performed through the 2 separate methods:

• Rendering


• Processing

`register_details` renders the initial form, along with any errors and other messages, `create_order` actually performs the databases persistence upon successful filling of the form.

In Rails, validation is added to the model types, by adding various validator methods to the class. A simplification of my customer looks as follows

class Customer < ActiveRecord::Base  validates_presence_of :first_name, :last_name, :email    ...end

In this instance we’re checking that both name and email have been set and are not empty. If you run the tests, you should see them fail as we won’t have any error explanation div on the page.

To add validation error messages we can use the `error_messages_for` helper method, by putting the following in our `register_details` view (in this case, the `register_details.rhtml` file:

<%= error_messages_for :customer %>

This internally checks to determine whether the object (in this case `:customer`) has any items within it’s `errors` collection. If you were to run the test again now you’ll get a different error—because we’ve not put anything in `register_details` that can provide a customer for the view to render. It was this bit that had me stumped for a while, but makes sense now.

As I mentioned previously, Rails only performs validation when saving/creating/updating records—that is when there’s some kind of database persistence involved. We only need to save anything to the database is the data they post to `create_order` is valid, but we also need a `customer` accesible from `register_details`, surely that points to saving a `customer` inside `register_details`?

The answer is actually no. We create a `customer` inside `register_details`, but purely for the purposes of them answering the form—it’ll get thrown away after the rendering. So, to prevent the error from appearing we add the following to our controller:

def register_details  @customer = Customer.newend

We’ll need to add something to our `create_order` method in the controller to ensure we check the data before deciding what we do afterwards. If the user has answered incorrectly, we want them to see the registration form again, but this time, with the error message. If successful, we want to redirect.

So, continuing with the test to see the error message, we need to add the following code to pass the test:

def create_order  @order = get_order  @customer = Customer.new(params[:customer])  @order.customer = @customerend

if @order.save && @customer.save    # we'll add some stuff to process good orders soonelse    render :action => 'register_details'end

In my example, when checking out we create both an `order` and a `customer`—the former holding any order line items, and the latter the details about the customer.

For validation to work correctly in this kind of situation (where we’re validating multiple objects) we need to explicitly save both the order and customer. If we can’t save the items because of a problem with validation, we’ll then render the `register_details` view again. However, when we render it in this instance, the `@customer` variable that previously just held an ‘empty’ in-memory customer, now holds a `customer` that was created from the form. As a result, this `customer` object contains errors (that were added during the attempted save) and thus displayed as a message.

The final test is to make sure that if we do complete succesfully, we’re sent off to the `checkout` view. So, we write the following:

def test_redirected_to_checkout_when_successfully_registered  post :create_order,  :customer => {    :first_name => "Paul",    :last_name => "Ingles",    :email => "paul@here.com"     }end

assert_redirected_to :controller => "store", :action => "checkout"

and to pass we can update our `create_order` method to do the following:

if @order.save && @customer.save  update_order_from_cart  redirect_to :action => 'checkout'else  render :action => 'register_details'end

Finally, done!

I’m sure there’s more goodies tucked away in Rails’ validation helpers, but I’m not sure it’s entirely clear that saving a parent does not save it’s child (in my example, `Order.save` does not implicitly call `Customer.save` even though `Order` includes a `has_one :customer` declaration. Maybe I just missed something?

Anyway, at least I can finally go to sleep happy in the knowledge this iteration is going a little better than I thought it was earlier tonight!

so we’ll be good TDD citizens and the first thing we’ll do is to get a functional test that will fail. All of my functionality is in my `StoreController`, so the following test is in my `store_controller_test.rb` file:

def test_error_displayed_on_incomplete
post :create_order,
:customer => {:first_name => ””,
:last_name => ””, :email => ””}
end

assert_tag :tag => "div",    :attributes => {:id => "errorExplanation"}

This will `post` the empty string values to the controller, and then tests that we have a div with an id of “errorExplanation” in the resultant rendering.

A pattern has appeared through following this example. My view for this stage of the process is called `RegisterDetails` and has a corresponding `register_details` method which is part of `StoreController`. However, when registering, the form input is taken to the `create_order` method on the controller. Conceptually, there are 2 stages performed through the 2 separate methods:

• Rendering


• Processing

`register_details` renders the initial form, along with any errors and other messages, `create_order` actually performs the databases persistence upon successful filling of the form.

In Rails, validation is added to the model types, by adding various validator methods to the class. A simplification of my customer looks as follows

class Customer < ActiveRecord::Base  validates_presence_of :first_name, :last_name, :email    ...end

In this instance we’re checking that both name and email have been set and are not empty. If you run the tests, you should see them fail as we won’t have any error explanation div on the page.

To add validation error messages we can use the `error_messages_for` helper method, by putting the following in our `register_details` view (in this case, the `register_details.rhtml` file:

<%= error_messages_for :customer %>

This internally checks to determine whether the object (in this case `:customer`) has any items within it’s `errors` collection. If you were to run the test again now you’ll get a different error—because we’ve not put anything in `register_details` that can provide a customer for the view to render. It was this bit that had me stumped for a while, but makes sense now.

As I mentioned previously, Rails only performs validation when saving/creating/updating records—that is when there’s some kind of database persistence involved. We only need to save anything to the database is the data they post to `create_order` is valid, but we also need a `customer` accesible from `register_details`, surely that points to saving a `customer` inside `register_details`?

The answer is actually no. We create a `customer` inside `register_details`, but purely for the purposes of them answering the form—it’ll get thrown away after the rendering. So, to prevent the error from appearing we add the following to our controller:

def register_details  @customer = Customer.newend

We’ll need to add something to our `create_order` method in the controller to ensure we check the data before deciding what we do afterwards. If the user has answered incorrectly, we want them to see the registration form again, but this time, with the error message. If successful, we want to redirect.

So, continuing with the test to see the error message, we need to add the following code to pass the test:

def create_order  @order = get_order  @customer = Customer.new(params[:customer])  @order.customer = @customerend

if @order.save && @customer.save    # we'll add some stuff to process good orders soonelse    render :action => 'register_details'end

In my example, when checking out we create both an `order` and a `customer`—the former holding any order line items, and the latter the details about the customer.

For validation to work correctly in this kind of situation (where we’re validating multiple objects) we need to explicitly save both the order and customer. If we can’t save the items because of a problem with validation, we’ll then render the `register_details` view again. However, when we render it in this instance, the `@customer` variable that previously just held an ‘empty’ in-memory customer, now holds a `customer` that was created from the form. As a result, this `customer` object contains errors (that were added during the attempted save) and thus displayed as a message.

The final test is to make sure that if we do complete succesfully, we’re sent off to the `checkout` view. So, we write the following:

def test_redirected_to_checkout_when_successfully_registered  post :create_order,  :customer => {    :first_name => "Paul",    :last_name => "Ingles",    :email => "paul@here.com"     }end

assert_redirected_to :controller => "store", :action => "checkout"

and to pass we can update our `create_order` method to do the following:

if @order.save && @customer.save  update_order_from_cart  redirect_to :action => 'checkout'else  render :action => 'register_details'end

Finally, done!

I’m sure there’s more goodies tucked away in Rails’ validation helpers, but I’m not sure it’s entirely clear that saving a parent does not save it’s child (in my example, `Order.save` does not implicitly call `Customer.save` even though `Order` includes a `has_one :customer` declaration. Maybe I just missed something?

Anyway, at least I can finally go to sleep happy in the knowledge this iteration is going a little better than I thought it was earlier tonight!

Found via http://www.updrift.com/article/questions-ruby-on-rails-skeptics-ask.

`for order in Order.find(:all)
puts “Item ordered: #{order.line_item.product_id}
puts “Description: #{order.line_item.product.description}
end`

In this example, there would be one database call for the main order, then two calls to retrieve the line item information then the product description. Here’s a much better approach.

`for order in Order.find(:all, :include => [:line_items, :product])
puts “Item ordered: #{order.line_item.product_id}
puts “Description: #{order.line_item.product.description}
end`

Very similar code, but in the latter version the :include attribute tells Rails to preload the line items and products, so it loads up everything in one database call rather than multiple ones. You also have the option of using the find_by_sql function to specify your own custom call.

Found via http://www.updrift.com/article/questions-ruby-on-rails-skeptics-ask.

`for order in Order.find(:all)
puts “Item ordered: #{order.line_item.product_id}
puts “Description: #{order.line_item.product.description}
end`

In this example, there would be one database call for the main order, then two calls to retrieve the line item information then the product description. Here’s a much better approach.

`for order in Order.find(:all, :include => [:line_items, :product])
puts “Item ordered: #{order.line_item.product_id}
puts “Description: #{order.line_item.product.description}
end`

Very similar code, but in the latter version the :include attribute tells Rails to preload the line items and products, so it loads up everything in one database call rather than multiple ones. You also have the option of using the find_by_sql function to specify your own custom call.

Once again I’ve been thinking about the XP practice of slack recently, again prompted by the raging (but excellent) discussion on the Yahoo! groups XP mailing list. In particular, due to some freelance work I’m in the process of preparing for etc.

Committal with regards to XP quotes/planning.

Is it needed? Customer + Developer side.

Mini-milestones—Leadership/Management, motivation etc.

Once again I’ve been thinking about the XP practice of slack recently, again prompted by the raging (but excellent) discussion on the Yahoo! groups XP mailing list. In particular, due to some freelance work I’m in the process of preparing for etc.

Committal with regards to XP quotes/planning.

Is it needed? Customer + Developer side.

Mini-milestones—Leadership/Management, motivation etc.