Here’s a gist showing what I ended up doing:

module Count
  def fake_count
    words.count + 500
  end
end

class Thing
  def words
    %w(one two three)
  end
  def count
    words.count
  end
end

def assert(value)
  raise "Assertion failed" unless value == true
end

thing = Thing.new
assert thing.count == 3
puts thing.count

class Thing
  include Count
  alias_method :real_count, :count
  alias_method :count, :fake_count
end

thing = Thing.new
assert thing.count == 503
puts thing.count

class Thing
  alias_method :count, :real_count
end

thing = Thing.new
assert thing.count == 3
puts thing.count

1. Create a module that has the faked version of the method
2. Open up the original class and include the module (I want it on all instances – if it were just one I’d use extend)
3. While the class is open call alias_method :real_count, :count which creates an alias of real_count that points to the count method
4. While still in the open class, call alias_method :count, :fake_count which creates an alias of count to the fake_count method. Note that real_count still points to the original implementation

Once the class has been opened and modified it will return the new value. To undo the change I can just open up the class again and call alias_method :count, :real_count which makes count behave as it did originally.

Why not stub? In this case I wanted to use a method in Thing and just add 500 to it. I probably could have also called real_count + 500 which would have effectively decorated the original count method.

Can you think of alternative approaches? Let me know in the comments.

First of all we’ve outlined how to deal with some of the dependency issues we had not yet dealt with, such as less-than, less-than-or-equals-to and not-equals. Additionally we outlined how to deal with situations where a dependency defines 2 or more requirements (such as ["> 1.0.0", "<= 2.0.0"]). We’ve also added in support for listing all known versions of a specific gem by moving the notion of the latest gem version so it uses a prefix of latest and then putting one PTR for each version of the gem on the gem domain name.

In addition to working on the details of the spec we also got some data loaded! Thanks to the work Jeremy did previously on his Gemology project a lot of the code had already been written. I spent some time working on moving the code we needed into the rubygems-dns project while Jeremy worked on exporting the existing specs we needed from his database and writing an import script. While the implementation is far from complete I’m happy to say that you can actually query the DNS server now and answer questions with it.

First a query to list all of the versions of a gem. We’ll use the Sinatra gem as an example:


dig @ns8.dnsimple.com sinatra.index.rubygems.org PTR


The result will be an unordered list of PTR records, with each record representing a version with the version number in reverse order:


sinatra.index.rubygems.org. 86400 IN PTR 1.3.0.sinatra.index.rubygems.org.
sinatra.index.rubygems.org. 86400 IN PTR 0.1.0.sinatra.index.rubygems.org.
sinatra.index.rubygems.org. 86400 IN PTR 5.1.0.sinatra.index.rubygems.org.
sinatra.index.rubygems.org. 86400 IN PTR 6.1.0.sinatra.index.rubygems.org.
sinatra.index.rubygems.org. 86400 IN PTR 7.1.0.sinatra.index.rubygems.org.
sinatra.index.rubygems.org. 86400 IN PTR 0.2.0.sinatra.index.rubygems.org.
...snip...


So the first line indicates that there was a 0.3.1 version of Sinatra and line 2 indicates there was a 0.1.0 version of Sinatra.

Next, let’s get the latest version:


dig @ns8.dnsimple.com latest.sinatra.index.rubygems.org CNAME



latest.sinatra.index.rubygems.org. 600 IN CNAME e.0.3.1.sinatra.index.rubygems.org.


This shows us that 1.3.0.e is the latest sinatra version published (as of the snapshot).

Next, we can query for PTR records for that same name:


dig @ns8.dnsimple.com latest.sinatra.index.rubygems.org PTR



latest.sinatra.index.rubygems.org. 600 IN CNAME e.0.3.1.sinatra.index.rubygems.org.
e.0.3.1.sinatra.index.rubygems.org. 86400 IN PTR 1.tilt.index.rubygems.org.
e.0.3.1.sinatra.index.rubygems.org. 86400 IN PTR 1.rack.index.rubygems.org.


This shows us that the version 1.3.0.e has two runtime dependencies, tilt and rack, and that they require the latest version of the 1.x releases for each of those. We can then use:


dig @ns8.dnsimple.com 1.tilt.index.rubygems.org PTR


To show us that the latest version:


1.tilt.index.rubygems.org. 600 IN CNAME 2.3.1.tilt.index.rubygems.org


That’s it for now. There is more work to do, like encoding the <, <=, != and dependencies with 2 or more requirements, but this will at least give an example how this all might actually work.

I currently am trying two approaches to extracting logic into modules. First, I have created a directory in lib where extracted modules will live. I choose to call this directory logic since essentially I’m trying to use it as a place to store logic (as opposed to storing code that describes data models, which will remain in the app/models directory. For simpler classes that only have a small amount of logic I am extracting all of the logic into a single file with the same name as the existing model. For example, for a Contact model the logic would go into a Logic::Contact module. This module is then mixed back into the module. Here is a (somewhat contrived) example:

Before the extraction:

class Contact < ActiveRecord::Base
  belongs_to :user

  def name
    "#{first_name} #{last_name}"
  end
end

After the extraction:

class Contact < ActiveRecord::Base
  include Logic::Contact
  belongs_to :user
end

module Logic
  module Contact
    def name
      "#{first_name} #{last_name}"
    end
  end
end

This is the simplest form of extraction. Beyond this however is another form of extraction that I am using in cases of larger, more complex classes. In this case I group together some of the logic into a module, usually naming it so it describes the behavior. For example, I have a module in DNSimple called Logic::Domain::Renewable which contains logic for domain renewal.

class Domain < ActiveRecord::Base
  # ...lots of code...
  def auto_renew?
   registry_domain.auto_renew?
  rescue => e
    logger.error e
    false
  end
  # ... more code ...
end

Becomes

class Domain < ActiveRecord::Base
  include Logic::Domain::Renewable
end

module Logic
  module Domain
    module Renewable
      def auto_renew?
       registry_domain.auto_renew?
      rescue => e
        logger.error e
        false
      end
    end
  end
end

The beauty of extracting in this way is that the different behaviors required by the system seem to align nicely into modules which make it much easier to locate code as I continue to develop the system.

So what might the tests look like after these extractions? I already have a fairly comprehensive test suite for DNSimple (yes, there are gaps) so it already is a little bit slow (although not as slow as it would eventually become). With the extractions I can began to test the logic in isolation. For example:

require 'lib/logic/contact'

class FakeContact
  include Logic::Contact
  attr_accessor :first_name, :last_name
end

describe Logic::Contact do
  subject do
    contact = FakeContact.new
    contact.first_name = "Anthony"
    contact.last_name = "Eden"
    contact
  end

  it "has a name" do
    subject.name.should eq("#{subject.first_name} #{subject.last_name}")
  end
end

What I’m doing here is creating a contact class that is not in any way tied to ActiveRecord. This allows me to completely bypass the Rails loading process and these logic tests will run extremely fast. If you take this route you’ll need to make sure to use a modified spec helper that does not load the Rails environment. I call mine lightweight_spec_helper and only load what I need in it.

In closing, all of this is designed to make the application code easier to manage so that I can continue to improve DNSimple and make my customers happier. All of this is really only possible because I have a decent amount of test coverage, allowing me to refactor and not blow up everything in the process. Inevitably during refactorings like this things will break, but my tests cover me and protect me from myself, and thus I can extract and improve without feeling like I’ll shoot myself in the foot.

While I was there I gave a talk called “Why Ruby, Why Now?” at the first dyncon as well as a talk titled Harnessing Cucumber at Valtech Labs. The first talk was an introduction to Ruby. I have been itching to give an introductory talk for a while and I’m glad this gave me the chance. The audience was a bit more knowledgeable about Ruby than I expected, so some of the items weren’t new to them, however I believe there was still enough in the talk to keep people interested. I also blazed through it since it was right before lunch so maybe people were enthralled merely by my lightning-fast presentation skills. The presentation is available online on Github: https://github.com/aeden/presentation_why_ruby and was created using Scott Chacon’s Show Off.

The second talk I gave was an intermediate to advanced talk on Cucumber where I covered a lot of what I have learned about Cucumber over the last year of using it. Cucumber has become an important part of my test suites because it allows me to test the experience of using my software. This talk covered some of the various command-line switches and cucumber.yml configuration options in the first section and then moves onto testing APIs and CLIs. I’ve found that testing both of these interfaces to my applications has helped tremendously in improving the application and at the same time providing a safety net for refactoring, which is exactly what I want from Cucumber. This talk is available as a PDF and was created using Keynote.

I appreciate the support from both of the audiences and the discussions that followed both talks and I look forward to the opportunity to visit Stockholm again in the not-to-distant future. Thanks as well to Peter Svensson for putting together dyncon and to Peter Lind for opening up the Valtech offices for my talk there.

And here is how it might be used:

Give it a try using the following:

ruby retryable_test.rb

What do you think? How can this be improved?

This evening Corey and I sat down and started looking into how we could make the tests live again. First we attempted to use Capybara directly, but ran into issues when trying to set HTTP headers. The DNSimple API uses Basic HTTP Authentication and thus we needed to set the header for that. We also need to set the Content-Type and Accept headers to ensure that Rails handles the input and output correctly. After peeling back some layers of the Capybara onion we landed upon Rack::Test. When using Rack, Capybara delegates request and response handling down to Rack::Test. At this point we decided to see if we could use Rack::Test directly in our step definitions, and it worked like a charm.

Rack::Test has a module called Rack::Test::Methods that can be mixed into a class to provide it with methods for get, post, put, delete as well as last_request, last_response, header and more. We mixed Rack::Test::Methods into the Cucumber world at the top of our API steps file like so:

Then our steps could simply call the Rack::Test methods directly. For example, here’s how to send the HTTP Basic Auth header:

And to set content type and accept headers:

And finally to actually send requests and test the responses. The entire api_steps.rb as it is right now looks like this:

And here is an example of a Cucumber feature that uses the API steps:

I doubt we’ve ended up with the ultimate final set of steps that can be used repeatedly for testing RESTful APIs, however I think it is an excellent start. I’m still on the fence about how to check the response body, specifically whether it is better to match the response body as a string or to actually parse it and write custom steps for each of the different types of objects, but time will tell.

As usual pairing with Corey resulted in some good code, a usable solution and something that I think others will benefit from as well.

Now RSpreedly::Subscriber instances will always be stubbed. Simple and sweet.

First of all let’s look at the most obvious attack vector, which is pretty simple: a malicious user would enter a script into the person name field and save that and then it would execute the script when the person is rendered in the person list. First I verified that this attack vector worked, and yes it did work, so then I considered where the value entered by the user needed to be sanitized. It’s pretty straightforward to sanitize the rendering when Rails is involved, just add the h() helper before the name output in the listing, so line 4 of index.html.erb becomes:

This is a fairly standard idiom in Rails (not necessarily the best way to sanitize user input, but the most common way to do it). This fix only fixes the problem when the page is rendered by Rails, but it does not address the issue for items that are added via Ajax, and here is where things get a bit tricky.

You’d think that sanitizing user input in JavaScript would be fairly easy, and to be clear you can do it with the JavaScript escape() function, however this results in some pretty ugly percent-encoded content (which may or may not matter to you. I was curious though whether there was something similar to the h() helper in Rails available in JavaScript. There is but finding it proved to be a bit of a challenge.

What I ended up doing what searching Stack Overflow for solutions that others had come up with and eventually landed upon this bit of code: http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/plugin/html-sanitizer.js. Unfortunately this bit of code by itself doesn’t work unless you have another JS library (html4) and that library requires building with Ant. Fortunately additional searching led me to a minified version with everything already compiled. I’ve included this minified library as html-sanitizer-minified.js and added a call to html_santize before rendering the person name in the JavaScript as such:

..and it works. I’ve deployed this fix to http://rails-jquery-unobtrusive.heroku.com/ and have updated the github repo so you can see the changes in action.

So is this the best solution for handling user input and avoiding XSS when you want to build HTML in JavaScript? I’m not sure. It’s probably not the only solution so feel free to add yours in the comments below. Also, consider this a warning if you are developing JavaScript code that builds and renders HTML: tainted user input is a threat and you need to deal with it.

If you want to go straight to the code it is available on Github: http://github.com/aeden/unobtrusive-jquery-example. I have also put a live demo on this up on Heroku: http://rails-jquery-unobtrusive.heroku.com.

Rather than going through all of the steps needed to set up a Rails app, the best thing to do is to follow along in the code from the example above.

First let’s take a look at the PeopleController (app/controllers/people_controller.rb):

This looks like a fairly normal RESTful controller. The one exception is the delete method, which will be used by browsers that have JavaScript turned off to provide a page that 1.) confirms that the record should be deleted and 2.) has a form that can post to the destroy method.

Next, let’s take a look at the index view:

There is a list of people with each person having a delete link next to their name. The delete link points to /person/:id/delete which will execute the delete action that I mentioned above (I’ll show you how to remove the “/delete” part of that link with JavaScript later). There is also a form for adding a new person. Note that there is no JavaScript in this page, just normal HTML elements with classes.

While we’re looking at views, let’s look at the only other view, the delete view:

This is just a simple form that confirms that they want to delete the user and provides a cancel link back to the people_url if they don’t. Note that the form tag uses the REST-ful URL for accessing the resource and sets ‘_method’ to ‘delete’ in the hidden field tag.

Finally, let’s take a look at the most complicated bit, the jQuery JavaScript. To make things easier to follow I’ll go through it piece by piece, starting with the document ready handler:

This is the jQuery way for executing code when the document has finished loading. All it does is call two methods, one for connecting up the add form and one for connecting up the delete links. To keep things organized and namespaced a bit I placed these two methods onto a JS object called ‘Actions’. First, the connectAddForm implementation:

This function finds the form element with the class “people” and attaches an event handler to the submit event. When the form is submitted an AJAX POST is made. The data type is JSON, which will call the ‘create’ action in the people controller with the accepts type set to a value that triggers Rails to render JSON as the response. The form is serialized and passed as data and when a successful response is received a bit of HTML is appended to the people list and the person name field is cleared.

Now for the connect delete links JavaScript:

Here each element that is in the people list that matches the selector a.delete and adds a click handler to it. Notice that I used the jQuery live method here, the benefit being that as new records are added, and new elements that match the selector expression are added automatically get the click handler that I define here. This saves me from the trouble of having to add the handler each time that a record is added to the page. The click handler first finds the li that it may eventually delete, displays a confirmation message to the viewer and if they confirm that they want to delete the record it will post via AJAX to the /person/:id URL with the method ‘delete’. The URL is pulled from the anchor’s href attribute and the ‘/delete’ is removed using a simple regular expression replace. Upon a successful delete the li that was found earlier is hidden using the slideToggle() function.

That’s it. You can try this in a browser either with JavaScript turned on, in which case it’ll use all of the JavaScript goodness, or you can turn of JavaScript and see the magic of graceful degradation. I hope you’ve enjoyed reading this little tutorial and if you have any suggestions on how to improve the code in the project please feel free to fork the github project, make your changes and send me a pull request. I’ll add any cool mods into the tutorial as I can.

Update: I’ve published a follow-on article that talks about changes to the code for this tutorial to handle sanitizing user input both in Rails and in JavaScript. I suggest reading it to understand XSS vulnerabilities that you need to deal with when accepting user input.

Here are the slides for my talk: Technical Debt . I’ve left the presenter notes in so you can see what I was thinking when I put the slide together (since most of the slides are just pictures anyhow.) Enjoy!