Rubymine has a feature called live templates that allows you to type a short command and have RubyMine extract it in to full blown code. Some built in shortcuts exist, such as def (creates a method), desc (create a RSpec test), it (RSpec test), etc.

To create your own, go to RubyMine -> Preferences -> Live Templates. Click one of the existing templates and hit Copy.

I named mine pl (Put Line Number) and put the following content in:

puts “#{__FILE__:#{__LINE__}”

Now when I’m typing code, I can hit the following:

pl<TAB>
p “Hello”

And it will print out the following:

/Users/jasonn/source/project/junk.rb:1
“Hello”

I’ve found this helpful for tracking down where a specific print statement is located.

This has gotten much easier with a change made by Jose Valim back in March.

The change allows you to create your own custom configuration variables like so:

# config/environments/development.rb
Demo::Application.configure do
  [...]
  config.json_url = "http://www.domain.com"
  [...]
end

# config/environments/test.rb
Demo::Application.configure do
  [...]
  config.json_url = "http://test.domain.com"
  [...]
end

This allows you to add any configuration variables you want to your Rails app. What if you have a bunch of configuration values? You don’t want to pollute your config.* namespace. Wouldn’t it be helpful to have config.my_app.json_url and config.my_app.other_url?

That’s easy enough:

# config/environments/application.rb
Demo::Application.configure do
  config.my_app = ActiveSupport::OrderedOptions.new
end

# config/environments/development.rb
Demo::Application.configure do
  [...]
  config.my_app.json_url = "http://www.domain.com"
  [...]
end

# config/environments/test.rb
Demo::Application.configure do
  [...]
  config.my_app.json_url = "http://test.domain.com"
  [...]
end

Now you can do the following in the Rails console:

$ rails console
>> Demo::Application.config.my_app.json_url
"http://www.domain.com"
>>

$ rails console test
>> Demo::Application.config.my_app.json_url
"http://test.domain.com"
>>

Now your Rails application will have access to all the configuration you need.

One of the cool/interesting features of the Pivotal office is that the company provides breakfast in the morning. I walked into the office to find two quiches, pears, strawberries, Orange Juice, Milk, Coffee and several choices of breakfast cereal.

The day started out with a standup. We then split off into pairs and worked on our respective projects. It was interesting to be thrown into the fire and within a half hour I was working on a large, well known website, implementing features that are now live on that site.

We split for lunch around 11:30. After lunch we switched pairs and I worked on a different portion of the code. Pivotal has a strong TDD/BDD approach to coding. We wrote tests that failed, then wrote the code to make them pass. After all the tests passed, we refactored. This is what Rails development is supposed to be.

The afternoon/evening was rounded out with a team retrospective meeting. After the meeting, the office all joined in for a game of StarCraft II.

I thought my interview/pairing day went really well, and I’m happy to say that I’m moving to Boulder to start working for Pivotal Labs March 14th.

Here’s some pics:

The Snow was falling as I arrived at Denver International Airport

The Pivotal office has a full size, full time ping-pong table

This is the view from the office.

The spotting scope is from a Russian Destroyer. One of the Pivots said during the summer you can see mountain climbers climbing the distant mountains. The large grill is for hosting summer parties.

This is from across the street. Pivotal Labs is on the second floor. Ted’s is an easy lunch.

It turns out it’s very easy to accomplish.

# config/initializers/configuration.rb
class Configuration
  class << self
    attr_accessor :json_url
  end
end

This gives you access to a Rails variable called Configuration.json_url. Now we just need to initialize this value in our environment files.

# config/environments/development.rb
#   Put this inside the ______::Application.configure block
config.after_initialize do
  Configuration.json_url = "http://test.domain.com"
end

# config/environments/test.rb
config.after_initialize do
  Configuration.json_url = "http://www.domain.com"
end

Now you can test it in the Rails console.

$ rails console
>> Configuration.json_url
"http://test.domain.com"
>>

$ RAILS_ENV=production rails console
>> Configuration.json_url
"http://www.domain.com"
>>

Now your Rails app has access to these variables, so you can use them in your Controllers, Models or Views as needed.

I just finished up with Chapter 6: Creating the Application. It’s working fine on my machine, but I wanted to push it to Heroku. Here’s how I did it:

echo "gem 'heroku'" >> Gemfile
bundle install
git init
git add .
git commit -m 'Initial commit'
heroku create
git push heroku master
heroku rake db:migrate
heroku rake db:seed
heroku open

I then added a /products on the Heroku URL that came up and my Depot application is now running on Heroku.

I’m using RVM with 1.9.2p0 and rails 3.0.1.

rails new conductor && cd conductor

I edited my Gemfile and added the following line:

gem 'conductor', :git => 'http://github.com/dhh/conductor.git', :require => 'conductor/engine'

I then ran “bundle install”.

I fire up rails server and hit http://localhost:3000/conductor (as suggested by the README) and I get an error:

Routing Error

No route matches "/conductor"

Am I missing something? I need to research Rails3 engines some more.

The site I came up with is quickly rising in the results for Montana land for sale.

Hopefully this page will help as well. </lame seo attempt>

I got Google Analytics setup and I think Google Adsense is next.

Here’s the steps I used to debug:

Login to your Cruise Control box and cd to $BUILD_DIR/projects/$PROJ_NAME/work

Run the following command. This is how CC.rb figures out if updates have been made.

git log --pretty=raw --stat HEAD..origin/master

When I ran this command, I was getting “warning: refname ‘origin/master’ is ambiguous.” returned. After some google searches, I landed upon some mailing list messages that pointed me towards the issue.

The reason git was complaining about origin/master being ambiguous was that someone created a tag named “origin/master” (the beating has been scheduled).

I had to delete this tag locally by running the following command.

git tag -d origin/master

Then I had to delete the remote branch by running the following.

git push origin :refs/tags/origin/master

Now the CC server is working properly.