README.md in contractinator-0.1.3 vs README.md in contractinator-0.1.4

@@ -16,11 +16,11 @@
 
     $ gem install contractinator
     
 Then inform RSpec that you'd like to use contractinator by adding something like the following to your spec_helper.rb
 
-```
+```ruby
 require 'contractinator'
 
 RSpec.configure do |config|
   config.include Contractinator::ContractHelpers
 
@@ -45,47 +45,47 @@
 ### Creating a Contract
 There are several ways to document a provider's behavior. The easiest is to use the `stipulate` and `agree` matchers.
 
 In the spec for a consumer, for example a rails controller, you might have
 
-```
+```ruby
 it 'assigns a new entry' do
   stipulate(Entry).must receive(:new).and_return(entry)
   get :new
   expect(response).to be_success
   expect(assigns[:entry]).to eq(entry)
 end
 ```
 
 This sets the expectation that Entry.new will be called, and stubs it out to return `entry`. Now you should get a warning in your rspec output that looks like this:
 
-```
+```ruby
 unfulfilled contract 'Entry.new -> entry'
    at spec/controllers/entries_controller_spec.rb:45:in `block (3 levels) in <top (required)>'
 ```
 
 The next step is to make sure that contract is fulfilled by something. So we'll switch over to the model spec
 
-```
+```ruby
 describe '.new' do
   it { agree(Entry, :new).will be_a(Entry) }
 end
 ```
 
 This calls new on Entry and asserts that it is_a Entry, and fulfills a contract of the form `Entry.new -> entry`. Since this matches the one from above, your spec output won't show the unmatched on anymore, but will increment the fulfilled contracts message.
 
 ### Less straight-forward contracts
 Not every contract in an application is so easy to specify. For example, a view spec which assigns a local variable has an agreement with a controller to assign that variable. Some other matchers available:
 
-```
+```ruby
 assign_contract('entries#new', :entry, entry)
 flash_contract('entries#create', :notice, 'Great Success!') if flash_enabled
 ```
 
 In these two cases, the method both does the side effect (assigning a variable for a view spec or setting a flash message), and also creates a matching contract. There isn't a corresponding fulfillment matcher for anything else yet, so you have to fulfill them manually. I do this like so, in my controller spec:
 
-```
+```ruby
 describe 'get :new' do
   it { fulfills 'entries#new assign @entry'   }
   it do 
   	# actual test which reflects this fulfillment
   end
@@ -93,19 +93,19 @@
 ```
 
 ### Free-form contracts
 Sometimes I think of things that need a contract that I have no matchers for, and all I really want is a smart comment. I'm using this for a routing contract relationship now. In that case, you can do this:
 
-```
+```ruby
  # this is a contract that might be created
  # by a link in a view spec for example
- Contractinator::Contract.require("get / routes")
+ contract("get / routes")
 
 ```
 
 And fulfill it with
 
-```
+```ruby
 it { fulfills('get / routes') }
 ```
 
 All that matters for the contract to be fulfilled is that the string matches, so in this case contractinator is almost acting as merely a smart comment.