Close
Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

Grant Hutchins

Posts By

LABS
Unit-Testing AngularJS in a Rails app using the Jasmine gem

Testing AngularJS applications is easy with Jasmine. If you look at the AngularJS docs, many of the code examples show a corresponding Jasmine spec.

One important part of AngularJS’s testing support is the included angular-mocks.js file. This file contains a module called NgMock that provides a set of fake services for things such as HTTP requests, in order to make them easier to unit test.

Read more »

LABS
Keep gem configurations up-to-date with Rails generators

Many Ruby gems are packaged with a Rails generator that generates a configuration file. Keeping these gem configurations up-to-date can be much easier if you take advantage of these generators during the upgrade process.

Installing a gem that has configuration

One example is simple_form, a gem that makes it easy to create and maintain forms.

Read more »

LABS
Testing Active Record Scopes

Active Record scopes are an interesting thing to test. In projects I’ve worked on, I have seen many different patterns of testing, some much better than others.

A little over two years ago I wrote the gem pg_search, which provides a sort of Domain-Specific Language (DSL) for creating Active Record scopes that take advantage of PostgreSQL’s built-in full-text search.

Read more »

LABS
Using Arel to build complex SQL expressions

I write and maintain a gem called pg_search that makes it easy to build Active Record scopes that take advantage of PostgreSQL’s built-in full-text search functionality.

Part of generating these scopes involves taking user input (which come in as Ruby strings) and comparing it against columns in database tables to see which records match.

Read more »

LABS
Refactoring the Deeply-Nested Hash Antipattern

On a few different Ruby projects, I have seen an antipattern emerge involving nested hashes.

For example, consider this simple question-and-answer command-line script:

QUIZ = { question_1: { prompt: "What is your name?" }, question_2: { prompt: "What is your favorite color?" } } answers = {} QUIZ.each do |name, question_hash| print question_hash[:prompt], " " answers[name] = gets.chomp end p answers

The QUIZ constant isn’t too hard to understand.

Read more »

PIVOTAL LABS
Standup 01/09/2012: Lightning and Rakes

Help

"RSpec 2.8 is out. The Rake runner in TeamCity isn't yet working."

The suggestion was to update to an EAP release of TeamCity.

Events

LABS
pg_search: How I Learned to Stop Worrying and Love PostgreSQL full-text search

I’m a Pivotal Labs developer at our NYC offices working on the Casebook development team. Casebook is a child-welfare-focused web application used by governments and non-profit organizations. Our users are social workers, caseworkers, and their leadership who work with children, families, and the broader community to provide services that ensure children are safe and healthy.

Search worries

Our users need to quickly find accurate information about the people on their workload to respond appropriately in crises and keep a high quality written record of their work with the children and families.

Solr powered Casebook’s initial search engine. Solr is built in Java, so we set up our application servers to run Java alongside our Ruby on Rails web application. We maintained a real-time copy of our important searchable data, such as people’s names, in our Solr index.

Our Solr-based approach ran into a few problems. Sometimes users would see outdated search results or, even worse, errors. This was annoying and also potentially damaging to our users’ ability to keep up with emergency situations.

Keeping our data synched in multiple locations caused most of our problems with Solr. Some of our more complex code paths would update the database but not propagate those changes to the search index. Users saw search-related error messages when there were communication problems with our Solr instances.

We had some fail-safes in place.

We wrote code that automatically restarted the Solr instances when they crashed. When we found the search data diverged from our application data, we manually rebuilt the search index to get the two data stores back in sync. These solutions just managed our problems rather than solving them.

These problems aren't unique to Solr. Other tools like Lucene, Ferret, and Sphinx have the same shortcomings when combined with Ruby on Rails.

Using the database itself as the search index

So the thought occurred to our team that we ought to try to make the database itself be the search index. We use a PostgreSQL database, and PostgreSQL 8.3 and later have built-in support for full-text search. PostgreSQL is a popular, mature SQL database solution that works great with Active Record. If you use Heroku, then you are already using a PostgreSQL 8.3 database that supports full-text search.

Since full-text search in PostgreSQL uses fairly complex SQL queries, we decided that the best approach would be to take advantage of Active Record's scopes. The idea is to make it easy to write code that looks like this:

Book.search_title("Ruby").include(:author).where("created_at > ?", 1.year.ago).limit(10)

So, I am proud to introduce pg_search, a Ruby gem that makes it easy to build search scopes that work just like this.