Trypticon: Tag actionmessenger

Action Messenger 0.2.0

Trejkaz — Fri, 23 Mar 2007 20:04:00 +1100

Today’s new version of Action Messenger makes things slightly easier to read when sending messages:

def prod(user)
  recipient user.jid
  subject   'Prod'
  body      'You told me to give you a prod when I updated...'
end

You can send to multiple recipients too, just add them like this:

def spam
  recipients User.find_all.map { |u| u.jid }
  subject    'Buy chunky bacon'
  body       'Do I have a deal for you!'
end

These changes have been in trunk for some time, however someone recently made me aware that the documentation doesn’t describe basic things like where the config file should be. This has been properly documented now, and hence the new version being pushed out.

Directions for Action Messenger

Trejkaz — Mon, 22 May 2006 22:16:00 +1000

Well, the first highly experimental release of Action Messenger experienced a small amount of success, and a couple of people spotted some bugs which have been fixed in version 0.1.1.

So now that everything works for small apps, how does it grow? I do want to integrate into Typo, and the default deployment for Typo uses FastCGI. Whereas each FastCGI process is relatively long-lived, there are multiple instances, and they can’t all be logged in at once [with the same resource.]

So I have a number of options for coping with having Action Messenger work from multiple Rails instances.

Have each instance login from a different resource. This is the simplest approach, and the one which I’m currently using on this site’s Typo install: append the process ID onto the resource when logging in. The main downside to this approach is that when I add presence support in, users who have added the bot would see all its multiple resources logged in at once. Whereas this would start out fairly small (I use 5 instances on my Typo) for larger, more popular sites, you might end up with a few dozen bots online at the same time.
Have one instance of Rails nominate it as the master, and start a DRb server on a background thread. The other instances would connect to the master when they need to send a message. This would be the simplest approach for the end user, but seems difficult to implement. Which server becomes the master? Perhaps an instance simply tries to open a socket to the server, and if it fails, it tries to open a socket as the server. In this fashion, there is always only one instance online, and when that instance goes offline (e.g. the process crashes) another one would pick it up.
Have the Rails app spawn a separate process to handle the server side of things, but otherwise do things exactly as #2.
Use something such as BackgrounDRb to run the bot as one thread of a much more flexible server. This approach is probably the most useful as things other than a Jabber bot might be run in this server, although at the moment I’m not sure what.
Write a simple, specialist Ruby bot, and require that bot to be started completely separately from Rails. The Rails instances would then connect to the bot whenever they need something.

At the moment, #5 is my favourite option. My main problem with this approach is – how will the bot handle receiving messages? Accessing the Rails models directly from the bot isn’t the problem, the problem is coming up with an API just as clean as the current one.

Jabbering with Action Messenger

Trejkaz — Mon, 08 May 2006 23:24:00 +1000

Want to send instant messages from your Ruby on Rails app with the minimum amount of code and the maximum amount of testability?

Then say hello to… Action Messenger

Some time ago, the Typo weblog software introduced a new feature, where notifications of new articles or comments could be delivered via XMPP, or as it’s more commonly known, Jabber. The one catch with the feature was that it depended on the older Jabber4R library, which under certain versions of Ruby, simply failed to work. Jabber4R has serious bugs in there which cause it to deadlock under any newer version of Ruby.

I wanted to use the feature rather badly at the time, so I patched it to use XMPP4R instead. The patch still hasn’t been accepted, allegedly due to a lack of tests. Granted, unit testing is big in the Rails world, but the original Jabber notification code didn’t have unit tests either, so I just see this as an enormous hypocrisy where the developers don’t write their own tests, and think that it’s everyone else’s responsibility to write the tests for them.

So in any case because of this, it’s likely that under the current state of affairs, the existing Jabber support in Typo will remain broken indefinitely.

After all of that, I started thinking about unit testing the Jabber messaging part. The main problem is that a Jabber communication library generally requires a network connection to operate. Whereas this is usually avoided by using mock objects, XMPP4R exposes rather a lot of different classes, and mocking the entire library out is probably just a little unreasonable.

So what you do is write a layer which has less things to mock out, and that’s the basis of Action Messenger. However, I couldn’t stop at merely having this layer for mocking. I had to go and make it possible to send a Jabber message with three trivial lines of code (two in the messenger layer, setting up the recipient and the body, and one in the controller to tell the messenger to send the message.)

So that’s what Action Messenger is. There isn’t much to it right now, but what’s there is heavily unit tested, and has convenience built-in for making your own code which uses it, more testable.

Enjoy, and as always, send complaints this way. :-)