Boosting ActiveRecord Performance

ActiveRecord is arguably one of the best ORM wrappers out there. And as any Rails developer will likely tell you, it’s also the backbone of the entire RoR architecture. Having said that, the flexibility comes with a trade off - you have a intermediary that is responsible for constructing the queries, hiding the database logic, converting data types, and the list goes on. All of the steps consume both time and resources, and while find_by_sql is powerful, it is often not enough. Thankfully, while flipping through ‘Pro Active Record‘ by Kevin Marshall, Chad Pytel and Jon Yurek I stumbled across a useful tip: ActiveRecord exposes a collection of methods which allow us to bypass all of its middleman functions and work with the raw SQL connection directly.

Working with low-level CRUD

If you look at the source of ActiveRecord you’ll quickly realize that all of its functionality boils down to a few simple methods: connection.insert, connection.update, connection.select_all and connection.delete. Issuing statements through any one of these methods requires a full SQL query - ActiveRecord is no longer responsible for verification. Essentially, we are bypassing everything ActiveRecord brings to the table, short of establishing a communications link to the database.

Bypassing ActiveRecord

Let’s establish a standalone connection to a test database and run our CRUD queries:

> ar-raw.rb

require 'active_record'
 
class DBConn < ActiveRecord::Base
  establish_connection(
      :adapter => "mysql",
      :database => "test",
      :username => "user",
      :password => "pass",
      :host => "localhost"
  )
end
 
# Return all documents; do not convert into ActiveRecord objects, keep as a hashmap
docs = DBConn.connection.select_all("select * from documents")
docs.each do |record|
  puts "#{record['id']} :: #{record['title']}"
end
 
# Insert a document
new_id = DBConn.connection.insert("insert into documents(id, group_id, date_added, title, content) values ('5', '1', '2007-10-26 12:00:00', 'Story title', 'Text')")
puts "\nNew document id: #{new_id}"
 
# Update a document
status = DBConn.connection.update("update documents set title = 'New title' where id = 5")
puts "\nUpdate status: #{status}"
 
# Check the updated document
p DBConn.connection.select_all("select * from documents where id = 5")
 
# Delete the update document (returns 0)
status = DBConn.connection.delete("delete from documents where id = 5")
puts "\nDelete status: #{status}\n"
 
# Check the table, once again.
docs = DBConn.connection.select_all("select * from documents")
docs.each do |record|
  puts "#{record['id']} :: #{record['title']}"
end

Executing the above code on a sample MySQL database with four document entries produces:

1 :: test one
2 :: test two
3 :: another doc
4 :: doc number four

New document id: 5

Update status: 1
[{”title”=>”New title”, “group_id”=>”1″, “id”=>”5″, “content”=>”Text”, “date_added”=>”2007-10-26 12:00:00″}]

Delete status: 1

1 :: test one
2 :: test two
3 :: another doc
4 :: doc number four

Working with low level SQL is definitely a lot more involved, but on the upside, it can also provide significant performance increases. If you are moving lots of data, need access to engine specific functions, or going for straight throughput, it’s not something you should overlook. Speed freaks: custom Mongrel handlers with raw ActiveRecord connections!

activerecord, ar, rails, ror, ruby

Pattie Maes on Ambient Intelligence

At OOPSLA 2007, Pattie Maes gave an interesting talk about the MIT ambient intelligence projects. One project, ReachMedia, was particularly interesting from an architectural, mashup and social networking perspective.

Some thoughts on Leopard

Rather than spending time discussing Leopard’s much discussed new major features, I thought it would be interesting to point out some of the smaller, minor but useful updates that I have picked up on so far. I will update this list over the next week or two as I discover new things, good and bad:

• Installation didn’t go too smoothly for me; there appears to be a bug in the install process affecting some machines that means that my hard drive wasn’t showing up in the “Select a destination” panel. Fortunately I was able to find out from the Apple discussion forums that after waiting 10 to 15 minutes your available drives will appear. One cup of tea later, and the install routine was back on track. I opted to perform an “Erase and Install” on my MacBook Pro to get rid of the sheer amount of crap that I had accumulated over the last 18 months which went as smoothly as I’d expected. I am yet to try the upgrade option on my Mac Mini so YMMV here.

• My first impressions were that Leopard seemed faster and given that it was probably hard at work indexing my hard drive for Spotlight this was pretty impressive. My Airport problems in Tiger (the connection would frequently just stop responding or lose packets making it incredibly frustrating to do anything useful) appear to be resolved, at least, when running on mains power. When running on battery I still seem to be suffering from random disconnections although Leopard at least shows that it has lost its connection and reconnects pretty fast. This may be a problem with my router and still requires further investigation on my part.

• The new dock is not as bad as everybody has made out and I have left it at the bottom for now even though I’m traditionally a dock-on-the-side person. The new Stacks functionality is useful and looks great although the cool “fan” effect only works when the dock is on the bottom. I imagine the novelty will wear off quite quickly and I will be back to having my dock on the side soon enough.

• I’m sure that most Rails developers have been aware for a while now that Leopard will ship with Rails. The new Ruby/Rails stack in Leopard is well thought out and organised and comes with Ruby 1.8.6, Rails 1.2.3 and and a host of other useful gems. Rails itself is simply bundled as a gem and is easily updated. A good overview of the changes to Ruby in Leopard is available.

• One utility that anybody who frequently uses SSH and public/private keys would not be without is SSHKeychain which integrates with Apple Keychain and acts as an SSH agent. In my experience SSHKeychain could be flaky and would sometimes silently crash for no apparent reason; good news then because as of Leopard, OSX maintains its own Keychain-integrated ssh-agent making passphrase-protected keys painless to use out of the box.

• Speaking of which, the new Leopard Terminal finally supports tabs and is much easier to customize thanks to built-in themes. Despite some niggles (like not being able to jump to a specific tab using Cmd+number) I think that it is finally time to say goodbye to iTerm.

• Connecting to your mail server over SSL using a self-signed certificate in Mail.app is no longer a pain in the arse. Before, Mail would prompt you that the server certificate was not from a trusted source every time you tried to connect unless you manually dragged the certificate to the desktop and added it to your keychain. In Leopard, Mail finally has an option to “always trust this certificate” as well as a number of other fine-grained trust options.

• The new version of Front Row, based on the Apple TV software, seems like a regression to me. The new interface doesn’t seem as slick and suffers from some annoying bugs like not being able to view album artwork on a shared library and most annoying of all: there doesn’t seem to be any way to get Front Row to open on a second monitor. In Tiger, Front Row would always open on the primary display – this was documented behavior and in Leopard this behavior seems to have disappeared. I like to hook my MBP up to my plasma TV but now Front Row will only open on my MBP screen, even if its not the primary display, severely limiting its usefulness.

• On the plus-side, Quicktime now has some useful full-screen options including options to stretch or fill a widescreen display when viewing videos in a 4:3 aspect ratio. Quicktime does work on a second display and allows you to select which screen it will display on in full-screen mode independently of your primary display settings.

Update 1: Airport Woes

When running in battery mode, Airport performance is horrendous, even after installing the latest keychain fix. The signal will go up and down and the transmit rate will jump up and down wildly between 0 and 54 before eventually just disconnecting – it seems to disconnect every couple of minutes.

The question is, is this a) a continuation of the connection stability problems I was having in Tiger but manifesting itself with different symptoms (or simply that Leopard is more responsive to Airport connection status changes than Tiger), b) an entirely new problem created by the latest Airport drivers, c) a hardware issue (dodgy Airport cards?) or d) a problem with my router.

Until I can test out Airport performance on my Mac Mini in Leopard, I can’t rule out D although the fact that many other people are having the same problem seems to suggests this is not the case. Airport performance seems reliable when connected to the mains, so maybe its an issue of power consumption by the Airport card?

Something else that I just noticed: there appears to be a rather nasty looking, if ultimately harmless, rendering bug when scrolling in Finder when in column mode:

More Airport updates

I’m beginning to become more and more convinced that the problem with Airport is a power issue. My Airport connection seems to be very stable with no disconnections when running on mains power but in battery mode the disconnections come very frequently. I’ve also managed to perform the following test with reliable results: plug in the power adapter and wait a few minutes to confirm a stable Airport connection. Now remove the power adapter – in my observations, about 80% of the time the Airport connection will drop within 10 seconds. This would indicate to me that the problem lies in the Airport card not being able to draw enough power to operate in a stable manner whilst running in battery mode.

Yet another update

I mentioned earlier that I was having trouble getting Front Row to display on my TV even though it was set as the primary monitor. Last night I gave it another try and et voila; Front Row was displaying on my TV. Further investigation led me to this post on the Apple discussion forums:

“Not sure if this is related to the bugs you are having, but one I’ve noticed and reported to apple is this: When you first start front row it appears on your primary display, it also remembers which display it first started on. So, if you exit but don’t kill the front row process (in activity manager), front row will always display on that initial primary monitor, even if you swap your primary/secondary in sys pref. I haven’t tried mirroring the displays. " cmendill, Apple Discussion Board

I haven’t had the change to verify this (yet) but it makes sense – if exiting Front Row doesn’t actually kill the process, then Front Row will not pick up changes to your primary display settings until you do. I still consider this to be a bug but at least it’s an explanation!

Leopard reviews:

• Ars Technica review
• Walt Mossberg’s Wall Street Journal review
• New York Times

Some thoughts on Leopard

In case you missed the memo, Apple unleashed Leopard on Friday. I headed down to the Regent Street Apple Store to see if I could snag a copy; unfortunately, by 6pm the queue had reached epic proportions (at least a 45 minute wait) and I promptly left and instead chose to pick up a copy from Brent Cross on Saturday (I feel sorry for anybody who did bother queueing all evening – the Brent Cross store was no more busy than usual come Saturday afternoon).

Rather than spending time discussing Leopard’s much discussed new major features, I thought it would be interesting to point out some of the smaller, minor but useful updates that I have picked up on so far. I will update this list over the next week or two as I discover new things, good and bad:

• Installation didn’t go too smoothly for me; there appears to be a bug in the install process affecting some machines that means that my hard drive wasn’t showing up in the “Select a destination� panel. Fortunately I was able to find out from the Apple discussion forums that after waiting 10 to 15 minutes your available drives will appear. One cup of tea later, and the install routine was back on track. I opted to perform an “Erase and Install� on my MacBook Pro to get rid of the sheer amount of crap that I had accumulated over the last 18 months which went as smoothly as I’d expected. I am yet to try the upgrade option on my Mac Mini so YMMV here.

• My first impressions were that Leopard seemed faster and given that it was probably hard at work indexing my hard drive for Spotlight this was pretty impressive. My Airport problems in Tiger (the connection would frequently just stop responding or lose packets making it incredibly frustrating to do anything useful) appear to be resolved, at least, when running on mains power. When running on battery I still seem to be suffering from random disconnections although Leopard at least shows that it has lost its connection and reconnects pretty fast. This may be a problem with my router and still requires further investigation on my part.

• The new dock is not as bad as everybody has made out and I have left it at the bottom for now even though I’m traditionally a dock-on-the-side person. The new Stacks functionality is useful and looks great although the cool “fan� effect only works when the dock is on the bottom. I imagine the novelty will wear off quite quickly and I will be back to having my dock on the side soon enough.

• I’m sure that most Rails developers have been aware for a while now that Leopard will ship with Rails. The new Ruby/Rails stack in Leopard is well thought out and organised and comes with Ruby 1.8.6, Rails 1.2.3 and and a host of other useful gems. Rails itself is simply bundled as a gem and is easily updated. A good overview of the changes to Ruby in Leopard is available.

• One utility that anybody who frequently uses SSH and public/private keys would not be without is SSHKeychain which integrates with Apple Keychain and acts as an SSH agent. In my experience SSHKeychain could be flaky and would sometimes silently crash for no apparent reason; good news then because as of Leopard, OSX maintains its own Keychain-integrated ssh-agent making passphrase-protected keys painless to use out of the box.

• Speaking of which, the new Leopard Terminal finally supports tabs and is much easier to customize thanks to built-in themes. Despite some niggles (like not being able to jump to a specific tab using Cmd+number) I think that it is finally time to say goodbye to iTerm.

• Connecting to your mail server over SSL using a self-signed certificate in Mail.app is no longer a pain in the arse. Before, Mail would prompt you that the server certificate was not from a trusted source every time you tried to connect unless you manually dragged the certificate to the desktop and added it to your keychain. In Leopard, Mail finally has an option to “always trust this certificate� as well as a number of other fine-grained trust options.

• The new version of Front Row, based on the Apple TV software, seems like a regression to me. The new interface doesn’t seem as slick and suffers from some annoying bugs like not being able to view album artwork on a shared library and most annoying of all: there doesn’t seem to be any way to get Front Row to open on a second monitor. In Tiger, Front Row would always open on the primary display – this was documented behavior and in Leopard this behavior seems to have disappeared. I like to hook my MBP up to my plasma TV but now Front Row will only open on my MBP screen, even if its not the primary display, severely limiting its usefulness.

• On the plus-side, Quicktime now has some useful full-screen options including options to stretch or fill a widescreen display when viewing videos in a 4:3 aspect ratio. Quicktime does work on a second display and allows you to select which screen it will display on in full-screen mode independently of your primary display settings.

Update 1: Airport Woes

When running in battery mode, Airport performance is horrendous, even after installing the latest keychain fix. The signal will go up and down and the transmit rate will jump up and down wildly between 0 and 54 before eventually just disconnecting – it seems to disconnect every couple of minutes.

The question is, is this a) a continuation of the connection stability problems I was having in Tiger but manifesting itself with different symptoms (or simply that Leopard is more responsive to Airport connection status changes than Tiger), b) an entirely new problem created by the latest Airport drivers, c) a hardware issue (dodgy Airport cards?) or d) a problem with my router.

Until I can test out Airport performance on my Mac Mini in Leopard, I can’t rule out D although the fact that many other people are having the same problem seems to suggests this is not the case. Airport performance seems reliable when connected to the mains, so maybe its an issue of power consumption by the Airport card?

Something else that I just noticed: there appears to be a rather nasty looking, if ultimately harmless, rendering bug when scrolling in Finder when in column mode:

More Airport updates

I’m beginning to become more and more convinced that the problem with Airport is a power issue. My Airport connection seems to be very stable with no disconnections when running on mains power but in battery mode the disconnections come very frequently. I’ve also managed to perform the following test with reliable results: plug in the power adapter and wait a few minutes to confirm a stable Airport connection. Now remove the power adapter – in my observations, about 80% of the time the Airport connection will drop within 10 seconds. This would indicate to me that the problem lies in the Airport card not being able to draw enough power to operate in a stable manner whilst running in battery mode.

Yet another update

I mentioned earlier that I was having trouble getting Front Row to display on my TV even though it was set as the primary monitor. Last night I gave it another try and et voila; Front Row was displaying on my TV. Further investigation led me to this post on the Apple discussion forums:

“Not sure if this is related to the bugs you are having, but one I’ve noticed and reported to apple is this: When you first start front row it appears on your primary display, it also remembers which display it first started on. So, if you exit but don’t kill the front row process (in activity manager), front row will always display on that initial primary monitor, even if you swap your primary/secondary in sys pref. I haven’t tried mirroring the displays. � cmendill, Apple Discussion Board

I haven’t had the change to verify this (yet) but it makes sense – if exiting Front Row doesn’t actually kill the process, then Front Row will not pick up changes to your primary display settings until you do. I still consider this to be a bug but at least it’s an explanation!

Leopard reviews:

• Ars Technica review
• Walt Mossberg’s Wall Street Journal review
• New York Times

Some thoughts on Leopard

In case you missed the memo, Apple unleashed Leopard on Friday. I headed down to the Regent Street Apple Store to see if I could snag a copy; unfortunately, by 6pm the queue had reached epic proportions (at least a 45 minute wait) and I promptly left and instead chose to pick up a copy from Brent Cross on Saturday (I feel sorry for anybody who did bother queueing all evening – the Brent Cross store was no more busy than usual come Saturday afternoon).

Rather than spending time discussing Leopard’s much discussed new major features, I thought it would be interesting to point out some of the smaller, minor but useful updates that I have picked up on so far. I will update this list over the next week or two as I discover new things, good and bad:

• Installation didn’t go too smoothly for me; there appears to be a bug in the install process affecting some machines that means that my hard drive wasn’t showing up in the “Select a destination” panel. Fortunately I was able to find out from the Apple discussion forums that after waiting 10 to 15 minutes your available drives will appear. One cup of tea later, and the install routine was back on track. I opted to perform an “Erase and Install” on my MacBook Pro to get rid of the sheer amount of crap that I had accumulated over the last 18 months which went as smoothly as I’d expected. I am yet to try the upgrade option on my Mac Mini so YMMV here.

• My first impressions were that Leopard seemed faster and given that it was probably hard at work indexing my hard drive for Spotlight this was pretty impressive. My Airport problems in Tiger (the connection would frequently just stop responding or lose packets making it incredibly frustrating to do anything useful) appear to be resolved, at least, when running on mains power. When running on battery I still seem to be suffering from random disconnections although Leopard at least shows that it has lost its connection and reconnects pretty fast. This may be a problem with my router and still requires further investigation on my part.

• The new dock is not as bad as everybody has made out and I have left it at the bottom for now even though I’m traditionally a dock-on-the-side person. The new Stacks functionality is useful and looks great although the cool “fan” effect only works when the dock is on the bottom. I imagine the novelty will wear off quite quickly and I will be back to having my dock on the side soon enough.

• I’m sure that most Rails developers have been aware for a while now that Leopard will ship with Rails. The new Ruby/Rails stack in Leopard is well thought out and organised and comes with Ruby 1.8.6, Rails 1.2.3 and and a host of other useful gems. Rails itself is simply bundled as a gem and is easily updated. A good overview of the changes to Ruby in Leopard is available.

• One utility that anybody who frequently uses SSH and public/private keys would not be without is SSHKeychain which integrates with Apple Keychain and acts as an SSH agent. In my experience SSHKeychain could be flaky and would sometimes silently crash for no apparent reason; good news then because as of Leopard, OSX maintains its own Keychain-integrated ssh-agent making passphrase-protected keys painless to use out of the box.

• Speaking of which, the new Leopard Terminal finally supports tabs and is much easier to customize thanks to built-in themes. Despite some niggles (like not being able to jump to a specific tab using Cmd+number) I think that it is finally time to say goodbye to iTerm.

• Connecting to your mail server over SSL using a self-signed certificate in Mail.app is no longer a pain in the arse. Before, Mail would prompt you that the server certificate was not from a trusted source every time you tried to connect unless you manually dragged the certificate to the desktop and added it to your keychain. In Leopard, Mail finally has an option to “always trust this certificate” as well as a number of other fine-grained trust options.

• The new version of Front Row, based on the Apple TV software, seems like a regression to me. The new interface doesn’t seem as slick and suffers from some annoying bugs like not being able to view album artwork on a shared library and most annoying of all: there doesn’t seem to be any way to get Front Row to open on a second monitor. In Tiger, Front Row would always open on the primary display – this was documented behavior and in Leopard this behavior seems to have disappeared. I like to hook my MBP up to my plasma TV but now Front Row will only open on my MBP screen, even if its not the primary display, severely limiting its usefulness.

• On the plus-side, Quicktime now has some useful full-screen options including options to stretch or fill a widescreen display when viewing videos in a 4:3 aspect ratio. Quicktime does work on a second display and allows you to select which screen it will display on in full-screen mode independently of your primary display settings.

Leopard reviews:

• Ars Technica review
• Walt Mossberg’s Wall Street Journal review
• New York Times

Some thoughts on Leopard

In case you missed the memo, Apple unleashed Leopard on Friday. I headed down to the Regent Street Apple Store to see if I could snag a copy; unfortunately, by 6pm the queue had reached epic proportions (at least a 45 minute wait) and I promptly left and instead chose to pick up a copy from Brent Cross on Saturday (I feel sorry for anybody who did bother queueing all evening – the Brent Cross store was no more busy than usual come Saturday afternoon).

Rather than spending time discussing Leopard’s much discussed new major features, I thought it would be interesting to point out some of the smaller, minor but useful updates that I have picked up on so far. I will update this list over the next week or two as I discover new things, good and bad:

• Installation didn’t go too smoothly for me; there appears to be a bug in the install process affecting some machines that means that my hard drive wasn’t showing up in the “Select a destination” panel. Fortunately I was able to find out from the Apple discussion forums that after waiting 10 to 15 minutes your available drives will appear. One cup of tea later, and the install routine was back on track. I opted to perform an “Erase and Install” on my MacBook Pro to get rid of the sheer amount of crap that I had accumulated over the last 18 months which went as smoothly as I’d expected. I am yet to try the upgrade option on my Mac Mini so YMMV here.

• My first impressions were that Leopard seemed faster and given that it was probably hard at work indexing my hard drive for Spotlight this was pretty impressive. My Airport problems in Tiger (the connection would frequently just stop responding or lose packets making it incredibly frustrating to do anything useful) appear to be resolved, at least, when running on mains power. When running on battery I still seem to be suffering from random disconnections although Leopard at least shows that it has lost its connection and reconnects pretty fast. This may be a problem with my router and still requires further investigation on my part.

• The new dock is not as bad as everybody has made out and I have left it at the bottom for now even though I’m traditionally a dock-on-the-side person. The new Stacks functionality is useful and looks great although the cool “fan” effect only works when the dock is on the bottom. I imagine the novelty will wear off quite quickly and I will be back to having my dock on the side soon enough.

• I’m sure that most Rails developers have been aware for a while now that Leopard will ship with Rails. The new Ruby/Rails stack in Leopard is well thought out and organised and comes with Ruby 1.8.6, Rails 1.2.3 and and a host of other useful gems. Rails itself is simply bundled as a gem and is easily updated. A good overview of the changes to Ruby in Leopard is available.

• One utility that anybody who frequently uses SSH and public/private keys would not be without is SSHKeychain which integrates with Apple Keychain and acts as an SSH agent. In my experience SSHKeychain could be flaky and would sometimes silently crash for no apparent reason; good news then because as of Leopard, OSX maintains its own Keychain-integrated ssh-agent making passphrase-protected keys painless to use out of the box.

• Speaking of which, the new Leopard Terminal finally supports tabs and is much easier to customize thanks to built-in themes. Despite some niggles (like not being able to jump to a specific tab using Cmd+number) I think that it is finally time to say goodbye to iTerm.

• Connecting to your mail server over SSL using a self-signed certificate in Mail.app is no longer a pain in the arse. Before, Mail would prompt you that the server certificate was not from a trusted source every time you tried to connect unless you manually dragged the certificate to the desktop and added it to your keychain. In Leopard, Mail finally has an option to “always trust this certificate” as well as a number of other fine-grained trust options.

• The new version of Front Row, based on the Apple TV software, seems like a regression to me. The new interface doesn’t seem as slick and suffers from some annoying bugs like not being able to view album artwork on a shared library and most annoying of all: there doesn’t seem to be any way to get Front Row to open on a second monitor. In Tiger, Front Row would always open on the primary display – this was documented behavior and in Leopard this behavior seems to have disappeared. I like to hook my MBP up to my plasma TV but now Front Row will only open on my MBP screen, even if its not the primary display, severely limiting its usefulness.

• On the plus-side, Quicktime now has some useful full-screen options including options to stretch or fill a widescreen display when viewing videos in a 4:3 aspect ratio. Quicktime does work on a second display and allows you to select which screen it will display on in full-screen mode independently of your primary display settings.

Update 1: Airport Woes

When running in battery mode, Airport performance is horrendous, even after installing the latest keychain fix. The signal will go up and down and the transmit rate will jump up and down wildly between 0 and 54 before eventually just disconnecting – it seems to disconnect every couple of minutes.

The question is, is this a) a continuation of the connection stability problems I was having in Tiger but manifesting itself with different symptoms (or simply that Leopard is more responsive to Airport connection status changes than Tiger), b) an entirely new problem created by the latest Airport drivers, c) a hardware issue (dodgy Airport cards?) or d) a problem with my router.

Until I can test out Airport performance on my Mac Mini in Leopard, I can’t rule out D although the fact that many other people are having the same problem seems to suggests this is not the case. Airport performance seems reliable when connected to the mains, so maybe its an issue of power consumption by the Airport card?

Something else that I just noticed: there appears to be a rather nasty looking, if ultimately harmless, rendering bug when scrolling in Finder when in column mode:

More Airport updates

I’m beginning to become more and more convinced that the problem with Airport is a power issue. My Airport connection seems to be very stable with no disconnections when running on mains power but in battery mode the disconnections come very frequently. I’ve also managed to perform the following test with reliable results: plug in the power adapter and wait a few minutes to confirm a stable Airport connection. Now remove the power adapter – in my observations, about 80% of the time the Airport connection will drop within 10 seconds. This would indicate to me that the problem lies in the Airport card not being able to draw enough power to operate in a stable manner whilst running in battery mode.

Yet another update

I mentioned earlier that I was having trouble getting Front Row to display on my TV even though it was set as the primary monitor. Last night I gave it another try and et voila; Front Row was displaying on my TV. Further investigation led me to this post on the Apple discussion forums:

“Not sure if this is related to the bugs you are having, but one I’ve noticed and reported to apple is this: When you first start front row it appears on your primary display, it also remembers which display it first started on. So, if you exit but don’t kill the front row process (in activity manager), front row will always display on that initial primary monitor, even if you swap your primary/secondary in sys pref. I haven’t tried mirroring the displays. ” cmendill, Apple Discussion Board

I haven’t had the change to verify this (yet) but it makes sense – if exiting Front Row doesn’t actually kill the process, then Front Row will not pick up changes to your primary display settings until you do. I still consider this to be a bug but at least it’s an explanation!

Leopard reviews:

• Ars Technica review
• Walt Mossberg’s Wall Street Journal review
• New York Times

Mozilla Labs’ announces Prism

On Friday, Mozilla Labs’ announced Prism, their entry into the budding market-trend of platforms for running web applications on the desktop, similar to Adobe AIR.

Jay Fields and Zak Tamsen on Domain Specific Languages

Jay Fields and Zak Tamsen talked with InfoQ about Domain Specific Languages (DSLs), and how they have successfully used them in their projects at ThoughtWorks to empower businesses, reduce development time, and increase the agility of projects.

Trying Out wmii

Wow, I’ve been busy. I just had my math midterm, not to mention the first rehearsal for the play I’m directing.

I did manage to find time on Friday to go on a little adventure, though. Ever since I moved to Linux, I’ve been finding more and more that I like a certain kind of tool. Emacs, for example. It may be complicated and have a steep learning curve, but the power it offers is almost unparalleled.

LaTeX, too. Sure it was kind of a pain to learn, but my math is so beautiful. And it’s so easy to write, now that I (mostly) know how.

I’ll save the rest of my lecture on UI for another post, but suffice it to say that I seem to like tools that have a steep learning curve but are very worth it in terms of power and productivity. Tools that aren’t built for everyone.

I was thinking about this last Friday. And I was thinking about window managers.

I had been using Compiz Fusion for a while, but my computer kept crashing. So I switched back to Metacity, the default, if boring window manager for Gnome.

As I was eliciting pity from a friend who had Compiz working flawlessly, it hit me. Now that I was no longer bound by the golden chain of eye candy, I had a great opportunity to try out a new, interesting window manager.

wmii

I decided to give wmii a go. This was mostly because it was the first thing that came to mind when I thought “interesting window manager.” I think _why uses it, and he seems to be a pretty good judge of what’s interesting.

So what makes for an “interesting” window manager? All I was really looking for was something like what I’d found in Emacs and LaTeX. I wanted a window manager that was powerful, extensible, and usable in that certain hard-to-define seemingly-unusable way.

I also wanted something distinctly different than the previous window managers I’d used. Metacity, Compiz, even whatever the Windows and OSX window managers are called - they’re all based on the same paradigm of “floating boxes that you move and squish.” I wanted something with a totally different paradigm.

wmii certainly fit that bill. It has several interesting features that seem terribly revolutionary to me. Now, I know there are plenty of other window managers out there with similar featuresets. Much of what I find amazing about wmii isn’t actually innovation on the part of the devs (although some of it certainly is). But for me, coming from the insular world of “normal” managers, it’s all mind-blowing.

Dynamic Window Management

One thing wmii shares with some other window managers (although none I’ve used) is that it’s “dynamic.” This means that it actually manages your windows. With Metacity, you have to move all the windows around on your own, resize them, place them just so. wmii does that for you.

When you first start wmii, it just gives you an empty screen with a status bar. As you open applications, it evenly distributes them so that they’re all as wide as the screen and their combined height fills up the entire screen.

You can then pull applications into new columns, so that you might have a stack of three terminals on one half of the screen and one tall Emacs instance on the other. wmii makes sure it’s all organized and sized properly. All you have to do is guide it.

Tagging

A second incredibly cool thing about wmii is that it allows you to tag windows. This is in lieu of a conception of workspaces or minimized applications that other window managers have.

The basic idea is incredibly simple. You can give each window one or more alphanumeric tags. At any given time, you’re displaying all (and only) the windows with a given tag.

Incredibly simple. But also incredibly powerful.

For instance, I like to use tags to divide up my tasks. As I type this, I’m viewing my “blog” tag. I have two apps tagged as “blog:” Emacs for creating the thing, and Firefox for looking up various minutiae and links. Only those two apps are visible right now.

I also have a “hw” tag for doing my math homework. I have Emacs tagged as “hw,” for writing LaTeX, and two Evince windows, one for viewing my compiled LaTeX, and one for viewing the assignment.

Then I have a “prog” tag for programming. This again has Emacs, as well as two terminals. I also have various other tags for various things.

Note that these are all actually the same Emacs instance. It just has three tags, so I can view it in three places. I can even organize it in different ways in the various different views. It could be next to the terminals in “prog” but above Firefox in “blog.”

Scripting

The third really cool thing about wmii is its scripting interface. It’s in the style of Plan 9, a style which I had not previously encountered. It’s based on a concept of files being a metaphor for everything, which is rooted in Unixy stuff like /dev/stdin and sockets and suchlike.

So for wmii, everything is a file or folder. The virtual filesystem is accessed via the wmiir command, using wmiir read <filename> or wmiir write <filename>, which operate on standard input and output, respectively.

For example, the folder representing the selected window is /client/sel. To set the tags on that window to “foo” and “bar”, all you need to do is run

echo "foo+bar" | wmiir write /client/sel/tags

Everything about wmii is accessible through this virtual filesystem. Beats DBus by a longshot.

Installation

Installing wmiir is quite simple. It’s packaged by Ubuntu, so all I had to do was run sudo apt-get install wmii. It has a very simple build process, too, though, so just downloading the source and running make and sudo make install should work for non-Ubuntu folks.

Actually getting it to run is a bit more difficult. You actually have to (gasp!) edit a file. Just open up ~/.xsession and add exec wmii to the top.

If you don’t have an xsession file, just create a new one. Be sure to add an sh-shebang, #!/bin/sh, at the top. I’m not sure this is actually important, but better safe than sorry.

Once that’s set up, all you have to do is restart. wmii should start instead of, say, Metacity.

Now, the first thing I noticed when I started up wmii was that all my Gnome settings – most noticeably, my window theme – were gone. Luckily, this was easy to fix. Just run gnome-settings-manager and all should be well. You can even add gnome-settings-manager & to your .xsession to have it run automatically.

I also wanted to talk about my personal configuration of wmii, but it’s late, I’m tired, and when I’m tired I don’t write well. So I’ll call it quits for now and continue this some other time.

Breakage in Leopard - RMagick fails to find libdpstk.1.dylib

Some small breakage in Leopard - it seems a couple of parts of X11 have been removed. Starting my rails setup, which has GraphicsMagick installed (read here for how), results in this:

dyld: NSLinkModule() error
dyld: Library not loaded: /usr/X11R6/lib/libdpstk.1.dylib
  Referenced from: /usr/local/lib/ruby/gems/1.8/gems/rmagick-1.15.9/lib/RMagick.bundle
  Reason: image not found
Trace/BPT trap

Those dylib files do not exist any more. But… I have a backup (I hope you do). I ended up doing this:

$ cd /Volumes/BackupDisk/usr/X11R6/lib
$ sudo cp libdps*1.0* /usr/X11R6/lib/
$ sudo ln -s /usr/X11R6/lib/libdpstk.1.0.dylib /usr/X11R6/lib/libdpstk.1.dylib
$ sudo ln -s /usr/X11R6/lib/libdps.1.0.dylib /usr/X11R6/lib/libdps.1.dylib

All fixed.

Without a backup you are going to need to find those two files from somewhere. I’m not sure I can legally post them here, but email me if you are stuck.