To put them in perspective, I think of being on an airplane. The flight attendant comes down the aisle with her food cart and, eventually, parks it beside my seat. “Can I interest you in the chicken?” she asks. “Or would you prefer the platter of shit with bits of broken glass in it?”

To be undecided in this election is to pause for a moment and then ask how the chicken is cooked.

I mean, really, what’s to be confused about?

The 0.2.7 version of Ruby OAuth isn’t totally compatible with the Netflix authentication APIs. However, thanks to the grooviness that it is GitHub, Rob Ares graciously forked the OAuth gem in order to get it working. So clone his repository and get cracking!

Here’s a start:

require "oauth/consumer"
consumer = OAuth::Consumer.new(
      "developer api key",
      "developer api secret",
      {
        :site => "http://api.netflix.com",
        :request_token_url => "https://api-user.netflix.com/oauth/request_token",
        :access_token_url => "http://api.netflix.com/oauth/access_token",
        :authorize_url => "https://api-user.netflix.com/oauth/login"
      })

    request_token = consumer.get_request_token  

 request_token.authorize_url({
      :oauth_consumer_key => "you developer api key",
      :application_name => "application name",
      :oauth_callback => "optional"
    })

    access_token = request_token.get_access_token

    response = consumer.request(
      :get,
      "/users/#{access_token.response[:user_id]}",
      access_token,
      {:scheme => :query_string})

I’ll be posting as I go along, as I’ve been learning quite a bit about the inner workings of DataMapper while going through this process.

Cheers.

Anyway, here’s a synopsis of what I’ve come across thus far. As pointed out in this post by The Merbist, a custom adapter simply inherits from Abstract Adapter and as such, can define a number of default Adapter methods such as create, update, delete, read_one and read_many. You also have access to an initialization method that supplies a hash with important environment information, including any parameters relevant to your adapter that a user may have setup in a database.yml file. This allowed me to create a MailChimp client and login once during class initialization rather than at every request, so I got that going for me.

Once I had a MailChimp client setup with login information, I started getting create working in my adapter. The create method takes a collection of resources as an option which I simply loop through and call the MailChimp listSubscribe API. So far, so good. I now wanted to test whether any of this would work with Merb.

I created a merb app:

 merb-gen app campaign
 cd campaign

and set the :use_orm parameter to datamapper in the Merb init.rb.

Next, I ran rake dm:db:database_yaml in order to generate a database.yml file to specify relevant properties for my adapter. In my case, I needed to create an entry for my mailchimp adapter:

  adapter:  mailchimp
  database:
  username: user
  password: password
  mailing_list_id: list_id
  host: localhost

.

I next created a resource to test the adapter with by running merb-gen resource mailings. My thinking was that one could have a User stored in a relational (or other) datastore, and that User can have many mailings or some such thing, bad naming aside. Anyway, a cool feature of DataMapper is that you can specify any number of repositories in a database.yml with different adapters, and then specify on a resource by resource basis which repository a resource belongs to like so:

 def self.default_repository_name
      :mysql
 end

After generating my resource, I went in to add the properties MailChimp would require for the create method.

class Mailings
  include DataMapper::Resource

  property :id, String, :serial => true, :key => true, :field => :_id
  property :first_name, String
  property :last_name, String
  property :email, String
  property :mailing_list_id, String

   def build_mail_merge()
      {"EMAIL" => self.email, "FNAME" => self.first_name, "LNAME" => self.last_name }
   end
end

.

I also added a callback method that is used by the adapter in order to pass mail merge arguments to MailChimp. This seemed like a sane approach given that the MailChimp mail_merge arguments are quite dynamic.

With a resource firmly in place, I fired up the merb console and tested to see whether I could connect to MailChimp with it.

 m = Mailing.new
 m.first_name = 'mandarin'
 m.last_name = 'soda'
 m.email = 'msoda@disney.com'
 m.mailing_list_id = '9'
 m.create

I checked my disney email, and sure enough, I had an opt-in response from MailChimp. Victory Adapter! I could sign users up to MailChimp via the DataMapper APIs quite quickly….not too shabby.

That’s where I’m at for now…still have some things to iron out, one being that DataMapper is returning false after a successful create. Others, of course being that I need to figure out the rest of the default Adapter methods. Feel free to follow on GitHub if you feel so inclined.

When trying to install the zeep messaging gem recently, sure enough I struggled a bit with getting the syntax correct.

Anyway, without further ado, here is what worked:
config.gem "zeep-messaging", :lib => "zeep/messaging", :version => "0.1.5"

Kinda nice sending SMS messages from the console, I have to admit.

Apache will log to its own log files, as well as handle log rotation, so nothing much to write about there. However, as a good practice, you’ll likely want to rotate your Radiant logs. And for that, you’ll want logrotate.

Logrotate gets its configuration information from /etc/logrotate.conf, so one just needs to open it up and tell it to look at the Radiant logs and rotate them like so:

# Rotate Rails application logs
/path/to/radiant/shared/log/*.log {
daily
missingok
rotate 7
compress
delaycompress
notifempty
copytruncate
}

This will rotate 7 days worth of logs, compress older logs and start a new log file. And it will do it daily. Simple.

Monitoring is a bit more involved, but God makes it fairly easy, and its all in Ruby. According to this helpful site mod_rails monitors its own processes, which leaves us to Monitor Apache, MySQL and any other processes running around. The God site has very good documentation, so I suggest you head over there if you want detailed descriptions of everything it can do. For the sake of this post, I’ll just lead folks to simple Apache and MySQL configurations.

After installing God sudo gem install god --no-ri --no-rdoc, setup a conf.god somewhere sensible and take a look at the posts below, as it probably doesn’t make sense for me to reiterate what others have already admirably accomplished:
Monitoring MySQL and setting up notifications.
Monitoring Apache.

Now I just need to figure out what will monitor God.

My thinking at the time was that a standalone “wrapper” web service made sense. While it would have complicated application administration a bit, encapsulating the mailing list functionality in a simple service that could be called synchronously or asynchronously, as well as modified and deployed independent of core site logic, sounded reasonable.

So, let’s start with building a minimal Merb application to serve as a foundation:
merb-gen app mail_chimp_service --flat

This generates one controller, a few templates (if we want to build in some templated monitoring and for xml responses) and just enough configuration to get the Merb service started.

To test it out, just fire up Merb with the following command: merb and head to http://localhost:4000.

With a foundation in place, I started looking into my MailChimp plugin to see if I should turn it into a gem or do something simpler. I turned to hoe, thinking that making a gem would be interesting, but then decided otherwise, as I basically didn’t feel like writing that much. So instead, I wrote a simple chimp class to do the MailChimp API work:

require 'xmlrpc/client'
class Chimp
  cattr_accessor :client, :auth
  def add(subscriber)
    chimp_subscribe(auth, Merb::Config[:chimp_settings]['mail_chimp']['mailing_list_id'],
                            subscriber.email, subscriber.mail_merge)
  end
  private
  def chimp_subscribe(auth, mailing_list_id, email, merge_vars,
                                email_content_type="html", double_optin=true)
    begin
      client.call("listSubscribe", auth, mailing_list_id, email,
                     merge_vars, email_content_type, double_optin)
    rescue XMLRPC::FaultException => e
      Merb.logger e.faultCode
      Merb.logger e.faultString
    end
  end
end

This class adds users to a specific MailChimp mailing list using the MailChimp APIs. The client and auth attributes are set in the Merb init.rb class, as they really only need to be loaded once and not initialized per each request:

Merb::BootLoader.after_app_loads do
    Chimp.client = XMLRPC::Client.new2('http://api.mailchimp.com/1.0/')
    Chimp.auth = XMLRPC::Client.new2('http://api.mailchimp.com/1.0/').call("login",
                         Merb::Config[:chimp_settings]['mail_chimp']['username'],
                         Merb::Config[:chimp_settings]['mail_chimp']['password'])
end

I’m loading the MailChimp configuration parameters in the init.rb file in the config block. I’m just loading in a yaml file with the relevant information one would presumably want externalized from the application code:

Merb::Config.use { |c|
 .....
 c[:chimp_settings]      = YAML.load_file(Merb.root/'mailing.yml')
}

I then created a simple subscriber.rb class to encapsulate user elements and wired the relevant classes together in my single controller like so:

require 'chimp'
require 'subscriber'
class Foo < Merb::Controller
  provides :xml

  def _template_location(action, type = nil, controller = controller_name)
    controller == "layout" ? "layout.#{action}.#{type}" : "#{action}.#{type}"
  end

  def index
    subscriber = Subscriber.new(params)
    chimp = Chimp.new
    chimp.add(subscriber)
    render false
  end
end

I subsquently added an index.xml.erb class to my views directory in order to render successful responses, fired up my app with the merb command and then ran a test in a separate console to ensure everything was working:

curl -H "Accept: text/xml" -L -d
"email=matt@mandarinsoda.com&first_name=swanky&last_name=mango" http://localhost:4000

It worked - the very first time!  (joking, but it did work after a bit of tinkering). I saw the content of my index.xml.erb and received a MailChimp opt-in email. Not too shabby for a few hours of tinkering. I’m sure there are interesting Merb features missing as well that could make this all the more compact.  More to explore later.