entries in blog for 2007/10

Getting ActiveRecord objects by ID

02 October 2007 in blog
tagged with [optimization] [rails] [ruby] (edit)

I’m trying to speed up a rails app here, and I’ve been making some assumptions that I’ve realised may not actually be true.

Specifically, if I have a list of IDs, I’ve been assuming that

list_of_ids.map{|id| Model.find(id) }

is going to be slower than

Model.find( list_of_ids )

Presumably, the latter will only make one SQL call to fetch all the objects, but the former will make a call per ID. This is because I’m used to perl, where the ORMs are stupid, the language is fast, and the DB is always the bottleneck.

But the sort of SQL produced by the supposedly slower approach is much more cacheable. The supposedly faster approach will tend to generate a different SQL query every time, whereas a sufficiently smart cache layer could intercept the SQL calls of the later approach and just hand back the models.

Initial benchmarking seems to have the one-SQL-call approach faster anyway. It does turn out to have a disadvantage, though - Model.find( ids ) doesn’t return objects in the same order that the IDs were in, whereas the map approach does. That’s fairly easy to fix, though:

class ActiveRecord::Base
  class << self
    def find_in_order( ids )
      # return all instances with the passed ids, in the order that the ids are in
      objects = self.find( ids )
      objects = objects.sort_by{|o|ids.index(o.id)}
      return objects
    end
  end
end

Running a Jabber server under Debian with eJabberd

11 October 2007 in blog
tagged with [debian] [jabber] [server] (edit)

I like to run my own jabber server, so that I can be contacted as tom@jerakeen.org. Also, I’m a sucker for punishment. I’ve run serveral different Jabber servers over the last year or so, and yesterday I started toying with ejabberd. It was probably the easiest to set up of any of the servers I’ve tried, and I recommend it.

I’m running Debian etch, and installing the daemon was a matter of:

sudo apt-get install ejabberd

Once installed, edit /etc/ejabberd/ejabberd.cfg. A ‘%’ at the beginning of a line is a comment, and lines finish with a ‘.’ character. This config file is read only once, and the settings are put into the ejabbed server database on startup. Unfortunately, that’s probably already happened, so uncomment the override_acls. directive - this makes the server re-read the ACL settings from this file on next startup.

I’ll assume that you own the ‘example.com’ domain and want the JID ‘user@example.com’. Uncomment the line below ‘%% Admin user’. It wants to be something like

%% Admin user
{acl, admin, {user, "user", "example.com"}}.

Change the line below ‘%% Hostname’ to set the hostname of the server:

%% Hostname
{hosts, ["example.com"]}.

You may want to look through the rest of the settings. But don’t bother, they’re all very boring. Now restart the server, to pick up the new settings:

sudo ejabberdctl restart

ejabberdctl can also register your admin / jabber user if you’ve turned off anonymous registration:

sudo ejabberdctl register user example.com <password>

Right, you’re done. Assuming that the DNS A record for example.com resolves to the machine you’ve been playing with (it doesn’t have to, see below), you now have a Jabber server with an admin user. You can visit http://example.com:5280/ to administer your server, but there’s not a huge amount to do there.

DNS SRV records

If the A record for example.com doesn’t resolve to your server you can still run a server for example.com by pointing DNS SRV records to your server. In fact, you should do this anyway, in the same way that your email will arrive if the A record for your domain points to the mail server, but MX records are still a good idea.

Assuming your Jabber server runs on a machine called jabber.example.com, you’ll want the following scary DNS records:

_xmpp-client._tcp 900 IN SRV 5 0 5222 jabber.example.com.
_xmpp-server._tcp 900 IN SRV 5 0 5269 jabber.example.com.
_jabber._tcp      900 IN SRV 5 0 5269 jabber.example.com.

You can check that they’re been set properly using this excellent tool (dead now, sigh), but it’ll probably take a while for the DNS updates to propagate. If you have the dig command line tool, you can also try

dig -t srv _xmpp-client._tcp.example.com

to ask your local DNS server for one of the SRV records.

Alternatives

You don’t have to use ejabberd. Viable alternatives are:

djabberd - lovely if you know Perl and want to extend/hack on a Jabber server. Unfortunately it’s somewhat tricky to configure out of the box, isn’t in Debian, and needs various things checked out from subversion repositories if you want to do esoteric things like preserve your friends roster across daemon restarts or have messages queued when you’re offline.
jabberd - I really don’t want to trust an internet server written in C any more. It was the original/first Jabber server, if this makes you approve of it more.
Not running your own Jabber server - Very worth considering. Unlike running your own mail server or web server, it’s very hard to change your mind later and have someone else host it. I know of very few 3rd party Jabber hosting providers. Yet. Running your own server is purely a vanity thing, but hosting your own email domain used to be a vanity thing too. However, one company that will host your Jabber server for you is..
Google apps for your domain - One of the apps Google provide is a chat (Jabber) server. You can ignore everything else they do and just use the Jabber server part, assuming you have enough DNS access to your domain to point the SRV records to it.

Irritating 2038 Ruby / Rails behaviour

17 October 2007 in blog
tagged with [bug] [rails] [ruby] (edit)

In a rails console:

>> (Time.now + 30.years).class
=> Time
>> (Time.now + 31.years).class
=> DateTime
>> (Time.now + 30.years).to_s
=> "Sat Oct 17 17:27:11 +0100 2037"
>> (Time.now + 31.years).to_s
=> "2038-10-17T17:27:13+01:00"

Time objects after about August 2028 can’t be expressed internally as ‘UNIX epoch (1st January 1970) plus N seconds’ where N is a 32 bit integer. Once a Time object tries to express a date after this point, it gets silently converted to a DateTime object, which presumably uses a different internal representation. It also stringifies differently, has different methods, and is just generally annoying behaviour.

When you have dates in a MySQL database, and use ActiveRecord, DATETIME columns come out of the table as either a Time or a DateTime object depending on what the expressed date is. Lovely. This bug indicates that dates before 1970 behave similarly (they can’t be expressed as unsigned epoch times either).

This is apparently desired behaviour.

Update: Apparently, DateTime objects are also much slower than Date objects.

Leopard-only Flame build

31 October 2007 in blog
tagged with [flame] [pyobjc] [python] (edit)

I have Leopard now, which includes, amongst other things, Python 2.5.1 and PyObjC built-in. Because of this, I’ve been able to package Flame as a much smaller application - 70k compressed rather than 3 megabytes. But it’ll only work on Leopard. So far, I haven’t been able to use Leopard to build a version of Flame that’ll run on Tiger (10.4), but I’m sure I’ll figure it out eventually.

jerakeen.org