Problem: Test email delivery in your local box

Problem: Test email delivery in your local box

Solution: http://babygnu.blogspot.com/2009/10/deleviring-mails-from-rails-app-to.html

Problem: You want to create a remote branch in git.

Problem: You want to create a remote branch in git.

Solution: Read http://djwonk.com/blog/2009/04/18/tracking-remote-git-branches

Problem: How to set up a Rails server the right way

Problem: How to set up a Rails server the right way

Solution: Read http://blog.envylabs.com/2009/08/set-up-your-server-right-part-1/

Problem: your JavaScript code is from the 90's

Problem: You know enough Ruby on Rails, but you feel like your JavaScript code is from the 90's. You want to organize your javascript code and apply best practices. JavaScript MVC frameworks overwhelm you.

Solution: Read

• http://tore.darell.no/pages/javascript_eye_for_the_ruby_guy and
• http://tore.darell.no/pages/unobtrusive_javascript_with_rails

Problem: You want to organize and apply best practices to your javascript code.

Problem: You want to organize and apply best practices to your javascript code.

Solution: Try a javascript mvc framework, like www.javascriptmvc.com

Problem: Your static assets are missing after a deploy

Problem: Your static assets are missing after a deploy

Solution: Bundle your assets during deployment

Source: http://overstimulate.com/articles/deploy-rails-missing-stylesheets

Simplify sending emails in Rails

Problem

Sending emails can be painful in Rails.

Why?

• No REST-like conventions. Should I divide my mailers by model or just put them all in one big Notifier class (as implied in the API)? How should I name my email methods?
• Lack of visibility. When writing views, you can check out the view in your browser as you are writing it. With emails, you can only view the email when its sent to your inbox. If the email depends on an event in your app, you have to redo that event anytime you need to view the email.

How we lessened the pain

Write a generic mailer

With the help of this blog post, we wrote our own generic mailer:

Now, we can send emails like so:

That's one less email method definition to worry about!

Note that template_name is used to determine the subject (take from the localization file) and the name of the template. Templates are saved in generic_mailer/<objects>/<template_name>. In the above example, the user_created_a_feedback.html.erb file should be under generic_mailer/feedbacks.

Test if you're sending the right email to the right people

For t(:key) to get the localization, we added the following test helper:

Preview the email on your browser

Since Rails is the golden hammer to all problems, it is what I used to preview the emails on my browser (instead, of say, using an IDE that can do this sort of thing).

There are two parts. The route:

and the controller:

That's about it! Now I can preview the email above in the following url:

http://localhost:3000/generic_mailer/feedbacks/user_created_a_feedback/1

Since you can view sensitive data from this controller, it's important to secure this controller before you release to production.

Testing your emails manually

We use http://www.mailinator.com to test our emails, i.e. in our staging environment, all our user emails end with "@mailinator.com".

Another service that looks interesting is http://litmusapp.com.

Code

http://github.com/gsmendoza/email_demo/tree/master

You can find me at

• oDesk
• GitHub
• Working with Rails
• StackOverflow
• Facebook
• Twitter
• Friendster