Ruby on Rails Planet

Double Shot #632 »

Created at: 22.01.2010 15:23, source: A Fresh Cup, tagged: Double Shot actionmailer db2 osx PostgreSQL rails smtp twitter

12 is really too many billable hours for one day.

PostageApp - SMTP mailing service that integrates directly via a Rails plugin.
IBM DB2 Gem Version 2.0.0 Released - For Rails/ActiveRecord, now supporting paramaterized queries.
Tuning Your PostgreSQL Server - A basic introduction.
Table size, database size - Determining physical storage sizes with PostgreSQL.
Setting PostgreSQL’s SHMMAX in Mac OS X 10.5 (Leopard) - How to temporarily bump up shared buffers without rebooting - works in Snow Leopard too. He's a bit confused about SHMALL, though, which is in pages rather than bytes on OS X.
KyngChaos PostgreSQL - Precompiled OS X installers, including server, client, PostGIS, and pgRouting.
Rails 3 Reading Material - Link list from Maxim Chernyak.
What is Shared Memory - Straightforward explanation of OS X shared buffers with some alternative settings.
Telephone - SIP/VOIP app for OS X.
Twitter Unstupidify - Greasemonkey script from Peter Cooper, for those of us who dislike the new retweets.

Double Shot #623 »

Created at: 11.01.2010 13:31, source: A Fresh Cup, tagged: Double Shot actionmailer hamster jquery plugins rails resque

Remember, the next RailsBridge BugMash is this coming weekend. Join us to hammer on Rails 3 and maybe win a prize.

Stock Names - A lovely spoof.
State of the Stack - New Relic looks at what's being used for Rails applications based on their users. Ruby 1.9 penetration remains negligible.
Apycom - Nice-looking selection of jQuery menus, though they do charge a minor fee if you want unobfuscated code.
Hamster - Efficient, immutable, thread-safe collection classes for Ruby.
ResqueMailer - Asynchronous mail from ActionMailer via Resque.
Coda-Slider 2.0 - Nice jQuery plugin to swap pages of text in an animated fashion.
14 Days of jQuery - And speaking of jQuery, looks like they have a bunch of stuff planned in conjunction with the 1.4 release.
WEBrick has an Escape Sequence Injection vulnerability - Security issue that affects all versions of Ruby from 1.8.6 onward. Thankfully it looks pretty obscure.
tracked_plugins - Manage your Rails plugins with extra metadata.

Sending email: Controllers versus Models »

Created at: 16.11.2009 17:33, source: Robby on Rails, tagged: Ruby on Rails programming development rubyonrails actionmailer models controllers patterns

While reviewing some code recently, I came across controller code that resembled the following.

if @customer.save
  CustomerMailer.deliver_welcome_message(@customer)
  flash[:message] = "Your account has been successfully created. We've sent you a welcome letter with..."
  redirect_to dashboard_path
else
  ...
end

Fairly typical Rails code. Nothing alarming here, but I wanted to evaluate the call to the mailer in this scenario. When it comes to sending emails from your application, you can choose to do it from the controller as in the example above or in your models. Our team prefers to do this from our model via a callback as we are considering this to be part of our business logic.

Each time a customer is created, we want to send them an email. This can be moved into the model and resembled something like the following..

after_create :send_welcome_message #, other callbacks..

def send_welcome_message
  CustomerMailer.deliver_welcome_message(self)
end

There are a few benefits to doing it this way.

We can test that this is being triggered within our model specs instead of our controller specs. (we prefer to spend more of our time working within models than controllers)
We remove the dependency that all requests must be processed through our controllers.
- Example: We may one day create rake tasks that data and want these emails to still be sent out. (We’ve had to do this a few times)

I definitely don’t think doing this via controllers is a bad idea, I just lean towards keeping controllers as dumbed down as possible. This allows us to have less controller code that is focused on passing data to/from models and letting our models do the heavy lifting.

UPDATE: DHH was kind enough to post a more detailed response on his blog.