mattberther.com

Problems running cucumber with nokogiri

2009-09-24T23:51:00Z

I installed cucumber last night and began trying to get some of the scenarios to work. One thing that kept plaguing me was the error message that kept coming up about using an old version of libxml2:

HI. You’re using libxml2 version 2.6.16 which is over 4 years old and has plenty of bugs. We suggest that for maximum HTML/XML parsing pleasure, you upgrade your version of libxml2 and re-install nokogiri. If you like using libxml2 version 2.6.16, but don’t like this warning, please define the constant I_KNOW_I_AM_USING_AN_OLD_AND_BUGGY_VERSION_OF_LIBXML2 before requiring nokogiri.

It turns out that this was relatively simply to correct on OSX Leopard by executing the following commands:

sudo gem uninstall nokogiri
curl -O ftp://xmlsoft.org/libxml2/libxml2-2.7.3.tar.gz
tar -zxvf libxml2-2.7.3.tar.gz
cd libxml2-2.7.3
./configure
make
sudo make install
sudo gem install nokogiri -- --with-xml2-include=/usr/local/include/libxml2 --with-xml2-lib=/usr/local/lib

Although I did not see any problems from using the old version, I did get frustrated by receiving the error all the time. Problem solved.

IIS7 and static files

2009-07-16T23:19:12Z

So, the other day I was trying to debug a problem with one of our web applications. I had gone through the steps of making the appropriate changes to my IIS configuration for this application, so that it utilized the Classic .NET App Pool and everything seemed to be running properly. That is, until I noticed that some javascript files and some images were not rendering properly.

As I utilized Firebug to try and understand what was going on, I saw that the javascript and image files were being sent with a content-length header of 0 bytes. Curious, what was causing this for some files but not all? I finally realized that the difference was that the files not being sent were static files.

Thoroughly befuddled now, I began to scour the web.config file to see if something had gotten committed that caused this to happen. This was not the case. Ultimately what I found was that Microsoft, in their infinite wisdom, decided that, when picking the default settings for installing IIS7 on Windows 7 RC, people probably did not have static content that they would like to publish on the web, and therefore left the static file handler turned off. Seriously! WTF?!

Chuck Norris: The Programmer

2009-06-15T21:10:03Z

Saw this from codesqueeze earlier today… Hilarious stuff. :)

When Chuck Norris throws exceptions, it’s across the room.
All arrays Chuck Norris declares are of infinite size, because Chuck Norris knows no bounds.
Chuck Norris doesn’t have disk latency because the hard drive knows to hurry the hell up.
Chuck Norris writes code that optimizes itself.
Chuck Norris can’t test for equality because he has no equal.
Chuck Norris doesn’t need garbage collection because he doesn’t call .Dispose(), he calls .DropKick().
Chuck Norris’s first program was kill -9.
Chuck Norris burst the dot com bubble.
All browsers support the hex definitions #chuck and #norris for the colors black and blue.
MySpace actually isn’t your space, it’s Chuck’s (he just lets you use it).
Chuck Norris can write infinite recursion functions…and have them return.
Chuck Norris can solve the Towers of Hanoi in one move.
The only pattern Chuck Norris knows is God Object.
Chuck Norris finished World of Warcraft.
Project managers never ask Chuck Norris for estimations…ever.
Chuck Norris doesn’t use web standards as the web will conform to him.
“It works on my machine” always holds true for Chuck Norris.
Whiteboards are white because Chuck Norris scared them that way.
Chuck Norris doesn’t do Burn Down charts, he does Smack Down charts.
Chuck Norris can delete the Recycling Bin.
Chuck Norris’s beard can type 140 wpm.
Chuck Norris can unit test entire applications with a single assert.
Chuck Norris doesn’t bug hunt as that signifies a probability of failure, he goes bug killing.
Chuck Norris’s keyboard doesn’t have a Ctrl key because nothing controls Chuck Norris.
When Chuck Norris is web surfing websites get the message “Warning: Internet Explorer has deemed this user to be malicious or dangerous. Proceed?”

Properly utilizing XslCompiledTransform

2009-02-28T02:30:02Z

Not long ago, we noticed some degradation in performance after we upgraded to .NET 2.0 and migrated to the XslCompiledTransform class from the now obsolete XslTransform class. Our implementation was fairly straightforward, although we hid it behind an interface for easy mocking/testing.

The code looked something like the below:

public interface TransformLoader
{
    XslCompiledTransform Load(string name);
}
 
class XslTransformLoader : TransformLoader
{
    public XslCompiledTransform Load(string name)
    {
        XslCompiledTransform transform = new XslCompiledTransform();
        transform.Load(name);
        return transform;
    }
}

This is a pretty standard implementation, although after JetBrains .Trace pointed out that a majority of the time was being spent in the Load method, we started doing some research. As it turns out, we mistakenly understood the XslCompiledTransform to be smart enough to determine whether or not the transform had already been compiled. If it was, we thought, it would use the compiled version. As it turns out, this is not the case. To effectively utilize this class, it is important to save off the instance of the class for subsequent uses.

To do this, we created a new implementation, the CachedXslTransformLoader, which looks like this:

class CachedXslTransformLoader : TransformLoader
{
    private Dictionary<string, XslCompiledTransform> transforms = new Dictionary<string, XslCompiledTransform>();
 
    public XslCompiledTransform Load(string name)
    {
        XslCompiledTransform transform = null;
        if (!transforms.TryGetValue(name, out transform))
        {
            transform = new XslCompiledTransform();
            transform.Load(name);
            transforms[name] = transform;
        }
 
        return transform;
    }
}

When running the older XslTransformLoader through a loop of 100 transformations with our XSLT and XML files, we found that it was taking approximately 48 seconds to transform the entire loop. However, when utilizing the new CachedXslTransformLoader, the exact same loop only took 1.3 seconds to execute.

This is where the performance improvements from the XslCompiledTransform really come to fruition, so make sure that you are saving off the instance of the class. As we saw, the class is not smart enough to determine whether or not the XSL has already been compiled.

By the way, the performance problem we were experiencing went away with this minor change. On another note, it was nice to see this adhere to the open/closed principle. We were able to correct issues in the system by adding new code, not by touching existing/tested code.

Bottom line: when using XslCompiledTransform, make sure to save off the instance and reuse it for maximum performance benefit.

Sometimes the problem is in your tests

2009-02-13T21:29:38Z

I was TDDing a new website that I’ve been working on last night and got caught in the interesting predicament where the tests failed, but the production code worked. For the life of me, I could not figure out why my test was failing. It turns out, I missed a tiny little piece of documentation on how shoulda works.

By the way, before we get into this, if you are writing Ruby code and writing tests (you are, arent you?), do yourself a favor and check out the shoulda library. Excellent work from the great folks at thoughtbot.

context "with valid attributes" do
  setup do
    @user = Factory.create(:user)
    @updated_attributes = Factory.attributes_for(:user)
 
    put :update, :id => @user.id, :user => @updated_attributes
  end
 
  should_not_change "User.count"
  should_respond_with :success
  should_redirect_to 'root_url'
end

For quite some time, every test was passing with the exception of should_not_change "User.count". After consulting the documentation and source code for shoulda, I realized what should_not_change was actually doing.

The should_not_change macro was evaluating the User.count statement *PRIOR* to the setup method executing and stored the result in a variable. Then when the test executes, it evaluated the User.count statement again. Since the Factory.create call in the setup method created a new instance in the database, of course, User.count would change.

To get around this particular example, I ended up having to create a nested context to make the test pass. I dont necessarily like this, but it does get the test to pass and gives me an opportunity to change it if someone has a better solution.

context "updating User information" do
  setup do
    @user = Factory.create(:user)
    @updated_attributes = Factory.attributes_for(:user)
  end
 
  context "with valid attributes" do
    setup { put :update, :id => @user.id, :user => @updated_attributes }
 
    should_not_change "User.count"
    should_respond_with :success
    should_redirect_to 'root_url'
  end
end

Indeed, sometimes the problem lies in your tests.

puts vs print in ruby

2009-02-12T02:46:47Z

I discovered something a bit peculiar about the puts and print methods in Ruby. puts seems to flush immediately, and therefore shows up on $stdout right away. Take the code example below:

5.times {
  puts "."
  sleep 2
}

This functions exactly the way that you would expect. It places a single period on $stdout, followed by a two second pause for five iterations. puts inserts a new line character as well, so instead of placing each period on the same line, each one is on a new line. print does not insert the automatic newline sequence, so it would place each one on the same line. However, the code below does not function the way you would expect.

5.times {
  print "."
  sleep 2
}

The code above waits for 10 seconds and then prints all 5 periods. As it turns out, this is because the print method buffers the output. The easiest way to get around this (for a situation like the above) is to set the sync property on $stdout.

STDOUT.sync = true
5.times {
  print "."
  sleep 2
}

This sets $stdout to avoid buffering the input, which most modern operating systems do. If you find yourself in a situation where you need to have a small amount of output sent immediately to the screen, this is a good technique to utilize to serve this requirement.

Implementing method_missing

2009-02-11T06:41:32Z

Earlier, I was working on creating a script that would iterate a set of folders and execute a chunk of code against that file when it was found. The script itself is easy enough to write with straight ruby. For example:

Dir.glob("./**/*").each do |f|
  # your ruby code here
end

However, as much as we tend to do this during our daily life, I was hoping to hide this behind an api that some less technical users may be able to use. To promote reuse, I created a class that would provide this functionality.

class FileWalker
  def root_path=(path)
    @root_path = path
  end
 
  def each_file_of_type(type, &block)
    Dir.glob("#{@root_path}/**/#{type}").each do |f|
      yield f
    end
  end
end

The users of this API utilized it in a manner which you would expect (coming from a statically-typed language):

walker = FileWalker.new
walker.root_path = "."
walker.each_file_of_type("*.rb") do |file|
  # your ruby code here
end

While this covered the functional requirements of what I was hoping to do, I really did not like the way this reads. One, the user of the API was expected to implement the wildcard for the type. Two, did I say that I didnt like the way it reads? What I was really hoping for was an API that worked like this:

FileWalker.dir "." do
  each_rb_file do |f|
    # your ruby code here
  end
end

The first thing you’ll notice is that I remove the file specification from the call with the each_rb_file method. However, I certainly do not want to corrupt the FileWalker class with dozens of methods to iterate different file types. Having to add a new method every time I want to iterate a different file type would most certainly violate the open/closed principle.

As I thought about the best way to accomplish both the API I desired and the long-term maintenance, I decided to take advantage of a great method on ruby’s Object class called method_missing. method_missing is a method that gets called every time a method on the receiver does not exist. The method gets passed three arguments, the name of the method, any arguments to the method, and a block to execute.

Using a little regexp magic, I am able to intercept calls to each_rb_file and delegate them to the earlier each_file_of_type method (which is now private). Take a look:

class FileWalker
  def initialize(path)
    @root_path = path
  end
 
  def self.dir(path, &block)
    walker = new(path)
    walker.instance_eval(&block) if block_given?
  end
 
  def method_missing(method, *args, &block)
    if method.to_s =~ /^each_(.+)_file/
      each_file_of_type "*.#{Regexp.last_match[1]}", &block
    end
  end
 
private
  def each_file_of_type(type, &block)
    Dir.glob("#{@root_path}/**/#{type}").each do |f|
      yield f
    end
  end
end

So, as you can see with a little method_missing mojo, we now have access to any number of methods that allow us to retrieve all files of a particular extension. The above script and class will work with any sort of file extension. Calling each_exe_file, each_xml_file, or each_py_file will all function the same way, without adding any new code. The advantage here, as mentioned earlier, are that 1) we get to provide a *readable* API to our consumers, and 2) we conform to the open/closed principle by not having to modify already written and tested code to implement a new extension.

If you’ve not looked much at method_missing and ruby, I encourage you to discover it more. I’ve only touched the surface with its capabilities. Others have gone much further, including implementing an entire XML dsl utilizing this method.

Perhaps in a subsequent post I’ll dive into how I’d go about implementing this… til then.

Testing Helper Modules with Rails 2.2

2009-01-28T05:03:21Z

I recently found myself in a situation where I wanted to make sure that the current year is always displayed in the copyright statement at the bottom of a Rails application. At first glance, this is easy enough. All that a person needs to do is add the following to their application.html.erb:

Copyright &copy; 2007-<%= Date.today.year.to_s %>

However, as we start to implement this, it becomes apparent that this is not very test driven. I sought to find a way to implement and verify this functionality with a breaking test first.

Since view tests can often be very brittle, I really wanted to implement this in my ApplicationHelper module, so that I could hopefully test it easier, but also reuse to functionality in other areas.

Testing Rails helpers has been hard historically, but as I investigated how I might test this functionality in the ApplicationHelper module, I discovered the ActionView::TestCase base class. This class provided all the hook up that I needed to call methods on my helpers. Armed with this, I set out to write my test:

class ApplicationHelperTest < ActionView::TestCase
  def test_copyright_includes_current_year
    actual_copyright = copyright_text()
    assert(actual_copyright.include?(Date.today.year.to_s), "Copyright must include current year.")
  end
end

This fails pretty quickly, since it cant find ActionView::TestCase. The easiest way to resolve this is to add require 'action_view/test_case' to your test_helper.rb. When we run the test again, it fails again, since the copyright_text method does not exist, so we flip back over to the ApplicationHelper module and implement the method.

def copyright_text
  "Copyright &copy; 2007-#{Date.today.year}, Company Name. All Rights Reserved."
end

Voila. Our tests now pass. The last step is to add a call to this helper method in the view:

<%= copyright_text %>

We may take this a step further and also implement additional checks around the copyright statement, which can be easily done with the assert_match method. This was not needed in my particular case though.

New MacBook Pro

2009-01-20T03:58:12Z

About 18 months ago, I purchased my first MacBook Pro… a 17 inch monster laptop. I absolutely loved the big (1920×1200) display that I purchased as an additional feature.

Over the course of the past year, I realized that I was not really very mobile with that behemoth. Obviously, at more than 17 inches wide and almost 7 pounds, it can be quite a cumbersome unit to drag around with you. Even more, the space it takes up on your lap makes it almost unusable. Calling it a “laptop” was a bit of a stretch.

No more… earlier today, I traded in that MacBook Pro and got the new 15″ unibody MBP. 320gb of drive space, with 4gb of ram packed into a nice little 5 pound chassis. Not quite as small as my wife’s 13″ MacBook, but certainly more inline with what I would consider a laptop. All that said, I really do miss the 1920×1200 resolution, even though the LED display on this is much brighter. If I do want that resolution, I can always plug it into my wife’s 24″ Cinema display.

Hiding an email address from spam harvesters

2009-01-16T06:09:55Z

Using a little css trickery, you can completely hide your email address from spam harvesters. The drawback to this approach is that it will only work on sites that read left-to-right as it uses CSS to reverse the direction of text.

Add this class somewhere in your CSS file.

span.reverse {
  unicode-bidi: bidi-override;
  direction: rtl;
}

At the point that you are ready to present the email address, code it in your HTML, but just key it in backwards. For example:

<span class="reverse">moc.rehtrebttam@retsambew</span>

The CSS above will then override the reading direction and present the text to the user in the correct order.

Pretty clever technique.