specifying a couple of versions
started spec-ing the resource builder
tweaked requires a bit
right way to do it.
refactor step 1: move code
refactor step 1.1: cut down on code
refactor step 1.2: tweak code
refactor step 2: remove code
I'm using scm for a reason. off with its head.
no idea why Halibut::Adapter was a class instead of a module…

Also added the JSON adapter to the autoload scheme.
updated README — Builder still has no embedded resources, nor relation DSL
require/autoload extravaganza. moved integration specs to json_spec, since that's what they were
added relation context to Builder. (see extended description)

So, I did this in a couple of steps originally. I kept chewing on the
best
way to do it in my head, and first I started with

    def relation(rel, &blk)
        @rel = rel
        def link(href, opts={})
            @resource.add_link @rel, href, opts={}
        end

        instance_eval(&blk) if block_given?
    end

As you can imagine this allows for this syntax:

    Halibut::Builder.new do
        relation 'games' do
            link '/games/1'
            link '/games/2'
        end
    end

or

    Halibut::Builder.new do
        link 'games', '/games/1'
        link 'games', '/games/2'
        link 'games', '/games/3'
    end

but not both. This was not optimal, since I want to provide flexibility
to the
users of the library, thus came about this ugly hack of a code:

    # note: I was listening to Ruby Rogues and they mentioned
define_method creates
    #       a closure, so I wouldn't need the ugly `@rel = rel` bit of
code
    def relation(rel, &blk)
      @rel = rel
      def link(href, opts={})
          @resource.add_link @rel, href, opts={}
      end

      instance_eval(&blk) if block_given?
      self.class.class_eval { def_delegator :@resource, :add_link,
:link }
    end

At this point I thought, hang on, why don't I just simply use OOP?
Thus, I
extracted all this nonsense to the — to my eyes — clean code you can
see now.
this is quite ugly, but it passes the test. refactoring time?
I'm going bblliinnndd.

So, all this refactoring is basically because I want to use the
`resource`
inside the DSL, but it also returns the built resource of the
Halibut::Builder.

I went all Context mad which, coupled with my recent obsession with
minimal APIs,
results in this piece of lovely code. Shut up, it _is_ lovely.
tidying up the specs.

I'm a lazy bum, so I "namespaced" the specs so I can fold
them and have a higher view of the structure.

I'm pondering as the next step to implement
method_missing so I can define properties willy-nilly,
making the DSL remarkably close to the XML format.
Yes, it's a good thing, you silly bunny.
tried to simplify the code a nudge.

Continuing with my minimalistic streak, I tried to reduce the
exposed interface to the bare minimum.

There was also some differences in the way that
RootContext and RelationContext worked that were kinda
grating me, so I tried to refactor accordingly.

I can say that so far I'm pretty happy with how the Builder turned out.
added differ to tell differences more easily
added pry-doc to support native methods
"minimalism" strikes again!

# Halibut::Adapter::JSON

## class to module
`Halibut::Adapter::JSON` didn't really make sense as a class,
since I only ever wanted to call #dump and #load, so I
converted it into a module and extracted all the "parsing"
logic into a `ResourceExtractor`.

## #to_json
I also added `InstanceMethods` to aid in the `extended` hook.
This allows me to extend an instance of
`Halibut::HAL::Resource` so it has a proper #to_json method,
for the people that don't want use the adapter directly.

This:

    resource = Halibut::HAL::Resource.new 'http://example.com'
    resource.extend(Halibut::Adapter::JSON)
    resource.to_json
    # => "{\"_links\":{\"self\":{\"href\":\"http://example.com\"}}}"

Is functionally equivalent to this:

    resource = Halibut::HAL::Resource.new 'http://example.com'
    Halibut::Adapter::JSON.dump resource
    # => "{\"_links\":{\"self\":{\"href\":\"http://example.com\"}}}"

## extract_resources
The #extract_resources method also suffered a small tweak.
I kinda want to get rid of the `([] << values).flatten`
bit, but the logic is eluding me at the moment.

Some may argue that using several iterations (map, map,
each) like that is not optimal, but honestly, micro
optimizing much? When it becomes a bottleneck I'll deal
with it.
Besides, the interpreter should deal with it.

Long live Cthulu.