Denver Drinkup

Hey Denver! Our CTO, Joe Ferris, is going to be in Denver next week and we’d like to have a beer with you. We’ll be joining some of our friends over at SendGrid in their spiffy Denver office for good local beer and a talk on “Improving Performance for Real-Time Requests”.

Joe will be schooling us on how to improve slow requests, avoid duplication, invalidate caches, and refactor for performance within Rails applications.

Leave us a comment with your favorite local beer and we’ll do our best to make sure we have you covered. We’ll also have some nonalcoholic beverages on hand as well.

Our Denver/Boulder team now includes, myself, Corey, Elliot, Sean and a few more starting in the next couple of weeks.

Most of us will be there and we are looking forward to meeting you!

RSVP here.

Thursday, April 4th, 6:00 PM at 1451 Larimer Street, 3rd Floor Denver, CO 80202 USA

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!

Delivering email on behalf of users

A recipe for a better user experience in emails sent between users via my Rails app.

Why?

When I receive an email from an automated system like a Rails app, it is disorienting if the sender shows up in my email program as “admin” or “donotreply”.

What I want is something like this:

Ingredients

• ActionMailer
• The email_spec Ruby gem

Install email-spec

I’m a fan of Ben Mabey’s email-spec gem, so I’ll install that:

group :test do
  gem 'email_spec'
end

I create a features/support/email.rb file:

require 'email_spec' # add this line if you use spork
require 'email_spec/cucumber'

Then generate some step definitions into features/step_definitions/email_steps.rb:

rails generate email_spec:steps

Feature

Now I’ll write my user story:

Scenario: Guitarist shares song with guitarist
  Given the following user exists:
    | name         | email            |
    | Eric Clapton | eric@example.com |
  And I sign in as "eric@example.com/password"
  And I am on the share page for "Layla"
  When I fill in "Share with" with "jimi@example.com"
  And I press "Share Song"
  And "jimi@example.com" opens the email
  Then he should see "Eric Clapton " in the email "From" header
  And he should see "eric@example.com" in the email "Reply-To" header

The “From” and “Reply-To” headers

I think the “From” and “Reply-To” headers can provide a better user experience.

I don’t set the author’s email as the “From” header because I hear it’s bad spam practice to send email on behalf of users in that way. ISPs use the From header (among other things) to determine if the originator is sending spam.

Making the feature pass

Ease my worried mind:

class Mailer < ActionMailer::Base
  def share_song(song, friend)
    mail(
      to: friend.email,
      from: %{"#{song.artist.name}" },
      reply_to: song.artist.email,
      subject: 'Good song'
    )
  end
end

I’ve used this format so the sender’s name shows up in the receiver’s email program:

"Name" 

In this case, I want Jimi to be able to reply directly to Eric, so I’ve set the “Reply-To” header to be the sender’s address. I’ve explicitly not put the sender’s name in the “Reply-To” header because that doesn’t work.

In other cases, I want the receiver to reply to the email and have that sent through the Rails app, but that’s a story for another day.

Written by Dan Croak.