Veezus Kreist

At Hashrocket, we use RVM to manage our rubies and gemsets on client projects. We typically specify the version of ruby that’s in production in our .rvmrc, like so:

rvm_gemset_create_on_use_flag=1
rvm 1.8.7-p249@vurl

However, sometimes a machine will have a problem with an installation of ruby, and so we’ll use a different version on that machine. Yeah, the correct solution is to fix the damn ruby, but we solved the problem today by flexing some little-used git fu… updating the index to ignore local changes to a file.

So, our `git status` shows us:

# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   .rvmrc
#
no changes added to commit (use "git add" and/or "git commit -a")

Now let’s instruct git to assume our .rvmrc is unchanged:

git update-index --assume-unchanged .rvmrc

And now our `git status` looks much better:

# On branch master
nothing to commit (working directory clean)

As a developer, I’m always looking for ways to keep my hands on the home row when typing. One of the few times I still use the arrow keys on my keyboard is when I want to repeat the previous command in bash. The solution? Use ctrl+p to cycle through previous commands, and ctrl+n to move forward through them.

Thanks, Bernerd!

It was a Wednesday a couple weeks ago. We were a group of Rocketeers on a wind- and rainswept balcony overlooking the river in downtown Chicago. All of the business types had fled after a table overturned in the maelstrom, but we were Hashrocket, and this was our happy hour. The waitress was thrilled that we continued to order drinks.

And then something strange happened… a siren started to sound. I had never heard anything like it, and my initial impression was that there was a normal police siren sounding that was being distorted by the buildings and rain.

Turns out, it was a tornado siren. But hey, it’s going to take more than a little tornado to keep us from our happy hour. Here’s the audio of the event:

We’re hosting a project on EngineYard and, unfortunately, they currently only support ruby 1.8.6 patchlevel 287. When trying to install ruby-1.8.6-p287 with rvm, however, make generates the following error:

In file included from openssl_missing.c:22:
openssl_missing.h:123: error: conflicting types for ‘BN_rand_range’
/usr/include/openssl/bn.h:411: error: previous declaration of ‘BN_rand_range’ was here
openssl_missing.h:124: error: conflicting types for ‘BN_pseudo_rand_range’
/usr/include/openssl/bn.h:412: error: previous declaration of ‘BN_pseudo_rand_range’ was here
make[1]: *** [openssl_missing.o] Error 1
make: *** [all] Error 1

The solution involves installing a custom OpenSSL package with rvm. You can get details directions directly from the source: http://rvm.beginrescueend.com/packages/openssl/

We’re developing an API of sorts for one of our clients. We’ve got an API that expects some form data for an Item and an optional file sent along. We ran into a little bit of trouble sending this file along with the request. We took a cue from the way webrat submits its forms for our solution:

file = File.open("path/to/fixtured/file")

params = { :item => {:new_file => ActionController::TestUploadedFile.new(file.path)} }

visit api_item_path(item), :put, params

We ran into some trouble today with finder_sql. Our object graph is fairly complicated, and can be summed up like this:

Job has many
Items, which have many
Processes, which have many
Cycles, which are iterations of many
Tasks.

This leads to us doing some pretty crazy SQL to compress the graph and save on database hits, and led today to an interesting discovery. We had done a has_many on User to return a list of tasks the user was able to perform. The finder_sql we generated looked like this:

SELECT *
FROM tasks t
INNER JOIN cycles c on t.cycle_id == c.id
...
INNER JOIN jobs j ON i.job_id = j.id

Unfortunately, the fist ID returned belonged to Job, so while the attributes for each Task was correct, the ID was actually the Job’s ID.

The fix was to select only the attributes of tasks:

SELECT t.*
FROM tasks t
INNER JOIN cycles c on t.cycle_id == c.id
...
INNER JOIN jobs j ON i.job_id = j.id

Matt Yoho and I have been working on interfacing with a SOAP-based external service with no documentation and hosted on Windows. During the course of feeding this service XML to try to get it to react as we’d like, we realized we didn’t know how to write out a Builder::XmlMarkup object to file without adding a new to_s element.

The solution? Calling target! on your object will return the string that Builder is building.

tempfile.write xml.target!

Updated with user-based configuration – thanks, Wayne

I’ve recently been in the uncomfortable position of trying to work on rspec-rails (which requires rubygems 1.3.6) and a legacy app that Hashrocket has been maintaining (which works with 1.3.5 or earlier). I’d been hearing about RVM and decided to give that a whirl.

However, by default, RVM was installing rubygems 1.3.6. After a little bit of struggling, I found the place to change the default rubygems version to install. In ~/.rvm/config/user, add the following line:

rubygems_version=1.3.5

This will override the default setting in ~/.rvm/config/db. Install a new ruby and check your gem version:

rvm install 1.8.7-p174

rvm gem -v

Lark and I were working on a project the other day and were nowhere near a commit at the end of the day. So we created a feature branch and pushed a WIP commit:

1
2
3
4
5
6

veez ~/code/some_app (master)$ git co -b client_edits_business
M        app/models/user.rb
M        spec/models/user_spec.rb
...
Switched to a new branch 'client_edits_business'
veez ~/code/some_app (client_edits_business)$ 

We finished up the feature the next day, and a week or so later Lark IMed me asking if there was anything on the branch that needed saving. I knew there wasn’t, so I deleted the remote branch:

1
2
3
4
5
6
7
8
9
10
11

veez ~/code/some_app (master)$ git branch -a
  client_edits_business
* master
  remotes/origin/client_edits_business
  remotes/origin/master
veez ~/code/some_app (master)$ git branch -d client_edits_business
Deleted branch client_edits_business (was 1fc95e5).
veez ~/code/some_app (master)$ git push origin :client_edits_business
To git@github.com:hashrocket/some_app.git
 - [deleted]         client_edits_business
veez ~/code/some_app (master)$ 

The next morning Lark asked me about the branch again, as it was still showing up in his tracked branches:

1
2
3
4

jon@mbp2:~/git_hashrocket/some_app$ git branch -a
* master
  remotes/origin/client_edits_business
  remotes/origin/master

The solution? Prune your remote:

1
2
3
4

jon@mbp2:~/git_hashrocket/some_app$ git remote prune origin
Pruning origin
URL: git@github.com:hashrocket/some_app.git
* [pruned] origin/client_edits_business

There are three main testing cliques at Hashrocket: the Fakirs, the Derivatives, and Team Zombie. Fakirs are so named because they stub and mock everything – making it all fake. Derivatives are the exact opposite, preferring to forego unit testing in most cases and just write integration tests that interact with the code through a browser. Team Zombie (the “decomposers”) had just the right mix for me: integration testing for core business value, unit testing individual methods, and stubbing them elsewhere. Personally, such a technique helped me with my data models: too many stubs means too complex a model.

Additionally, I’ve never been in love with cucumber; the regexes drive me crazy, and I’ve never had a client who wants the (admittedly very nice) story formatting that it gives. I’ve been working on a green-field app this week at Hashrocket for the first time in months and it’s given me an opportunity to try out a new integration testing methodology and has called into serious question my membership in Team Zombie. Tip of the hat to Sandro for turning me and Voxdolo on to this technique.

Here’s a quick and dirty implementation of integration testing with rspec and webrat on Vurl (source), using the techniques I picked up this week.

Configure your application

In config/environment.rb:

1
2

config.gem 'rspec-rails', :lib => false, :version => '1.2.7.1'
config.gem "webrat", :version => "0.5.3", :lib => false

In spec/spec_helper.rb:

1
2
3
4
5
6
7
8
9
10
11

require 'webrat'

Webrat.configure do |config|
    config.mode = :rails
end

Spec::Runner.configure do |config|
  ...
  config.include(Webrat::Matchers, :type => [:integration])
  ...
end

Create your spec

1

mkdir spec/integration

Here’s my spec/integration/create_vurl_spec.rb file:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

require File.expand_path(File.join(File.dirname(__FILE__), '..', 'spec_helper'))

describe "Create Vurls" do
  it "redirects to the vurl show page" do
    submit_vurl 'http://google.com'
    current_url.should == vurl_url(Vurl.last)
  end 
  it "shows a success message" do
    submit_vurl 'http://google.com'
    response.body.should include('Vurl was successfully created')
  end 
  it "creates a vurl" do
    submit_vurl 'http://veez.us'
    Vurl.last.url.should == 'http://veez.us'
  end 
end

def submit_vurl url 
  visit root_path
  fill_in "vurl_url", :with => url 
  click_button 'Vurlify!'
end

Run your spec

Since your spec file ends in _spec.rb, it will run with the rest of your spec files. Just give your app a

1

rake spec

A note about rspec matchers

When running these rspec tests, we don’t have access to the rspec matchers. So things like

1

flash[:error].should_not be_nil

won’t work because the be_nil matcher isn’t loaded. You can always fall back to Test::Unit:

1

assert_not_nil flash[:error]

Or, better yet, test that your content is within the body:

1

response.body.should include('There was a problem creating your vurl')

This method of integration testing feels much lighter to me; the tests take less time than cucumber equivalents and we’re not writing and maintaining a separate set of regexes to go with the app.

I’ve been going through a rebranding effort lately, moving away from Matt Remsik or Veez to Veezus Kreist. I believe Veezus will be a stronger brand that will result in less name collisions with other folks on the internet.

Part of this effort was moving my blog from Blogspot to something I’ll host myself at blog.veez.us. I considered many solutions: Mephisto, Simplelog, and Enki

Mephisto was active but seemed large and bloated with features I wouldn’t use (and the Documentation tab kept throwing 404s). Simplelog was no longer being maintained. Enki was just right, providing a simple blog application with everything I needed.

I was able to get my enki blog up and running, with all posts and comments copied over, in about two hours. I’d recommend it for a personal blog that doesn’t need features like multiple authors and that you want to easily modify.