Data Noise

It's a quite common for an action to finish by sending a confirmation email to the client. Usually you don't want to put this logic directly in your model. Models deal with a business rules and shouldn't care about emails or any other infrastructure nonsense (unless of cause this is the business domain of your application). In Rails you define your business logic in terms of ActiveRecord::Base and the delivery of emails in terms of ActionMailer::Base. In order to decouple these two, Rails provides a mechanism of ActiveRecord observers. These glue objects listen for changes in the model and react accordingly (usually using after_save method). If we need to perform a complex operation that involves updating several tables, it is better to wrap it with a database transaction. What I didn't pay attention to is that observer's after_save method is also a part of the transaction, meaning the transaction will remain open until this method finish.

This lead to a potential problem. What happens when your email server is under heavy load or you have some kind of DNS problem and the address resolution takes unusual amount of time? Your transactions will stay open for a long time and some of them will eventually time out.

Preface

Overcomplicated specifications lead to overcomplicated implementations. Lately I've been fixing issues with ActionWebService framework - a soon to be removed part of Ruby on Rails. I have to use SOAP in the web application I'm developing. My client needs to keep his product inventory in a good shape and he requested to implement some of the inventory management functionality using handheld devices. There is a .Net environment available for this kind of devices and it works very well. So I desperately needed a functional web service implementation for Rails. That why I volunteered to fix AWS. And that's when I found out that ruby-breakpoint just doesn't cut it. Don't get me wrong, soap4r is a fine piece of software, but SOAP is difficult and obscure, which leads to complicated libraries that implement it. The situation is even worse when such libraries have almost no documentation whatsoever.

So instead of just stopping at some point in your program to examine the environment (the facility offered by ruby-breakpoint library), ruby-debug extension offers the full-fledged debugger for Ruby. The main difference between ruby-debug and the standard debug.rb library is the speed of the execution. Major problem with debug.rb is that it uses Kernel#set_trace_func method, which requires creation of Binding object for each hook invocation. It is fine for small scripts, but for the real world applications like Rails ones, debug.rb is almost impossible to use. You just sit and watch how Ruby interpreter creates enormous amount of Binding objects, just in order to destroy them with the immediate garbage collection cycle. It also explains that ruby-debug doesn't support watchpoints for the same reason.

I've been watching a thread on ruby-talk about the possibility to have a faster debugger for Ruby.

Now when Ruby 1.8.4 has a better C based API for tracing code execution, it is possible to significantly speed up debug.rb. I've been playing with this idea for last two days and came up with ruby-debug extension:

Follow these easy steps:

• Download extension ruby-debug-0.1.gem.
• Install it with sudo gem install ruby-debug-0.1.gem

• Use either

      $ rdebug _your-script_
  

  Or for your Rails application:

  1. Add to your config/environments/development.rb

      require 'ruby-debug'
     

  2. Use Kernel#debugger method to interrupt your application and invoke debugger

      def myaction
       ...
       debugger
       ...
      end
     

Enjoy.

Update. I've created a project on rubyforge.org for this extension and uploaded a bugfix version 0.1.2. Now you don't have to download the gem file from this site. Just use

    $ gem install ruby-debug

command to install it.