Resources for addressing the Heartbleed zero-day OpenSSL bug


Heartbleed is a zero-day bug in many OpenSSL implementations, and effects a huge swatch of servers on the Internet. Here’s a list of resources I’ve been referencing:

I am thankful today for SaaS platforms and virtual hosting environments, as they’ve meant I’ve had to do a minimal amount of work on my end to patch the applications I maintain.

Happy 21st Birthday, Ruby!


Ruby wasn’t the first development language I fell in love with, and it probably won’t be the last, but it’s beautiful and fun and it’s my favorite tool in my toolbox at the moment. It turns 21 today. If you haven’t already, give it a try!

Some useful Bash shortcuts for Ruby on Rails commands


Like any developer, I spend a lot of time in the terminal typing out commands. Anything I can do to cut down on keystrokes is a daily win, which is why I’ve got over 50 bash alias entries.

I frequently have to work on a several different Rails projects at a time, ranging in versions from 2.3 – 4.0. Hammering out commands for console, server or generate can get pretty tedious by the end of the day, so I came up with a couple shortcuts that I’m particularly fond of:

alias rails_mv="rails -v | sed 's/Rails \([0-9]\).*/\1/g'"
alias bexec='bundle exec'
alias brake='bundle exec rake'
function cons () {
  if [ `rails_mv` -lt 3 ]; then
    ./script/console "$@"
    bexec rails c "$@"
function gen () {
  if [ `rails_mv` -lt 3 ]; then
    ./script/generate "$@"
    bexec rails g "$@"
function srv () {
  if [ `rails_mv` -lt 3 ]; then
    ./script/server "$@"
    bexec rails s "$@"
alias sandbox='cons --sandbox'

What I like most about the cons, srv and gen commands is that they eliminate the mental overhead of context switching when going from the old 1.x and 2.x projects where each command is a separate bin file versus the newer 3.x+ project where they are just arguments to the rails command – It’s the same alias for every project.

Using dig to view, backup and verify DNS zone records on OS X


I was recently asked by a client to consolidate all of their DNS zone records and domain name registrations from 2 separate services to a single provider. The FAQ page of the current DNS service recommended using the named-xfer shell command, but that utility isn’t available on OS X. I googled around and learned that dig is a suitable alternative.

Finding the nameservers

Dig can be used to find nameserver information for a given domain:

$ dig NS +short

Viewing and Backing up DNS Records

$ dig IN ANY
;; Truncated, retrying in TCP mode.
; < <>> DiG 9.8.3-P1 < <>> IN ANY
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 12683
;; flags: qr aa rd; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 5
;; ANSWER SECTION:	14400	IN	NS	14400	IN	NS	14400	IN	NS	14400	IN	MX	0	14400	IN	MX	0	14400	IN	A	14400	IN	SOA 2013122000 16668 1800 1814400 14400
;; ADDITIONAL SECTION:	14400	IN	A	14400	IN	A	14400	IN	A 14400 IN	A 14400 IN	A
;; Query time: 150 msec
;; WHEN: Tue Feb  4 16:17:59 2014
;; MSG SIZE  rcvd: 305

Backing these up just requires you to send that output to a file: dig IN ANY >>

Once you’ve updated the nameservers for a domain you can verify if they’ve changed using the dig NS +short command.

Other useful dig commands

$ dig A +short

Integration Tests for a Custom PayPal Express Checkout Integration


Paypal Express Checkout is a great way to add or extend the checkout capabilities of an e-commerce store. Most e-commerce software bundles have support for this baked in, but when you’re working with a custom-built shopping cart and have to roll your own Express Checkout integration it can be a real bear. The PayPal developer documentation is fragmented and often contradictory, and it’s never entirely clear about what steps are required to setup a developer account. They also often refer to their services using different names. And their support system is slow and cumbersome.

Because of this, when I recently worked on an Express Checkout integration for a Panoptic Development client, it took us a lot longer than we expected. A lot of that additional time came from trying to workout a proper integration test suite that would exercise our custom integration points without actually needing to hit the PayPal servers with valid requests every time. It took a lot of trial and error, but in the end I was able to get these tests working by mocking some service calls and stubbing out methods from the PayPal SDK libraries we were using.

For anyone stuck in the same spot, I documented my efforts at StackOverflow: “How to configure integration test for PayPal Express Checkout using TestUnit in a Rails 2.3 app“. My current set of tests differ slightly from what is show there and I ended up refactoring quite a bit as I added new tests, but that question and answer should be a good starting point.


I’ve posted a gist of all of the moving parts of my current implementation of this:

Integration tests for PayPal Express Checkout using TestUnit in Rails 2.3


Configuring PhoneGap for cross-platform mobile development on Mac OS X Mavericks


One of my professional goals for this year is to publish a mobile app for at least one Panoptic Development client. I’ve been researching different cross-platform mobile development frameworks to see how they would fit various project leads, and a couple weeks ago I decided to give PhoneGap a try. It wasn’t as straight forward a process as their documentation would have one believe, so when I finally had it up and running I posted my own documentation on the Panoptic Blog.

Complete instructions at: Up and running with PhoneGap on Mac OSX

Testing for a redirect using Capybara and Selenium WebDriver


I just spent the better part of 8 hours trying to figure out how to do this. The Selenium WebDriver API docs are pretty bewildering especially when it comes to trying to interact with the HTTP response or request itself because those constructs are abstracted quite a bit.

Then /^I should be on the (.*) page$/ do |page_name|
  object = instance_variable_get("@#{page_name}")
  page.current_path.should == send("#{page_name.downcase.gsub(' ','_')}_path", object)
  page.status_code.should == 200
Then /^I should be redirected to the (.*) page$/ do |page_name|
  page.driver.request.env['HTTP_REFERER'].should_not be_nil
  page.driver.request.env['HTTP_REFERER'].should_not == page.current_url
  step %Q(I should be on the #{page_name} page)

Which we can use in a Cucumber feature like so:

Given I am on the homepage
When I click on the link to add a widget
Then I should be able to complete the widget form
  And I should be redirected to the widget page
  And I should see a confirmation message
  And I should see the widget listed

Setting up a Rails 3 virtual machine using Vagrant and VirtualBox


I recently started bringing other developers on board to help me with a project that up until then I had been the sole developer on. I already had some rudimentary installation instructions that I had updated on occasion as I was originally developing the application, but it turns out that all the developers experienced problems of one kind or another while following along on their own development machines. Although I had recommended using RVM to at least isolate the application gem bundle, it was clear that there were other per-machine libraries and dependencies that were not being accounted for. So, I decided to include instructions on setting up a virtual machine which would hopefully alleviate these issues. My problem with VMs in general though, especially ones that you want to spin up and tear down quickly, is that it’s still possible for everyone involved in the project to be using a different VM manager and linux distro, and thus a different package manager and standard lib setup, and you still need to do a lot of setup after the fact to get all the necessary components to work. Enter Vagrant. (more…)

Notes on Single Table Inheritance (STI) in Rails 3.0


I’m currently working on a project that calls for splitting up a single model into two similar models with slightly differing functionality. I was already familiar with Alex Reisner’s excellent article on when to use Single Table Inheritance versus the other alternatives that one might use, and after re-reading the article with a colleague it was determined that STI was probably our best bet. However, neither of us could remember seeing any recent articles on STI in Rails, specifically with Rails 3, and it’s been my experience that if people aren’t talking about a Rails feature it’s probably because it’s been recently deprecated or replaced.

Not wanting to back ourselves in a corner before we were sure it would work, I decided to spike a dummy Rails app and see what problems we would run into. There are plenty of questions on StackOverflow (1, 2, etc.), et. al., with various suggestions for working through issues related to STI, but there was no one concise guide that detailed the benefits and drawbacks of each approach. I decided to document my findings. This is my first real-life attempt at implementing an STI pattern, so please leave a comment if you feel that I omitted something or if you know of another way to approach one of these issues.


Testing model validations in rspec the short and sweet way


There seems to be a divide in the Rails/TDD community over whether you should bother testing your model validations. On the one hand, it’s silly to just retest what the Rails core team has hopefully already tested — that validations work. On the other hand, I want to make sure that my models only accept the data that I design them to accept. I also tend to use my RSpec unit tests as blueprints for building out my models, in true TDD fashion, so I start out by defining what values they should accept.


Go to Top