Jakub Kuźma - Articles

Using ActionMailer for internal messaging

2009-11-14T19:28:00Z

Rendering internal messages inline can be quite confusing, especially if you want to use some helpers inside (like path helpers). It’d be more convenient to render them in the same way as other messages – using ActionMailer and ERB templates. My solution uses email addresses to figure out the message recipients:

class UserNotifier < ActionMailer::Base
  # sample message
  def some_message(user)
    from %Q{"Internal Messaging System"}
    recipients user.email
    subject "This is internal message"
    body :user => user
  end

  # sample message notification
  def message_notification(message)
    from %Q{"MyAppName.com mailer"}
    recipients message.recipient.email
    subject "You've new message in your inbox"
    body :user => user
  end

  private

  # if the called method has "deliver_internal_"
  # prefix, use notify method to deliver message
  def self.method_missing(method_name, *args)
    if method_name.to_s =~ /^deliver_internal_([_a-z]\w*)/
      new($1, *args).send(:deliver_internal)
    else
      super
    end
  end

  # deliver message to user using internal messaging
  def deliver_internal
    users = User.find_all_by_email(@mail.to)
    from = @mail.from.first[1..-2] # remove quotes
    users.each do |user|
      Message.create!(:recipient => user,
                      :subject => @mail.subject,
                      :body => @mail.body,
                      :sender_name => from)
    end
  end
end

Additionally you can notify the user about a new message, by implementing a simple callback in the Message model.

class Message < ActiveRecord::Base
  after_create :deliver_notification
  belongs_to :recipient, :class_name => "User"

  private

  def deliver_notification
    # deliver message notification email (external)
    # if the user wants it
    if recipient.wants_message_notifications?
      UserNotifier.deliver_message_notification(self)
    end
  end
end

There’s a really good point of this solution – you don’t need to create separate actions for external and internal messaging. The only difference is the method’s prefix:

# send message and notify by email if user wants it
UserNotifier.deliver_internal_some_message(user)
# send email only
UserNotifier.deliver_some_message(user)

Ruby and Rails on Ubuntu 9.10 Karmic Koala

2009-11-10T08:46:00Z

Ruby Version Manager is a really powerful tool which provides an easy, non obtrusive way to install multiple versions of Ruby, Rails and other gems on your Ubuntu 9.10 box. You won’t have to compile anything manually (RVM does a great job) and everything will be kept in your home directory. All you need to do is:

sudo apt-get install ruby rubygems libssl-dev libreadline-dev zlib1g-dev libsqlite3-dev curl

sudo gem install rvm

/var/lib/gems/1.8/bin/rvm-install

Last step modifies your ~/.bashrc (or ~/.zshrc), so the changes will be visible in all new terminal instances. After restarting your terminal, pick a Ruby version to install:

rvm install 1.9.1

After a couple of minutes you’ll have a fully functional Ruby 1.9.1 interpreter installed in your ~/.rvm directory. If you want to use it as a default Ruby, type:

rvm use 1.9.1 --default

Now you can install Rails and other stuff – remember to not use sudo to do that (since everything is kept locally in your home directory, RVM manages your PATH environment variable as well):

gem install rails

For more information about Ruby Version Manager, visit the RVM’s homepage.

Patching Rails and gems locally

2009-10-21T21:08:00Z

How many times did you have to wait ages until a patch that you’ve submitted gets merged into the Rails or a gem? Sometimes you can’t wait, it’s confusing to keep external libraries in your repository. Fortunatelly – Rails provides a simple way to unpack dependencies into vendor directory, where it’s possible to make local changes. Instead of tracking whole vendor, you can have small .patch files in a separate directory and apply them to frozen vendor stuff. You won’t need to remember which gems are locally modified, repository stays small, patches can be easily applied on your remote production server by invoking rake tasks (you can use Capistrano as well). All you need is a simple Rake task:

namespace :patch do
  desc "Applies patches to Rails frozen in vendor"
  task :rails do
    rails_dir = Rails.root.join("vendor", "rails")
    Rails.root.join("patch", "rails").children.each do |patch|
      patch(patch, rails_dir)
    end
  end

  desc "Applies patches to gems frozen in vendor"
  task :gems do
    Rails.root.join("patch", "gems").children.each do |patch_dir|
      patch_dir.children.each do |patch|
        gem_dir = Rails.root.join("vendor", "gems", patch_dir.basename)
        patch(patch, gem_dir)
      end
    end
  end

  desc "Applies patches to Rails and gems in vendor"
  task :all => ["gems", "rails"]
end

def patch(patch, dir)
  puts "Applying patch #{patch.basename} to #{dir.basename}"
  sh "patch -N -p 1 -d #{dir} -i #{patch}"
end

Freeze your Rails and/or gems using rake rails:freeze:gems and rake gems:unpack. You have to store your patches as shown below. Notice that gem’s patches directories must include the version number (just like in vendor/gems).

To apply the patches run rake patch:gems or rake patch:rails task (rake patch:all). Don’t forget to add vendor/rails and vendor/gems to your .gitignore.