What could be so stupendous as to merit sharing a title with The Best of Tesla?

The paperwork is finally done and everything is official, so I guess I can talk about it. I’ve got a new job with Collaborative Software Initiative. I start the first full week in July. I’m really excited. This is going to be a big change for me in a lot of ways.

First of all, since the company’s in Portland and I’m not, I’ll be working from home. People like to talk about the ups and downs of working from home: how you can never get away from work that way; how it’s hard to keep your personal life and your work separate; how you’re going to miss human contact. I think those people are jealous or nuts. When I’ve gotten to work from home in the past, it has ruled. I really think I’m going to eat it up.

The client is in Utah (well, the client is Utah), so I will be traveling a scosh, which I’ve never done. I’m looking forward to getting to see new places, but this is the aspect of the job that has me the most anxious. Since my daughter’s birth, I don’t think I’ve ever been away from her longer then twenty-four hours.

The product is a JRuby on Rails application, and it’s being developed in a lean/agile manner. I’ve been looking for a chance to work in an environment that was Ruby, or Smalltalk, and was agile. I’m not as fond of Java (the language) as I used to be, and my current company just doesn’t seem to be ready for agile development (if this post is any indicator).

The product is open source (or will be soon). This represents a huge change for me. A few months ago, I don’t think I appreciated how important this would be to me. Back then, I was trying to set up a talk about some work I had done in our software using JRuby for eRubyCon. I thought it would be a good talk and fit right into the eRubyCon concept. I was eventually shut down because there was concern amongst the powers-that-be that I would be exposing too much of our architecture and we’d be giving up a competitive advantage.  That was when I realized that I’m an open source guy, and I need to be making my living writing open source.

That is lot of change for one guy with a family to feed to make. I feel like I should be nervous. I’m not. I’m excited and I can’t wait to get started.

Friends! Let me free you from your complicated lives. From the complicated
part, not the lives part. -Bender

I managed to get SLIME and CLISP to play nice on Windows. As is often
the case when trying to get something interesting working on Windows,
I couldn’t find a single comprehensive source that explained
everything. I’ll document what I did here, and maybe that will save
someone else some time.

Oh yeah, and I did know about Lisp in a Box, but that felt like
cheating.

I already had cygwin installed. I did a full install (I had some
time on my hands). So I already had CLISP installed, too.

You’re going to need emacs to run SLIME. I use the Windows emacs
build, rather cygwin’s build. The cygwin build of emacs 22 is pretty
flaky on my machine.

When you go to download SLIME, make sure you grab the cvs tarball
and not the 2.0 tarball. The 2.0 release is not compatible with the
current CLISP release. The SLIME readme contains the magic incantation
to load SLIME into emacs. This goes in your .emacs file:

(add-to-list 'load-path "~/.site-lisp/slime/")  ; your SLIME directory
(setq inferior-lisp-program "/bin/clisp.exe -K full") ; your Lisp system
(require 'slime)
(slime-setup)

Change the paths so that they work for your system. Make sure that you
leave the “-K full” on the clisp executable.

There’s a path error that occurs if you run SLIME now. This is caused
by the difference between cygwin paths and windows paths. Note that I
don’t use any of that cygpath crap in my .emacs file. I also didn’t
want to write the elisp functions that would make Swank (it’s a SLIME
thing) work. I liked this suggestion from CLiki better:

mkdir /c
touch /c/NOT_MOUNTED
mount C:\\ /c

Start up emacs and run M-x SLIME. You should get the CL-USER> prompt
if everything worked.

I think that’s everything I did. If I missed anything, drop a note in
the comments.

There’s not a whole hell of a lot I can do about the platform I’m
stuck deploying on. Right now I wouldn’t recommend deploying the
jackrabbit.rar to a Glassfish Server running on Windows.

I’m using jackrabbit version 1.4. So far, I’ve gotten pas a few
pitfalls.

* Once the rar’s been downloaded, crack it open using 7z or WinRAR or
something. Then crack open the nekohtml.jar and rename the LICENSE
file to LICENSE.txt (or something).

* Download jcr-1.0.jar and copy it to the Glassfish lib directory.

* Then you should be able to follow this post from the jackrabbit
mailing list.

Everything seems great, but every time I grab this Jackrabbit instance
from my servlet using JNDI, I get an error. Jackrabbit won’t create the
session because it’s already locked by another process.

I’m not going to give up on this, but I’ve get to get something
running by the weekend. For now, I’m just going to embed the
jackrabbit stuff in my servlet. If anyone has any ideas, leave a
comment.

I’m using git on cygwin. For a while, gitk was not able to find any of
my git repos. Everything else was working, so it wasn’t a deal
breaker, but it was really annoying. I finally fixed it by removing
tty from the CYGWIN environment variable.

Rails 2.0 made writing your own ActiveRecord adapters easier. Combine
that with JDBC and you have some really nice tools for creating data
driven ruby applications working against any number of databases.

So, How Do I Write One?

Like a lot of things in the Ruby and Rails world, once you understand
the conventions, everything else is easy. So much so that, once you
know what you are looking for, writing an adapter is about copying the
patterns that have already been laid out in the other adapters.

The key steps for creating an adapter are:

- create a new lib/jdbc_adapter/jdbc_<adaptername>.rb

- update lib/active_record/connection_adapters/jdbc_adapter_spec.rb to
require ‘jdbc_adapter/jdbc_<adaptername>’

- create a new test/<adaptername>_simple_test.rb and an associated
test/db/<adaptername>.rb

- add test rake task to the Rakefile.

(these were basically stolen from an email on the JRuby Users mailing list).

What Goes Where?

For the most part, you can figure out everything else you need to know
by reading the code. If you aren’t sure how to do something, there’s
probably already an example of it in the code somewhere.
Here are some things I think I’ve figured out:

- Most of the magic happens in the
lib/jdbc_adapter/jdbc_<adaptername>.rb file. The rest of these
points describe points of interest in that file.

- ::JdbcSpec::ActiveRecordExtensions is where you put the connection
method, <adaptername>_connection. This is what Rails will call when
someone sets the adapter name to <adaptername>. You can use this to
turn Rails flavored config hashes into nasty JDBC URLs. Users will
thank you.

- Create a ::JdbcSpec::<AdapterName> module. Make sure you follow the
conventions for self.column_selector and
self.adapter_selector. There’s no reason not to.

- Lots of crazy stuff happens in the ::JdbcSpec::<AdapterName>
module. Write a custom create_table method. Rewrite “LIMIT 1″
queries for dialects that don’t support the LIMIT keyword. Support
migration behaviors that aren’t natively supported by the
database. Many more examples exist.

- Create a ::JdbcSpec::<AdapterName>::Column module. This is where
individual field customization happens. You can customize quoting
and unquoting of fields and column names. You can cast special types
(like bit to boolean). You can modify types on the fly.

Anything Else?

Eh, probably. I can’t think of anything else that you necessarily need
to know. I suppose you could do all of your modules in Java as part of
a Ruby Service. If your database driver has a friendly enough license,
you could distribute that as its own gem. This simplifies distribution
and installation for end users. I haven’t tried that yet, but it looks
simple enough. Leave a comment if can think of something I missed.

I hate to miss a good bandwagon. That’s why I have started using git as an interface to all the various subversion repos I have to deal with. So far I’m very happy with it. I’ve even started using it from my Windows machine. It works pretty well from cygwin. I did have to make this change to my pre-commit hooks.

I recently discovered org-mode on emacs. A very useful way to track todo lists and to manage projects. I’ve been using git to track the changes to my org files as well. A deadly combo.

It works well in simple cases. Running from Rake doesn’t work. Running rcov from rspec doesn’t work yet, either.

There are 13 unit tests that fail (12 failures and 1 error). The failures are mostly minor differences in output between MRI and JRuby. The big old up now is the one error. It appears to be a bug in the reset code. Once data collection starts, calling reset clears the callected data (desirable) and prevents new data from being collection (less desirable). I think that’s why running rcov from rspec fails.

The Smalltalk logos are mostly lame. Parrots and balloons don’t cut it compared to snakes, gemstones, and whatever the hell Duke is. Some may disagree, but the only reasonably good logo for Smalltalk is the block logo. It’s already been successful. Don’t believe me? See for yourself:

Smalltalk
Not Smalltalk

I can’t believe it myself.

It’s hard to believe that, for all of Smalltalk’s elegance, it isn’t more widely accepted. I just read the SUnit chapter in Squeak By Example. The SUnit TestCase class has a resumable assert method (TestCase#assert:description:resumable:). The use case for this is testing objects in a collection. Here’s a code example:

(1 to: 30) do: [ :each |
    self assert: each even description: each printString, ' is odd' resumable: true]

This code produces a test failure and outputs each object in the collection that fails the test (every odd number, in this example).

I decided that I wanted something like that in Ruby. Well, I want it in Java too, but coding in Java’s no fun

I was thinking of something like this:

1.upto 30 do | each |
       assert_and_resume each % 2 == 0, "#{each} is odd"
end

After poking through the TestCase source, I decided the easiest approach would be to write a custom assert, wrapping the assert_block method. I just needed to be able to catch the failed assertion and report the failure without stopping the test method.

So I wrangled a little code and came up with a solution that works like this:

1.upto 30 do | each |
       assert_and_resume( "#{ each } is odd" ) { each % 2 == 0 }
end

Pretty close to what I was thinking.

And here’s the implementation:

module Test
  module Unit

    # Resumable assertions are in a different module then the other
    # assertions because they have a dependency on
    # TestCase#add_failure.  The standard assertions can be included
    # anywhere, so including Resumable assertions in the Assertions
    # module might break existing code.
    module ResumableAssertions

      require 'test/unit/assertions'
      def assert_and_resume( description, &block )
        begin
          assert_block description, &block
        rescue AssertionFailedError => e
          add_failure e.message, e.backtrace
        end
      end

    end

    # Now we hook our assertion up to the test case. I could have just
    # re-opened TestCase, but I wanted to keep the Assertion logic
    # separate from the TestCase logic, as was the original author's
    # design.
    require 'test/unit/testcase'
    TestCase.send( :include, ResumableAssertions )

  end
end

Not much to it. The only other change that I might like to make is to modify the output so that it’s clear that one method failed many times. On a lark, I ran this through ci_reporter and then used Antwrap to generate a junit report. Here’s an snapshot of what that report looks like:

Sitting on my desk at work is a copy of trusty the old GoF book. Whenever a new programmer asked me about patterns, that was the book I would hand him. The next time, I think I’ll hand him Design Patterns in Ruby instead. One reason is because I take any chance I can to introduce developers to Ruby, but the main reason is that Russ Olsen does a great job of describing commonly used patterns.

Each pattern description is concise and easy to understand. The code samples lean towards simplistic, but are more then adequate for demonstrating the technique being described. Olsen starts with a code example that resembles how the implementation was describe in GoF. He then morphs the pattern into a more Ruby-ish implementation. Along the way he makes sure to describe the pros and cons of each implementation.

In addition to covering fourteen of the GoF patterns, the book also covers three additional patterns that are popular in the Ruby community. Those are Domain Specific Languages, Convention Over Configuration, and Creating Custom Objects with Meta-programming. Again, the pattern descriptions are clear and the code examples nicely demonstrate the concepts.

If you’re just getting started a developer, and you’re interested in seeing what patterns are all about, Design Patterns in Ruby is a good place to start. If you’re already familiar with patterns, but not so familiar with Ruby, this book gives some good examples of how using Ruby impacts the patterns you’re already familiar. Even if you’re an experienced Rubyist, you may want to pick it up anyway. It’s a quick read and a nice book to have in your lending library.