Category Archives: Rails

Previewing emails in Rails applications with the mail_view gem

Mailer specs are a great to verify that the emails sent from your Rails applications have the required data, links, and important content. But often a developer, or more likely the product owner, may want to see the emails to make sure they are properly formatted, read well, and are free of spelling errors.

Getting your application to send an email from a development or staging environment can be an onerous task depending on how much user workflow and data setup is required for a given email. This is where the mail_view gem can really help you out.

The mail_view gem lets us easily preview emails right from within your Rails application running in the development environment

Using mail_view in Rails 4.1+

Configuring mail_view

mail_view is built into Rails 4.1+, so there is no additional setup or configuration to start using it.

You can read more about support for mail_view in Rails 4.1 in the following links

Edge Guides Release Notes

ActionMailer API Docs

Setting up emails to preview

By default, Rails 4.1 expects the mail preview classes to be located in the test/mailers/previews directory. If you use the mail generator, a preview file will be created for you automatically. You create a class that inherits from ActionMailer::Preview for each email to be previewed.

class WelcomeMailerPreview < ActionMailer::Preview

  def welcome_investor
    user = User.last
    WelcomeMailer.welcome_investor(user)
  end

end

Previewing the emails

Browsing to http://localhost:3000/rails/mailers/welcome_mailer/welcome_investor will show you a preview of the email. But before you do that you will probably need to set up some data for the preview

Using mail_view in Rails prior to 4.1

Configuring mail_view

For Rails versions prior to 4.1, there is just a little work to do to get set up.

First you will need to add the gem to your Gemfile.

gem "mail_view", "~> 2.0.4"

Then you mount the mail_view engine into your application via the routes.rb file.

  if Rails.env.development?
    mount MailPreview => 'mail_view'
  end

I wanted to make the mail_view available on my staging server, so I used an environment variable to enable it.

  if Rails.env.development? || ENV["PREVIEW_EMAIL"] == "true"
    mount MailPreview => 'mail_view'
  end

With the engine mounted at mail_view, browsing to http://localhost:3000/mail_view will present us with a list of emails to preview. But before we do that, we need to set up the emails to preview.

Setting up emails to preview

You set up the emails to preview by creating a class that inherits from MailView

class MailPreview < MailView

  def welcome
    user = User.last
    WelcomeMailer.welcome_investor(user)
  end

  def payment_confirmation
    payment = Payment.last
    PaymentConfirmationMailer.confirmation_email(payment)
  end

  def contact_us
    ContactMailer.contact_email("Joe Smith", "617-555-1212", "jsmith@example.com", "I have a question...")
  end

Listing the emails

Now that we have some emails to preview, we can browse to http://localhost:3000/mail_view will present us with a list of email preview links as defined in the MailPreview class.
Mail Preview List

Providing data for the emails

Typically our emails are working with data from our database. The mail_view documentation describes some of the ways you can provide data to the mailer, using either actual data from the database, using a factory pattern, or providing a stub.

In the examples above, I am using data from the database. Each approach has its advantages and disadvantages, and it really depends on how you data is structured as to which approach you use. You can also mix and match the different approaches as you see fit.

Viewing an email

mail_view displays a preview of the email with the header information shown in the page header and the body in an iframe, as shown below.
Mail Preview As HTML

If you have provided a text and html template for the email, a drop-down is displayed in the page header to allow you to preview the different formats. Here we are displaying the text version of the email
Mail Preview As Text

Since the body of the email is displayed in an iframe, clicking on a link in the email will open the link inside the iframe.
Mail Preview Open Link

Summary

The mail_view gem is a great tool to allow you to visually inspect the emails sent by your Rails application.

Aikido, Controller Tests, and LinkedIn at Launch Academy

I had a nice visit the other day speaking at Launch Academy.  It’s no secret that I am a big fan of the program.  As a community, we need to do more to produce good entry-level developers and also to help them develop their careers.

My talk was geared towards preparing them for what happens when they leave Launch Academy and some of the things they can do to continue learning and growing as software developers.  The three topics: Aikido, Controller Tests, and LinkedIn don’t seem to have anything to do with one another, but let’s look a little closer.

Aikido

I don’t know the first thing about aikido, but I do know of a talk that Alistair Cockburn gave where he talks about aikido and the three stage of learning: Shu, Ha, and Ri.  These stages of learning are common to almost any endeavor, including software engineering.  Right now, the students at Launch Academy are in the shu phase, learning a single technique from their masters.

When they go out into the world, they will be exposed to new techniques and new masters, and it is their responsibility to be open to these new techniques, try them out, and incorporate them into their own practices.  This is the ha phase.

With some hard work, practice, and luck they may reach the ri phase, where they are inventing their own techniques, but that wasn’t part of my talk.

I highly recommend the talk by Alistair Cockburn, it covers so many great ideas about developing your craft.  He is an amazing guy and his talks are always engaging.

Controller Tests

I have been thinking a lot lately about controller tests in Rails.  What value do they serve, are they still worth writing?  This is probably the subject of another blog post or series of posts, but in the talk I wanted to tie it in with the concept of shu-ha-ri and being open to new ideas.

When I first started learning Rails, one of my primary resources was Michael Hartl’s amazing tutorial.  So many of us owe him so much for showing us the way into an awesome framework.  At the time I was learning, I recall the tutorial having a fair number of controller tests, and those tests became part of my shu learning phase of Rails.

As I started to develop more Rails apps, and getting exposed to more practices and techniques, I was forced to rethink the role of controller tests.  I found some of the ways I was using them had little intrinsic value.  In some cases, they were essentially testing the framework (e.g. index action rendering index template) or were a mix of controller and view tests that were brittle and not as comprehensive as a Capybara feature spec.

Taking a ri approach, I have adapted my practices to do more outside-in tests.  These have the advantage of reinforcing the customer experience and keep me from diving too deep too soon.  They allow me to explore the data relations and behaviors before getting in to specifics about the low-level details.

It is interesting to note that in researching the talk, I could not find many (if any) controller tests in the current edition of Hartl tutorial.

LinkedIn

The third phase of the talk took a bit of a left turn, but I think is an important lesson for someone trying to break into the field.

I am a big believer in REAL networking, i.e. talking to people, building relationships, asking questions, and following up.  I have made some awesome friends, mentors, and mentees in the Rails community.  It took me too long to learn how to effectively meet people and build relationships.  Fear and imposter syndrome are tough things to overcome.

I see a lot of people not networking effectively and it makes me sad.  We had a really good discussion about getting out and talking to people, sending follow up/thank you emails, and personalizing your LinkedIn invites so the person on the other end remembers you and is inclined to accept your invite.  A big key is following up, if you make a contact at a meetup, say hello at the next meetup, ask a question about something they told you about themselves, be genuine.

As always, it was great to meet another Launch Academy cohort.  I hung around for quite a while and the Launchers had awesome questions.  Looking forward to seeing them out in the community soon.

Reinventing Yourself at Boston Ruby

I gave a talk at the November 2013 Boston Ruby Meeting about my experience moving back to a development role after working the last few years in more managerial roles in the medical device/laboratory automation space.

My hope was that this talk would help people starting out in the Rails world, or perhaps people who are transitioning to Rails from the Java or .NET worlds as I was.

Along the way, I also talk about ways to establish yourself in a new development community and how to build up your network beyond just adding people to your LinkedIn network

Wicked Good Wrap Up

What an amazing weekend at Wicked Good Ruby, where does one begin.

Thank You Brian, Johnny, Sean, and others

First things first.  Thank you Brian Cardarella, Johnny Boursiquot, Sean Hussey, and all the volunteers for making Wicked Good Ruby happen.  I remember being at the Boston Ruby meetup where Brian announced that he was organizing Boston’s inaugural Ruby conference. We all cheered wildly…then we went home, while Brian, Johnny, Sean and others did the hard work.

Kicking Us Off

Liana Leahy got us kicked off in song, reprising the role of Ruby Minstrel.  Liana has a great gift both vocally and satirically.  And if this Ruby thing doesn’t work out for her, I’m sure she could pursue other avenues

Opening Keynote

I was really excited when it was announced that Sandi Metz would be giving the opening keynote.  She promised to tell our future.  Along the way she took us from ancient scrolls on papyrus, to the Roman codex, handwritten manuscripts, the Gutenberg printing press, right up to the linotype machine.

Sandi shared some childhood memories of her dad, who worked for a newspaper in Parkersburg, WV, who started out working with linotype machines but managed to re-invent himself when the printing world changed in 1965 with the advent of photosetting and the sudden death of linotype machines.

She gave us some hard truths about life, we are going to die, but also reminded us that we need to live and love along the way.  I can’t do justice to Sandi’s words so look for the talk online later.   I was blown away.

Awesome Talks

I won’t try to go over all the talks, though there were a few that I really liked.

Joanne Cheng taught us how to play and explore with Ruby-Processing, showing some truly amazing ways she has used it to visualize data and just have fun.  I liked that she shared unexpected lessons that she learned along the way, becoming a better programmer, gaining confidence.

Mike Nicholaides reminded us about ways of securing our Rails app.  Stuff we should all know, but I know I left the talk thinking about some of the tests I am going to write this week to test for holes in my apps.

Neeraj Singh pointed out some of the “good” and “bad” magic of ActiveRecord.  His talk made me want to rush home and play around with different “features” of ActiveRecord that we take for granted work a certain way.  Understanding how they really work can save you a lot of pain.

Dan McClain had some really awesome ways to let your app take advantage of the advanced datatypes in PostgreSQL.  Dan obviously knows a ton about the internals of PostgreSQL, but he made things very clear and easy to use.  Another talk that makes me want to experiment and grow as a developer.

Matt Aimonetti talked about “good” code and “bad” code.  I was psyched that I got a question in that got kicked around by Matt, Sandy Metz, and Katrina Owen in the round-table discussion.

I wish I had more than 140 characters to ask a fairly nuanced question about what is the right amount of testing for a Rails app.  Fortunately I got a chance to catch up with Matt just before the conference ended to explore some ideas.  I love how approachable people are in this community.

Things to Consider

There were a lot of local developers at the conference, which was really nice to see.  I know a lot of the companies and developers from helping out at Boston Ruby.  One disappointing trend I saw was people sticking with their co-workers.  Sure it gives us a common understanding that we can take back to the office, and we don’t need to reach outside our comfort bubble and engage people we don’t know.  But that’s the best part of a conference.  Meet new people, learn what they are passionate about, share your experience.

Along those same lines I wish there was a little bit more time between talks.  It’s a balance between getting as much great content as possible but also having a chance to talk to other devs, or dare I say it, approach a speaker and say hello.  I really enjoyed talking to Matt Aimonetti, Neeraj Singh, and Mike Desjardin about their talks.  The short time between talks also made for some rushed moments when a speaker talk inevitably ran long.

Finishing Where I Started

Thank you Brian, Johnny, and Sean.  You guys kept things flowing and from where I was sitting it looked like everything went off smoothly.  I am sure there was furious activity behind the scenes, but it looked like a well oiled machine.

And thank you volunteers.  Working the registration table, arranging sponsors, sending out emails, and coordinating the speakers and attendees is a mostly thankless job, but let me say this.  Thanks 🙂

Getting Started with Rails Testing

I gave a presentation at the January 2013 Boston Ruby Project Night on “Getting Started with Rails Testing”.

This talk aims at understanding the development workflow while using TDD and the Red-Green-Refactor loop.

We look at the different test types that you can write in a Rails application

  • Unit tests
  • Controller tests
  • Integration tests

We also look at some of the tools and frameworks that are available for testing, including RSpec, MiniTest, Test-Unit, Capybara, and FactoryGirl.

A simple example is used to show the test-driven development workflow.  The code for the example is on github at https://github.com/mdenomy/expense_tracker.

The github repository uses branches to capture a series of snaphots in the test-driven-development workflow.  See the Readme file for a list of the branches, or run the “git branch -a” command to see the full list from the terminal.

So Ends The Season of Ruby

After a few false starts trying to get started with Ruby, I made a commitment this year to dive in with both feet and really learn it.  I decided on the notion of a “season” to dedicate to getting started with Ruby, and I think my initial dive has come to an end.  When are you ever done learning about a language or a technology, probably never?  And I am no more done learning about Ruby than I am done learning about C#, Java, Python, Perl, Javascript, or any other language.  Well, maybe Perl (ha, ha, ha).

So my introduction to Ruby and Ruby on Rails has not disappointed.  As expected, the community is vibrant and on the whole focused on real quality and craftsmanship.  There is no shortage of great resources out there to help a developer come up to speed on Ruby and Ruby on Rails.  And in that spirit, I wanted to take a snapshot on what I have learned, what resources I have found helpful, and where I might focus in the future.

Learn Ruby First

It is surprising easy to get up and running in Rails without really knowing much Ruby, just follow the wealth of examples and tutorials that are already out there.  I would argue strongly against that approach though.  Ruby has some really great features, especially if you are new to dynamic languages.  There is a an expressive syntax, great features like blocks and iterators, and incredibly rich set of standard libraries and 3rd party gems that allow you to build on.

Here are some of the resources I used to get up to speed with Ruby

Ruby Koans – Well structured introduction to the various features of Ruby.  A great intro to the language that you can bang through pretty quickly and refer back to when questions arise.  I have a lot of experience with Test Driven Development, but if you are new to TDD this will also get you thinking about TDD and how to write tests for your code.

The Pickaxe Book – Great resource on features of the Ruby language

The Ruby Way – Extensive resource for ways to solve several common programming tasks using Ruby.  This is also a great early introduction to writing in a Ruby-esque style, which was really helpful for me coming from C#.

Ruby-Doc.org is another good reference for features about Ruby, especially the core API and standard library.

Moving on To Ruby On Rails

There is just an incredible wealth of resources to getting started with Ruby on Rails.

I spent a lot of time on Michael Hartl’s Ruby on Rails Tutorial.  I loved the focus on TDD and good developer practices.  Other added benefits to this tutorial is it is a gently introduction to git and even shows you how to push your code up to heroku.  I know this is a resource I will continue to come back to again and again.

As much as I loved the Hartl tutorial, I wish I had actually started with Rails for Zombies.  Rails for Zombies is put on by Code School, which has a lot of content available for purchase, but the Rails for Zombies course will give you a good introduction to Rails and it’s free.  You can blast through it pretty quickly, gives you a good sense of the basics, and it really sets the table for a deeper dive into Rails.  I actually did this after spending a lot of time with the Hartl tutorial, but doing Rails for Zombies provided a lot of “a ha” moments as I went through it.

RailsCasts has a ton of great content, both free and by subscription and is just a fantastic resource.  The screencasts are typically anywhere between 5 and 15 minutes and cover a huge range of topics.

I can’t get enough of the Ruby Rogues podcast.  These guys do a fantastic job and have great chemistry.  I am shocked that they can do all of this every week, and it has made my commute a lot more educational and enjoyable.  They have some great guests and even for a newb I find the content informative.  Some stuff goes past me, but I usually go to the website afterwards and follow up on the links for the list of topics discussed on each episode.

Ruby 5 is another great podcast.  It serves a different purpose than Ruby Rogues.  Ruby 5 is more of a news oriented feed of what’s happening in the Ruby community, what gems have been released, what books have come out, etc.

Other great resources for learning about Rails are the Rails Guides and Rails ApiDock.

Get Involved in the Local Community

I am fortunate that in Boston there are a lot of resources for meeting and learning from other people in the community.

Boston Ruby puts on some great talks each month and also does hackfests a couple times a month.  I have been to a few talks, but really need to get to the hackfests. They also have a very active mailing list that is a great resource for technical issues.

The Boston Ruby on Rails group meets more sporadically, but seems like a great group.  I went there for a series of lightning talks just before starting the Season of Ruby and there was a spirited Q&A after each of the talks.  I am sure that helped motivate me.

I also went to a few workshops put on by thoughtbot that I got a lot out of: the Web Design and Development Process, and Intermediate Ruby on Rails.

Where to Next

The simple answer is just write more code because that is the best way I know to improve.  There is still sooooooo much to learn.

The Non-Linear Nature of Learning

Learning is a funny thing, rarely does our knowledge progress in a smooth, linear fashion.  I have been spending some of my copious free time learning Ruby and Rails and in that time I have experienced various moments of joy, frustration, utter confusion, and total clarity.  It got me to thinking about the way we learn.

Inspired by Jessica Hagy’s great work at Indexed I came up with this diagram.

I experienced a brief, fleeting moment of Ruby hubris (Rubris?) a few weeks back and implied I was starting to “get it”, even invoking the good name of Ralph Kramden.  Well the Rails gods rightfully smited  me for my lack of a deep understanding of Rail’s Active Record Associations.

For my penance, I have started to take a look at HacketyHack and hope to soon contribute some lessons or help out however I can.  If anyone knows of any other resources for teaching kids to code, I’d be interested in helping out.

Needless to say I’ll also be spending some time trying to grok Active Record Associations as well.

Still having a blast on this journey.