Sending Gmail Emails With Rails

As part of our meetup project, I needed to figure out how to send email via Rails. Our website allows a user to select a favorite photo and then receive a link to that photo via email.

Rails sends email through something called the Action Mailer. The Rails Guides explain how to set up Action Mailer, but I needed to take some additional steps that the documentation didn’t include. For instance, the guide explains how to send a welcome email after a user signs up, but we wanted to send an email later on – after the user selects a favorite photo. Here is how I got it working for Gmail.

As the guide points out, mailers are conceptually similar to controllers. We generate a mailer via the command line:

rails generate mailer UserMailer

This creates a file called app/mailers/user_mailer.rb. More on this file later.

In our project, the user enters an email address via a form. In the code below, the form_tag directs to the users/create action – the create method in the User controller – and the e-mail field passes an :email_address to the params. And since we want to send the user a photo URL, we pass the photo URL as a hidden field:

<%= form_tag("users/create", method: "get") do %>
<img src="<%=@picture_chosen.photo_url%>">
<%= hidden_field_tag(:photo_url, @picture_chosen.photo_url) %>
<%= email_field(:user, :email_address) %>
<%= submit_tag("Submit")%>
<% end %>

On submit, the data passes to the User controller’s create method:

class UsersController < ApplicationController

def create
  @user =
  respond_to do |format|
    @user.email_address = params[:user][:email_address]
    @user.photo_url = params[:photo_url]
      format.html { redirect_to(root_path, notice: 'Favorite photo chosen') }
      format.json { render json: root_path, status: :created, location: @user }
      format.html { render action: 'new' }
      format.json { render json: @user.errors, status: :unprocessable_entity }


def user_params
  params.require(:user).permit(user: [:email_address, :photo_url] )


The email address gets saved as @user.email_address, which we must add to the permitted user params. Upon, we get directed to:


UserMailer is the mailer we created at the beginning via rails generate mailer UserMailer. (The deliver_now at the end sends the email immediately; there is also an option for deliver_later.)

So we're directed to the UserMailer, and we need to put the following code in there:

class UserMailer < ApplicationMailer
  def result_email(user)
    @user = user
    @url = user.photo_url
    mail(to: @user.email_address, subject: 'Your favorite photo')

We're setting the individual user and the photo URL as objects so we can pass them, and the mail command specifies the email address and the email subject.

The UserMailer inherits from ApplicationMailer, which, like UserMailer, lives in the app/mailers/ folder. ApplicationMailer needs to contain the email address from which the email will be sent:

class ApplicationMailer < ActionMailer::Base
  default from: ""
  layout 'mailer'

(Replace "email_sender" with the actual sending account.)

To go along with the UserMailer, there is a corresponding user_mailer folder under app/views/. The user_mailer folder contains two files, result_email.html.erb and result_email.text.erb. The former sends an HTML-formatted email; the latter contains a text-formatted email, which will be sent if the user's email client doesn't accept HTML-formatted email.

Here's our HTML-formatted email in our result_email.html.erb file:

<!DOCTYPE html>
<meta content='text/html; charset=UTF-8' http-equiv='Content-Type' />
Thanks for picking your favorite photo! Here is a link to the photo you chose as your favorite:
<%= @url %>

Note that since we created a @url object in the UserMailer, we can call it in the email above.

This sets everything up, but the email won't actually get sent unless we add the following code to the three files under config/environments/ -- development.rb, production.rb, and test.rb:

config.action_mailer.default_url_options = { host: 'localhost', port: 3000 }
config.action_mailer.delivery_method = :smtp
config.action_mailer.raise_delivery_errors = true
config.action_mailer.smtp_settings = {
:address => "",
:port => 587,
:domain => 'localhost',
:user_name => ENV["gmail_username"],
:password => ENV["gmail_password"],
:authentication => :login,
:enable_starttls_auto => true

This works for Gmail. Other email clients will require slightly different settings.

Note that :user_name and :password are ENV keys, because these are the sender's username and password, and we don't want the password to be visible to others. We should also install the Figaro gem and require it in the Gemfile. This creates a file called config/application.yml, which gets added to the .gitignore file and will keep the email name and password hidden. Open this file and add the following (replacing the sample user name and password with the real ones):

gmail_username: ""
gmail_password: "123456789"

Make sure "gmail_username" and "gmail_password" are spelled the same in both the config/environments files and the config/application.yml file.

And we're done. Your application can now send email.

Refactoring Your Code After Adding a Feature

This has been project week at Flatiron, and while designing our websites we’ve been learning to follow the principle of minimum viable product, or MVP. This basically means “the smallest thing you can build that lets you quickly make it around the build/measure/learn loop” or “the smallest thing you can build that delivers customer value (and as a bonus captures some of that value back).”

The idea is to start by building a simple product that works before adding new features. Here’s the image we were shown in class that illustrates MVP:


Our group decided to build a site that maps out public restrooms in New York City so users can easily find a place to answer nature’s call. Users can review existing restrooms and even add restrooms to the site’s database. In creating our site, we found it useful to follow the MVP principle, but this created some issues we had to fix later on.

There’s an existing database of public restrooms in New York City public parks, so we decided that our MVP was to build a map showing all these restrooms. Only after we’d built out this minimum product and had it working would we build the next feature: letting users add restrooms to the database.


When we built out our MVP, we created a table in our database called public_parks. We also had a PublicParks controller, a PublicParks model, PublicParks views, and PublicParks routes. We had a public_park_id as a foreign key in another of our tables, and we had public_parks objects throughout our code. This was all fine when we were working on our MVP, but it created problems when we expanded our project to let users add public restrooms in other types of venues such as restaurants and stores. Each of our parks had a “show” page with the path “/public_parks.” But this URL wouldn’t make sense for a restaurant or bookstore. And anyone looking at our code would be confused by a public parks table that also included stores and restaurants, or public_park objects that weren’t parks. What to do?

We realized we had a couple of options. One, we could create a new table called location types and refactor from there. The other option was just to give the public parks table, files, objects, and routes a new name. Which choice was better?


We realized that, given the features we were planning, there was no need to create a separate table of location types. There was nothing that separated one type of location from another: whether the restroom was in a park, store, or restaurant, our users would be able to rate it on a scale from 1 to 10 and write a review. Therefore, we decided to rename our public parks table, controllers, views, models, and routes as restrooms. Had we wanted to add any features that applied only to stores or restaurants — such as operating hours — it might have made more sense to create separate location types. But since we were creating a fairly simple website, it made more sense to put every location in one table and not differentiate.

But we actually did add a column for location type to our parks table, which gets assigned when a user adds a restroom to the site. The user selects a choice from a dropdown table to categorize the restroom as a park, restaurant, or store. If, in the future, we decide to do different things for these different location types, we have a way to distinguish them without tediously going through all our locations and assigning them location types, one by one.

Depending on your MVP and the features you expect to add later, you’ll have to figure out the best way to structure your code from the start and what you’ll have to do to refactor your code later. As I go through my career and work on more complicated projects, I look forward to learning more about how to plan my code and refactor it. Revising code can be just as fun and challenging as writing it.