I want to be able to specify an arbitrary time, in english, relative to the current time, in my Cucumber steps. For example,

Scenario: Only posts from the last two months are shown
  Given the following posts:
    | title           | posted_at           |
    | recent post     | 2 days ago          |
    | recent post 2   | yesterday           |
    | older post      | 2 months ago        |
    | really old post | 2 months, 1 day ago |
    | tomorrow's post | 1 day from now      |
  When I go to the posts page
  Then I should see 3 posts

The desire, there, is to be able to specify a date relative to the current time, in plain english. The tricky bit is being able to chain them together, as in 1 year, 3 months, 2 days ago

I got this worked out by stringing a few regular expressions together in my step definition helper. It depends on the 2.days.ago type dsl in ActiveSupport.

Given /^the following posts?:?/ do |table|
  table.map_column!('posted_at'){|date| interpret_time(date) }
  table.hashes.each{|hash| Factory :post, hash}
end

def interpret_time(time)
  return nil if time.blank?
  return time if time.kind_of?(Time) or time.kind_of?(Date)
  named_time(time) || time_by_regex(time) || Time.parse(time)
end
 
def named_time(time)
  case time.downcase
  when "today" : Date.today
  when "now" : Time.now
  # etc ...
  else nil
  end
end
 
def time_by_regex(time)
  directional_regex = /(ago|from now)/i
  time_regex = /(\d+) (minute|hour|day|week|month|year)s?/i
 
  direction = time.scan(directional_regex).flatten
  shifts = time.scan(time_regex)
 
  return nil if direction.empty? or shifts.empty?
  forward = direction.first == "from now"
 
  result = Time.now
  shifts.each do |count, unit|
    #depends on the 1.week type DSL for time measurements
    adjust = count.to_i.send(unit)
    # move time in correct direction
    result = forward ? (result + adjust) : (result - adjust)
  end
 
  result
end

It arrived at the start of the weekend, and I took a bit of time to install it in my laptop, a Thinkpad T61p, about a year old. The installation was pretty easy — one screw to get at the laptop’s main drive, and pull the sled out. I had a little bit of difficulty getting the sled screws out of the old HD, as they were in pretty tight. Other than that, it was a smooth swapout.

I installed the most recent Ubuntu beta, which went swimmingly. Better than any Windows install I’ve ever done. The bottleneck there, unsurprisingly, was the CD drive.

It’s impressive how much quieter the laptop has become, without the spinning drive. plus … it’s fast. I’m not going to compare boot numbers, because I’m not booting the exact same OS after install … but, the boot time is impressive. Under 30 seconds from powered off to login prompt, by my stopwatch. Of that, 7 is spent on the bios screen, and another 5 at the grub menu. All told, it takes about 15 seconds to boot, once the linux kernel starts loading. No reason to worry about turning this thing off anymore… Just need to teach gnome to save my entire session on shutdown, and I’m good. (I have never had any luck with hibernating a laptop, so I’m considering that a non-option)

So, install is done, and I’m pondering how aggressive I want/need to be about limiting writes to the drive. I have no particular worry that I’m going to burn the drive out anytime soon, and my track record with hard drives has always been a little bumpy, so I’m not terribly worried about it. By the time I do burn through all the writes on this drive, I’m sure that I won’t be using this laptop anymore. It’ll probably last longer than a normal drive would.

I’m still getting set up and running it through it’s paces, and I still have to see what kind of an impact it has on my battery life through normal use (when I’m not draining the battery with tons of install related network traffic and CD spinning). Overall, however, I’m really impressed with the difference this makes.

I saw a question on the rspec list recently asking about how you test an SSL required page within cucumber, and I realized that I’ve had that, and even more cert-related chaos, figured out at $WORK, and that I should probably talk a little bit about it.

Simple scenario is that you’ve got some controller on your site that is supposed to only be accessible via https, and you want to make sure it behaves correctly in cucumber. In your standard deployment scenario, mongrel never really sees anything about SSL; that’s all handled by Apache. Apache will set some headers for you, which rails can check to determine if you’re using SSL. Since you’re not testing with Apache at this testing level, you just need to set the relevant HTTP headers.

Given I am using HTTPS
When I visit /payments
Then I should see the payments page

Given I am not using HTTPS
When I visit /payments
Then I should see an SSL error page

If I’m using webrat (which is highly recommended here) this becomes as simple as setting a header value. In recent versions of webrat, that boils down to:

Given /I am using HTTPS/ do
  header("HTTPS", "on")
end
Given /I am not using HTTPS/ do
  # this space left intentionally blank
end

If you’re NOT using webrat, but still at the rails integration test level, the call is a bit uglier

  get :show, { :id => 1234 }, { :https => 'on' }

The get method at the integration test level actually takes a third argument, which is the HTTP headers set on that request. At the functional / controller example level, the same method might work — I don’t know, I havn’t actually tested this at that level, instead I’ve just stubbed the https? method as needed.

Now, for bonus points. At $WORK, I exist in one of those ideal closed environments where x509 authentication actually stands a chance of working. That is, everyone gets a client certificate, which they send to us with the HTTPS request. We check against an external service, see that the cert is good, and viola, we can pre-populate with all sorts of juicy user information. Pipe dream on the internet, but it works well on an intranet. (having worked with this stuff, it’s no surprise to me at all that x509 client certs havn’t even managed to catch on with banks much less the general public …)

Apache takes care of checking the certificate, making sure it’s valid and well formed, and that it’s not in any CRL, and that it’s trusted. Makes my life easier, at the Rails level, we just have to check against the external service and we’re off to the races. And, happily, apache will pass things on in the headers.

Given I use the client certificate for “Joe”
Then when I visit /administration
I should be let in

Given /I use the client certificate for "(.*)"/ do |cert_user|
  #lookup or generate stub certificate information
  header("X_CLIENT_CERT", certificate.certificate)
  header("X_CLIENT_DN", certificate.dn)
  header("HTTPS", "on")
 
  DirectoryService.instance.stub!(:lookup).with(certificate.dn).and_return certificate.remote_xml
end

I’m hand-waving around some of the stubbing that would have to go on here, as far as generating dummy information goes, but the basic idea should be sound. In this case, I’m stubbing the entire DiectoryService.lookup method for a particular DN, which I set in the headers, and returning “remote_xml” which is a stand in for the XML document that the remote system returns. This lets me cut out the remote system, which wouldn’t appreciate being hit for all sorts of trash data every time the tests run, while still exercising most of the relevant internal code.

The general idea of an integration test is to see all of the pieces of the system working together. At this point, Cucumber is exercising everything in the stack below Apache. Since certificates and x509 client certificates are largely dealt with by apache, we have to stub those ins and outs to work through the rest of the system. The system is otherwise left unstubbed, and we check those integration points during manual testing.

This is a form builder we use in a couple of heavily used forms on the site, so we “know” this works, aside from the new code I want to add. But in moving in to backfill some specs, I discovered that, like many things relating to form builders in rails, it’s not the easiest thing to do, nor is it exactly well documented …

After a bit of digging, I finally managed to work out the right setup to get this going. Documented below for posterity

# spec/helper/random_form_builder_spec.rb
  describe RandomFormBuilder do
    attr_reader :builder, :helper
    before do
      @helper = Object.extend(ActionView::Helpers::FormHelper)
      @object = stub_model(Random)
      @builder = RandomFormBuilder.new(:random, @object, @helper, {}, nil)
    end
  end

You can then spec as normal, calling methods on builder and verifying the result.

The tricky part is the constructor.

:random

This is the name of the object, by analog, the first argument of a #form_for

@object

The object you run with; where the form pulls field values from

@helper

this is the tricky one. A form builder is really just a pass-through, decorating calls down to methods that live in FormHelper. If you don’t have a template that defines the FormHelper methods, failures abound.

{}

Options for the FormBuilder. Here, unused

nil

A proc

When I got there, they asked if I wanted a paper ballot. Yes, yes and yes! For those who don’t know, those touch screen, paperless voting machines scare the hell out of us programmers, for a variety of reasons that have been well covered elsewhere.

Fill in a couple of bubbles with the provided pen (just a cheap bic) and run it through the scanning machine, and you’re done. No muss, no fuss. And it works if you lose power.

Now, off to spend the rest of the day pretending to work, instead of watching poll results like one of pavlov’s dogs …

I’ve been working on a Rails based re-write on-and-off for the last few months, and we’ve been using the new site internally, as I work through various different approaches to the project.

By far, one of the trickiest things was figuring out how to deal with file distribution and versioning. Shipping out files, PDFs primarily, is the entire reason for the site[0]. We tend to do multiple releases of the same product — beta/playtesting releases, followed by revisions, followed eventually by a “final” release. (I put final in quotes, because we can always go back and revisit a product) …

I wrestled for a long time with how to manage this versioning issue; I’m still not necessarily satisified with the current solution. Which is: A product (which contains multiple files) is what holds the current status — Internal, Beta, Final, Under Review. Files are associated with the product, but aren’t really tracked themselves. They’re either public or private (for purely internal development files) and can be archived. Basically, the product is a big bucket for all of the associated files, but the file records themselves are “dumb”.

It seems to work out well enough. Time, I suppose, will tell.

[0] For the moment; I do plan on making a much more web-based interface for distributing 4e material in development.

We’ll see if I actually blog anything, since I didn’t write a damned thing about Railsconf.

Bug report gets filed about the application at work. It seems that there’s an error that crops up when you print from IE. The error, of course, being the characteristically unhelpful dialog of garbage that IE likes to throw at you. After a bit of digging, it got even better. I was hoping I’d be able to respond with something technically snotty, like “Do you have your printer installed?”

But, I managed to reproduce the bug. Even better, I managed to narrow down it’s occurance. It turned out that when you were logged in, the error would occur, but only if you were logged in. Now that’s strange, since we’re using application level (cookie based) authentication — IE wouldn’t know anything about your logged in state. Everything works fine in Firefox (of course, the browser with good diagnostic tools doesn’t show the problem …)

So, in stumbling around trying to find some clue as to what the problem is, I came across this … It seems that id="tags" ends up conflicting with some builtin function in IE that’s used in printing. Sure enough, we had a field with <input name="tags" id="tags" type="text"> that was wrapped inside an if logged_in? check. Renamed the field, and printing now works like it’s supposed to.

So, what could have been really long and painful was short circuited by a lucky find in my net searches. No thanks to IE, it’s non-reserved reserved fields and opaque error messages. Have I mentioned lately how much I hate IE?

So, I’m gonna jump into the migrations and patch the existing add_index calls to specify a :name => value for all of the existing indexes, so that migrations will actually work and leave me with a database that matches the one in production ….

Figuring out why I suddenly couldn’t build my test database was not exactly the way I meant to spend the last hour ….

Update

Changeset 4768 is responsible for all this. Apparently, to allow reverse parsing of the indexes from the index name. Not alltogether a bad goal, but it still breaks down migrations … (thanks to Devin for find this one)

And, I discovered another problem last night. Seems that all of my text fields have a default value of “empy_clob()” … not the function, but that actual string. Sort of trashes one’s assumptions about unset fields. Apparently (thanks Roy) this has been worked out in ticket 7344 and already applied to Edge. Some sort of thing that only applies to Oracle, because, of course, nobody tests Rails on Oracle, it’s all MySQL. And I can’t really look into the patch attached to the ticket, because I keep getting Trac errors. Shaping up to have been a lovely adventure …

update
Finally got through to the site, and worked out a monkey patch to fix this. For those of you who might be running with oracle, and can’t upgrade to Edge (gee, wonder why not) the patch is below. This is a temporary thing, given that the ticket is closed, and will hopefully be fixed in 1.2.2 …
[ruby]
class ActiveRecord::ConnectionAdapters::OracleColumn
attr_writer :default
end if defined? ActiveRecord::ConnectionAdapters::OracleColumn

class ActiveRecord::ConnectionAdapters::OracleAdapter
def quote(value, column = nil) #:nodoc:
if value && column && [:text, :binary].include?(column.type)
%Q{empty_#{ column.sql_type.downcase rescue ‘blob’ }()}
else
super
end
end

alias columns_orig columns
def columns(*a)
columns_orig(*a).each do |col|
col.default = nil if col.default =~ /^(null|empty_[bc]lob())$/i
end
end
end if defined? ActiveRecord::ConnectionAdapters::OracleAdapter
[/ruby]

This appears to do the trick … a dump of the test schema no longer defaults all of our text columns to “empty_clob()” and tests are again passing …