Baroquebobcat

Update: this is no longer valid as of the release of 1.6.0.

I was debugging this Dubious problem where a class I was sure was on the class path couldn’t be found(link). First, I tried compiling on my local checkout, and it worked oddly. Then I realized I was dumb, because the class was being picked up from the finished jar. So, I clobbered my build artifacts and then my local copy didn’t compile either.

I did some digging and found out why.

In the end it was because of how JRuby implements $CLASSPATH–the way you can modify the classpath from within JRuby. JRuby uses a subclass of URLClassLoader to implement it which gives it some possibly unexpected behavior. In particular, URLClassLoader treats anything that does not end in a slash as a jar. That’s why the class files in my build directory were not being picked up properly.

Lessons Learned:

Combat “It Works on My Machine™”. Clobber local generated files every now and again, and checkout a fresh tree from time to time to reduce the chance something local is weird.

Look for and ask for help when you don’t know something. First time I tried to figure out the problem, I just tinkered and compiled and tinkered and compiled. A little research would have saved some time.

TL;DR

If JRuby can’t find your classes and you think they should have been added to $CLASSPATH, make sure you have trailing slashes on your directory names.

Update:

This has actually been fixed, but not released yet: https://github.com/jruby/jruby/commit/8740a6b3ea946a1442dd7fa833aed3c30d82e23f

So you got some awesome scraper script and you want to deploy it to your server but you don’t want to have to install firewatir. Or, you don’t want to pull in the firewatir gem because you are not planning on using it. Whatever.

Problem: scrubyt
requires the firewatir gem

Hacky Solution: comment out the require

But where you ask?

/lib/scrubyt/core/navigation/agents/firewatir.rb line 1

This works on the current rubyforge version(0.4.1).
Recommended: Or, you could just use the version on github that is fixed(see commit)

grab the files via git or archive from github.com/scrubber/scrubyt

then

cd scrubyt-somehash
rake gem
gem install pkg/scrubyt-0.4.26.gem

Not as nice as using jeweler where you can just `rake install` it, but pretty nifty none the less.

As part of a personal project, I have been working on an OpenID Provider written in Sinatra.

The idea is to make it ridiculously easy to set up an openid provider within a rack middleware stack.

It’s just a single sinatra app without any tests using code I cribbed from the example rails implementation in ruby-openid. But, I intend on rewriting it once I get a better feel for how it should go.

The problem I face is a matter of interface, specifically application programming interface. I want it to be simple to use. But that is alittle complicated underneath.

Today I read The Little Manual of API Design(pdf), which made me think about my approach to building things in, I think, a good way. It talks about the goals of building a good API and boils it down to five things.

• Easy to learn and memorize
• Leads to readable code
• Hard to misuse
• Easy to extend
• Complete

For my app, complete is pretty easy. I’ve boiled the interface down to two main things:

• OpenID Store
• User/Identity

First, for an openid app, you need an openid store to put all the associations, nonces etc.

Then, the meaty bit, the users and their identities. The stuff we are serving up. My current thought is to have one of the app’s parameters be a lambda or Proc that returns the current user, or nil when called with the request.env. So that using it would look somewhat like this.
It’s kind of ugly, but I like it better than some of my other options. One other way I could get the user to the app would be to use rack request hash. I could have users put the user object in the request env before the OpenID provider gets it and tell the provider where to look. But the problem with that is that I would need to add another middleware layer that added the user to the environment. That would look something like this:

Maybe that would be better.

Ultimately I just need to pick something and run with it.

The thing I wonder about though, is what is the most idomatic way of doing this. Using the most rubyish, most Rack like interface would make it easier to learn and memorize.