SelfDiagnose for Ruby on Rails

SelfDianogse is a library of tasks to diagnose a running system with respect to its dependent external resources. Recently, I did some Rails development and was thinking about how to implement it for the Ruby on Rails framework ? Obvious choice is to make a plugin that on installation adds the SelfDiagnoseController.rb to the application. Because of the scripting nature of Rails framework, putting the configuration in XML (as it is done for Java) is not the Ruby-way. So either use YAML or put the configuration directly into the controller. Let’s investigate the latter.

class SelfdiagnoseController < ActionController
  include SelfDiagnose

  tasks {
      check_database_connection 'mysql'
      check_directory_readable '/path/to/dir'
      check_log_writeable 'production.log'
      check_url_accessable 'http://s3browse.com'
  }
end

And the module would be defined as something similar to:

module SelfDiagnose
  def tasks
    yield if block_given?
  end
  def check_database_connection(db_name)
    # create a new CheckDatabaseConnection task and register it for running
  end
  def check_log_writeable(log_name)
    # create a new CheckLogWriteable task and register it for running
  end
end # module

Looking back at this approach, I don’t see the need for having a task registration in the Rails version of SelfDiagnose. I might as well implement the controller like this:

class SelfdiagnoseController < ActionController
  include SelfDiagnose

  def index
      check_database_connection 'mysql'
      check_directory_readable '/path/to/dir'
      check_log_writeable 'production.log'
      check_url_accessable 'http://s3browse.com'
  end
end

Then, the index.html.erb will put together a nice report of the results.

Amazon Web Services Test Drive Needed

Designing and implementing applications that make use of Amazon Web Services such as S3, SQS and SimpleDB, require extensive testing to ensure a robust integration. In addition to scenarios for the “happy flows”, test scenarios should be created to handle the critical exceptional situations. How does my application respond to failures in communication, checksum errors, service unavailability, never ending transactions and extremely frequent or heavy traffic?

In the spirit of test driven development, I see a need for writing up such scenarios and simulate the unexpected behavior of AWS just to verify the correct handling of each exceptional event. Such a Test Drive service would implement the API of services available at Amazon Web Services. It should provide extra control services to put a Web Service in some “testing mode” such as “simulate disk failure”, “simulate terminated http connection” or “simulate invalid access key”or a combination thereof.

To implement the persistent feature available in SQS, S3 and SimpleDB, a basic filesystem or relation database could be used to support test scenarios that involve more then one request. And of course all actions are properly logged and event information is made available to verify that a scenario is completed with success, i.e. the exceptions are handled correctly.

Finally, if I had such a Test Drive Service, I could startup multiple instances on different machines and run scenarios that involve combinations of AWS services SQS, S3 and SimpleDB. How much effort is needed to build such a Test Drive Service in e.g. Ruby on Rails? Isn’t this a common testing practice for all public service APIs out there on the Web?

Deploying Flex using Capistrano

Capistrano is a deployment tool initially created to support the remote installation of Rails applications. One of the assumptions Capistrano makes is that the application (source) can be pulled out of a source code management system such as Subversion.

In case of Adobe Flex applications, compiled sources (SWF,HTML,…) need to be deployed to the Web server. So instead of pulling sources from a repository, I needed to push compiled code to the server.

The script below overrides the update_code task of the standard recipe and defines the steps to secure copy the compiled sources to the release location. To make this also work on the Windows platform, you need to install pscp

Now, just as any other Rails application, you can say:

cap deploy

and the application will be deployed to a new release location on the Web server.

Get the source of this Capfile from my public S3 bucket.

Note: the version shown here will not work for deploying on multiple web servers. This is on my big TODO list…