Jackrabbit.rar + Glassfish + Windows == Frustration

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.

gitk Not Finding Repos on Cygwin

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.

Writing an ActiveRecord-JDBC Adapter

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.

Subversion Through Git (on Cygwin)

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.

Rcov for JRuby Update

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.

Smalltalk Logos: [|] Advocacy

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.

Ruby TestCase: Resumable Assertions

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:

Book Avalanche: Design Patterns In Ruby

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.

Book Avalanche: Release It!

I’m nearly overwhelmed with books these days. I just finished reading Release It!, and I’ll share a few thoughts.

The author clearly has a great deal of Java experience, so his examples seem to come from that realm. And he focuses on web applications. But the advice is valid for anyone writing applications that support a ton of load (I think we all hope our applications see a ton of load, one day). And as HTTP based services become a staple of all enterprise-y development, I think the advice is still applicable. Circuit breakers, bulkheads and many of his other recommendations can be applied to any application space, whether you build you services in Rails, Java, Perl, whatever…

Since the book is web centric it assumes a server back end with a web browser UI. For those of us who build our own front ends (instead of relying on browsers) have more options for choosing how we handle HTTP protocols and handshaking; we can handle HTTP error codes correctly on both ends of the call (when we control both ends). Obviously, that doesn’t absolve us of the responsibility of securing and stabilizing our apps the same as any server based application. And we still have to deal integration points, so most of the book’s contents are valid for our particular situation.

Much of what the book talks about is preparing for the inevitable failure so that you can get your systems running again and prevent another occurrence of that particular failure. In fact, the anti-pattern chapters are longer then pattern chapters. Some of his patterns I’ve learned through experience. That’s definitely the hard way. I’m hoping that I can apply some of what I’ve learned here before the next disaster ensues.

I recommend the book for any software shop that builds web application software or has to integrate with third party services over a network. In fact, buy two copies and sharing with your engineering services team.

JRuby ETL Performance Boost

I spent today looking for ways to get our JRuby ETL to handle more data. Today’s work was mostly centered around cutting back on reads from the database. I had a lot of luck taking advantage of data already available in the JMS message we receive. The numbers aren’t in, but I think this should make it fast enough. It also looks like upgrading to a newer JRuby release will be fairly painless. That should get us some JIT, too. Sweet.

While I was poking through the code, I realized that it could use some work. It’s not thread safe, for one thing. That’s not a problem in production now, but I’d like to be able to run multiple processes one day and process more messages.

So I had the idea. The current tool uses TestCase, but I thought that I might start writing rspecs based on a) what the ETL does now, and b) what I’d like it to do in version 2.0. Once the specs are solid, I’ll start a rewrite. It’ll be interesting to see what comes of it.

As an aside, I popped into the local RUG. Coincidently, they were talking about rspec. Nothing earth shattering, but it seemed like a good group (if a little heavy with M$ Mono users).