A smarter nutrition label for the web

Ah, the humble nutrition label. Since it was introduced in the 1990’s (in the U.S., anyway), it’s been pretty much ubiquitous. We see them everywhere, whether we understand them or not.

They’re particularly puzzling on foods with multiple ingredients. Looking at a nutrition label and an ingredients list side-by-side, you might guess which ingredients contribute the most to each nutrient, but you may be wrong.

Why am I talking about nutrition on a web development blog?

We implemented nutrition labels for Cook Smarts meal planning app, and put a twist on the classic. In addition to showing a nutrition label for every recipe, we show which ingredients contribute the most to each nutrient.

For instance, below are the nutrition facts for Orange-Sesame Beef Stirfry. By expanding the total fat, I can see that the #1 and #2 contributors are the flank steak and the cooking oil.

If I were counting carbs, I could expand total carbs and perhaps cut back on the rice.

Nutrition label shows which ingredients contribute most to each nutrient

Since we integrated the USDA’s robust nutrition database into Cook Smarts’ recipe editor on the back-end, we had this per-ingredient data. Instead of just exposing the recipe’s total nutrition facts, we tried to think of ways to go a little deeper. This is our first attempt at doing so!

The USDA database is huge, so we brought it onto a separate server that we interface with using our own API. It’s working well, and keeping the extra load off of Cook Smarts’ primary app server. More on our first attempt at service-oriented architecture soon!

Special thanks to Chris Coyier for his nutrition label HTML and CSSMatt Beedle for his USDA nutrient database gem, and Cameron Dutro for his Active Nutrition gem.

Sending Mandrill e-mails from Rails, the MVC way

Update: For updated guidance, see E-mail in Rails with MailChimp and Mandrill, a comprehensive guide

Mandrill is a transactional e-mail service for developers. It allows you to quickly reach out to users from your app via e-mail, through SMTP or Mandrill’s  API.

Cook Smarts‘ transactional e-mails sometimes go to many users at once, and we quickly hit the limits of SMTP. It was time to use Mandrill’s API to send out e-mails from our Rails app.

Here’s how we moved from ActionMailer/SMTP to Mandrill’s API while staying true to the model-view-controller (MVC) nature of Rails.

Install the Mandrill gem

Add the Mandrill API to your gemfile.

Then run ‘bundle install’ from the same directory.

Send e-mail

Want the simple version of the code needed to send a message? Check out Mandrill’s documentation.

Below we’re going to cover Cook Smarts’ more complex use case.

We specify the subject, from name, and from e-mail above, which is pretty self-evident.

But – surprise! – we’re sending this particular e-mail to a ton of users at once, and we want to address each user by name.

Addressing the message

This message is going to all users with a subscription. We have a scope in our User class called ‘paid,’ which returns all the paid users.

We need to get these users’ e-mail addresses into an array for Mandrill. A class method, User.to_mandrill_to, takes care of this.

When we call ‘User.to_mandrill_to(User.paid),’ we get all our paid users’ e-mail addresses back as an array.

Merge tags

Mandrill uses merge tags to personalize messages. For instance, we want to say “Dear Mary” if the message is to Mary, and “Dear John” if it’s to John.

When we send multiple messages at once, we need to tell Mandrill which name is related to which e-mail address.

Our e-mail template, stored in a Rails view, contains a placeholders for the user’s name:

Another class method, User.to_mandrill_merge_vars, associates each user’s e-mail address with their first name:

This gets us the value we need for the ‘merge_vars’ argument of the API request above.

The message

As stated earlier, the e-mail template lives as a view in our Rails app.

We’ll use render_to_string to process the template and insert it into our API request.

The view should be a full HTML page, including and tags. We add ‘:layout => false’ to avoid bringing in other header/footer content from our app.

Avoid an embarrassing mistake

Remember to include ‘:preserve_recipients => false’ in your API request, unless you want all the people you’re e-mailing to appear in the To line in every message. Mandrill has the details.

MVC Summary

Our Users model provides the addressee information, the meal plan e-mail template/view provides the message, and the admin controller sends the actual e-mail.

All of this without the use of SMTP or Rails ActionMailer – just Mandrill’s API.

We’ve found that this solution has worked well for transactional e-mails with multiple recipients.

If you’re looking for tight Mandrill + ActionMailer integration, check out the Mandrill delivery method gem.

We’re starting a series called Mailing on Rails, which will cover all the bases to get you up and running with mail in your app. Want us to let you know when it’s up?