Thus Spake the Demigod

TL;DR: My time at Hashrocket is coming to an end. It's a very bittersweet experience, leaving this company that has come to define me over the last several years, but it is become the season for change and I'm ready for my next challenge. Ping me if you're looking for a consultant experienced in ruby and rails.

I have a tattoo of Hashrocket's logo on my right calf. It's an odd thing, people say, to have a corporate logo on one's body. But for me, it's completely natural. When I'm in the presence of conversations regarding ruby 1.9's new hash syntax or my upcoming departure from Hashrocket, I inevitably get asked: "What about that tattoo on your leg?"

At first I was confused by the question. It took me a while to get to the source of the confusion: folks seem to have a base assumption that regret follows when the meaning of a life-altering body modification changes. I have only this one tattoo on my body, and it comemmorates what is thus far the single most awesome experience I've had. Regardless of what happens from here on out, I will treasure and honor the myriad experiences I've had as part of Hashrocket. I've earned the right to wear that tattoo, and I'm honored to give those square inches of skin on my leg to help keep those experiences alive in my memory.

In my time at Hashrocket, I've had the great fortune to work alongside some of the best developers in our field - in a company whose original members included the likes of Obie Fernandez, Desi McAdam, Jon Larkowski and my brother Jim Remsik. I've learned more about consulting and client relations than I ever dreamed I would. And I've learned a ton about what Agile means, and how to stay flexible among changing team and client dynamics. A friend pointed out recently that I've been at Hashrocket almost as long as one attends university; this observation feels especially apt given the amount that I've learned and grown.

The memories of my time at Hashrocket will last a lifetime: a year in Hashrocket time feels like 5 anywhere else. I'll remember our "garage", where we first came together as a company. I'll remember the RV trip to the Ruby Hoedown, getting our new digs in the tallest building in Jacksonville Beach, the Hashrocket Hot Hackers Hump-day Happy Hours, the pool parties, the 3-2-1 launches, the rescue missions seemingly uncountable, the Halloween parties and that birthday where Mark sat in his cake, and of course the video that tpope gifted us commemorating three years of Hashrocket.

There's been almost as many downs as there have been ups: I know I'd certainly like to forget 2010 and all of it's troubles. We had multiple robberies (which were solved, thanks to anti-theft tech on our machines), we had some management shakeups, and even several situations that could have meant the end of the rocket. But we celebrated New Years 2011 as a company: we made it through the crucible as a whole, finding ourselves in an an awesome position throughout 2011.

I was given an opportunity a little over a year ago to come work at the Chicago office, shortly after it opened, and I jumped on it. It took some time, but it's blossomed into an exceptional office. I'll remember fondly, too, memories from up here: post-6H karaoke, the Josh, Yoho, and Bernerd eras, the ever-present and always-welcome Corey Haines, the grand opening party for which we "needed" that 55" plasma TV, the company game of Whirlyball featuring David Chelimsky and Neal Sales-Griffin, the apartment debachles, being the lonely sole rocketeer in the city, and two Tuesdays ago when we were a party of nine at Six Flags Great America.

It's a bittersweet time for me, these last two weeks of my employment with Hashrocket. There's a pride in knowing that I helped make our office what it is, and a sadness knowing that it will go on just fine without me. But you can bet I'll be back in the office visiting whenever the chance arises!

So, what's next? I'm not yet sure. I'd like to work on a product for a while, or at least cool my heels from the continual churn of consulting. I'd like to work with a group of awesome everyone-together developers that value continual learning and the occasional code-based flame war. And I'd like to use the knowledge I've gained during my time at Hashrocket to help another team achieve success. Know a place like that? Email me at almighty@veez.us.

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.

I had been working for the last few weeks on a tricky issue. Given the following code:

class Vendor < ActiveRecord::Base@
  has_many :vlogs, :conditions => ["vlogs.published_at < '#{Time.now.to_s(:db)}'", ]
end

The items listed for each vendor would cache an arbitrary amount of time after the server was started. Restarting mongrel would resolve the issue – until Time was cached again. I spent more hours than I care to think about trying to resolve this issue with various Hashrocket and EngineYard staff. The only solution presented was:

class Vendor < ActiveRecord::Base
  has_many :vlogs, :conditions => ["vlogs.published_at < ?", Time.now.to_s(:db)]
end

Which didn’t work, anyhow. I finally spent some time with Tim Pope this evening, and he provided the following, correct solution:

class Vendor < ActiveRecord::Base
  has_many :vlogs, :conditions => ["vlogs.published_at < '\#{Time.now.to_s(:db)}'", ]
end

The trick here is that Ruby is interpolating the date string; ActiveRecord never even sees the reference to Time.now. Apparently, deep within ActiveRecord, there’s a regexp that searches for string to interpolate. The solution, escaping the pound symbol, allows ActiveRecord to find and execute the interpolation.

Some people have asked why I’ve got a Hashrocket tattoo on my calf. The reasons are pretty biographical; ‘ware ye the history contained herein. Credit for the photo goes to Travis Schmeisser.