Shoulda Matchers 2.0

Shoulda Matchers has been around for a long time. Unfortunately, it’s starting to suffer from feature bloat so we’re narrowing its focus to keep releases fast and the maintenance burden low.

Removing Deprecated Matchers

The following matchers were deprecated in 1.5 and will be removed in 2.0 . If you’re currently using these methods you should consider testing the code in another way.

assign_to

The assign_to matcher allows you to ensure you have set an instance variable properly. We do not use this because we typically cover those types of assertions implicitly through an integration test. An integration test may be slower than a unit test, but it provides more thorough coverage.

validate_format_of

The validate_format_of matcher allows you to perform the same operation as the allow_value matcher. Please use the allow_value matcher instead.

should validate_format_of(:email).with('user@example.com')
should allow_value('user@example.com').for(:email )

have_sent_email

We recommend email-spec for testing emails in your apps. It has the added benefit of working with your integration suite as well as your unit tests.

respond_with_content_type

The respond_with_content_type matcher is not a matcher we use often. This behavior can be tested using the response object in your controller tests without the need for a matcher.

query_the_database

We do not have a recommended solution for a replacement on this matcher.

Matchers Removed Temporarily

The strong_parameters and delegate matchers will also be removed in 2.0. We ran into some trouble implementing them but hope to re-implement them in a less troublesome way soon.

New Hotness

As part of the move to 2.0, we will also be dropping support for Rails 2 & ruby 1.8. We will continue to support Rails 3.x and ruby 1.9.x and will be adding support for ruby 2.0 soon.

Keeping it tight

We are trying to keep Shoulda Matchers a tight focused gem and make sure the matchers we do support are as robust and thorough as possible. Do you think there are any other matchers we should remove?

Written by Jason Draper.

Handle incoming email with Griddler

For all the likes, shares, tweets, pokes, follows, and friends, there’s a fundamental core to the internet that, no matter how hard some might hope, will never go away—email. Rails has built-in support for outgoing mail with ActionMailer, but nothing on the omakase menu handles incoming mail. To help with that, we extracted Griddler from Trajectory and are now happy to release it—hot off the… ahem… presses.

Griddler is a Rails engine that provides an endpoint for the SendGrid Parse API. It hands off a preprocessed email object to a class implemented by you. We’re happy to look at pull requests that interface with other email services.

Setup

To get Griddler integrated with your app, add Griddler to your Gemfile, and bundle away:

gem 'griddler'

Griddler automatically adds an endpoint to your routes table resembling the following:

post '/email_processor' => 'griddler/emails#create'

But you may copy, paste, and modify that anywhere else in your routes for the purposes of your application.

Once Sendgrid posts to your endpoint Griddler will take care of packaging up the important bits of that data and providing a nice Griddler::Email object for you. The contract we expect you to go in on with Griddler at this point is that you will implement a class called EmailProcessor, containing a class method called process, which we will be passing that packaged up instance of Griddler::Email into.

For example, in lib/email_processor.rb:

class EmailProcessor
  def self.process(email)
    # all of your application-specific code here - creating models,
    # processing reports, etc
  end
end

The email object contains the following attributes:

• to
• from
• subject
• body
• raw_body

Of those, to, from, and subject fall on the obvious side as to their purpose.

Let your users interact with your app via email

What isn’t entirely obvious (but very cool) is that Griddler helps you handle the email body by cleaning up replies and providing the important parts of an email before -- Reply ABOVE THIS LINE -- in the body attribute. Note that the reply delimeter is adjustable in the configuration. We keep raw_body around, as contains everything before Griddler scrubs it into body so that you may use the contents for other purposes.

There is much more information in the Griddler README explaining the details, configuration, testing, and other bits.

If you like it, let us know what you think! As always, you can find the code on GitHub. We look forward to hearing all of the ways you use Griddler!

Giving thanks

Happy Thanksgiving! Here’s what thoughtbot is thankful for this year.

Our clients and customers

Thank you to our clients America’s Test Kitchen, Awesome Foundation, AxisCampus, Backupify, Blueleaf, CareZone, CoachUp, CountIt, Financial Diligence Networks, ImpulseSave, LevelUp, Lights Up, MAG+, MIT, Movenbank, OwnerAide, Redis to Go, Rock Lobby, SnapPay, Stattleship, Swoop, T1D, TDDium, Thrively, Truonex, Vertical Performance Partners, Yammer, and yBuy, for trusting us to work on your products.

Thank you to all of our workshop alumni, those of you who have bought one of our ebooks or screencasts, and everyone who is a Trajectory customer.

Software as a service providers

Thank you to Heroku for your awesome support and services hosting our applications.

Thank you to GitHub for hosting all of our open source and private code.

Thank you to CodeClimate for providing insight about the quality of our code.

Thank you to Travis CI for letting us know when our code is working (or broken) on various versions of Ruby.

Thank you to Rubygems.org for hosting software which makes our lives easier.

Thank you to 37signals for Campfire, Basecamp, and Ruby on Rails.

Thank you to Braintree for processing payments for ourselves and our clients.

Thank you to SendGrid for making world-class email delivery a no-brainer, and for your smart, friendly, tireless support.

Thank you to New Relic for making performance monitoring pleasant.

Thank you to Amazon for EC2, EBS, and S3.

Thank you to Tumblr for hosting our blog.

Thank you to Dropbox for hosting large design assets and important files.

Thank you to Google for Gmail, Analytics, Adwords, Hangouts, and search.

Business partners

Thank you to Gesmer Updegrove for handling our legal needs.

Thank you to AccountingDepartment.com for handling our accounting and bookkeeping.

Thank you to WeWork for our current home in San Francisco.

Thank you to CBRE and Richards Barry Joyce and Partners for helping us find our future home in San Francisco.

Thank you to TMF Group and Newcomers for helping us expand into Stockholm.

Open source contributors

Thank you to every person who submits a pull request to our open source projects, even the ones we don’t pull.

Thank you to Linus Torvalds for Git.

Thank you to Matz for Ruby.

Thank you to DHH, the Rails core team, and the Rails community for Rails.

Thank you to Yehuda Katz and Carl Lerche for Bundler.

Thank you to Nick Quaranto, Terence Lee, and Larry Marburger for making the Bundler API faster.

Thank you to John Resig for jQuery.

Thank you to Jonas Nicklas for Capybara, a big step forward in browser simulation and acceptance testing.

Thank you to KDE, Apple, Google, Trolltech, and Nokia for Webkit and QtWebKit, which enabled our capybara-webkit.

Thank you to Bill Joy, Bram Moolenaar, and Tim Pope for making and improving Vim, our beloved text editor.

Thank you to the many Postgres committers for a rock-solid and always-improving database.

Thank you to Hampton Catlin, Nathan Weizenbaum, and Chris Eppstein for Haml and Sass.

Thank you to Max Howell for making it simple to install dependencies like C compilers, Postgres, Ack, Exuberant Ctags, Tmux, ImageMagick, Redis, and more with Homebrew.

Thank you to Wayne E. Seguin, Michal Papis, and 37signals for making it easy to manage Ruby versions with RVM and rbenv.

Thank you Nicholas Marriott for making it easier to manage various terminals with Tmux.

Thank you to Dennis Ritchie for software.

Teachers

Thank you to Alan Kay for object-oriented programming.

Thank you to Martin Fowler for refactoring.

Thank you to the Gang of Four for design patterns.

Thank you to Uncle Bob Martin for clean code.

Thank you to Gerard Meszaros for xUnit testing patterns.

Thank you to Gary Bernhardt for sharing performance-enhancing Unix, vim, testing, and OOP techniques on “Destroy All Software.”

Thank you to Avdi Grimm for “Objects on Rails” and its associated mailing list.

Event organizers and hosts

Thank you to Brian Cardarella, Patrick Robertson, and all of the Boston Ruby Group for a fantastic local Ruby community with great talks and a calendar full of hackfests.

Thank you to Brightcove, ZenDesk, and ApartmentList for hosting fun Ruby and vim meetups in Boston and San Francisco.

Thank you Wrapp for hosting meetups in Stockholm.

Thank you to Aloha Ruby, Burlington Ruby, Eurucamp, Frozen Rails, Lone Star Ruby Conf, MagicRuby, NordicRuby, Railsberry, Rocky Mountain Ruby, RubyConf, Ruby Nation, Rupy, and Scottish RubyConf for allowing us to share our passion for programming with others in person.

And thank you, too, for reading, commenting, and making us think.