Ricardo Martins

Extending Alfred.app with Applescript

2010-04-15T00:00:00+01:00

EDIT: This post has been obsoleted by Alfred 0.6.1. :)

Lately, I’ve been using Alfred.app as my application launcher. I used to use Quicksilver, the grandfather of OSX app launchers but changed to Google Quick Search Box, since Quicksilver had some problems (namely with Snow Leopard and Spaces). However, Google QSB proved to be a little too slow for my taste, and Alfred showed up in Hacker News, so I gave it a shot. Couldn’t have been happier with my choice, even though it’s still in an early stage of development.

I still missed in Alfred something Google QSB had: easily accessible system actions, like sleep, shut down, restart and lock screen. I like to avoid using the mouse whenever I can.

This wasn’t a problem. I took a look at the applescript Google QSB uses internally¹ and created standalone apps based on each action, using Google QSB’s icons².

I’m quite pleased with the result, since I got my beloved actions back and Alfred.app is still snappy.

Sleep

tell application "System Events" to sleep

Shutdown

tell application "System Events" to shut down

Restart

tell application "System Events" to restart

Lock Screen

do shell script "'/System/Library/CoreServices/Menu Extras/User.menu/Contents/Resources/CGSession' -suspend > /dev/null"

¹ /Applications/Quick Search Box.app/Contents/PlugIns/System.hgs/Contents/Resources/Scripts/main.scpt

² /Applications/Quick Search Box.app/Contents/PlugIns/System.hgs/Contents/Resources/

Snow Leopard calculates disk space in base 10

2009-09-01T00:00:00+01:00

Among the many under the hood improvements included in the latest OSX version (10.6 – Snow Leopard, for those who've been under a rock the last few months), there's an unexpected and unpleasant (at least for me) surprise: now Finder uses base 10 to calculate disk and file sizes, instead of the base 2 de facto standard.

Apparently, the motive behind this is to avoid the consumers feeling cheated when they buy an allegedly 1TB hard drive and find out it really is a ~~953GB~~ 931GB drive. Meanwhile, the RAM size is still reported according to the supposedly old and deprecated base 2 representation. I love consistency.

This all stems from one very simple fact: hard drive manufacturers have been maliciously marketing their hard drives' capacities in base 10 since the 90's, since it's more profitable to sell a 100 × 10⁹ byte hard drive as a 100GB drive instead of a 100 × 2³⁰ byte drive, since the latter would be more expensive to manufacture.

It wasn't always like this, hard drives from respectable manufacturers used to have the announced capacity, but someone saw an opportunity to profit more by selling less and took it. The other manufacturers had to do the same in order to remain competitive.

Since Apple yielded to the IEC standard (base 10), we're bound to find many inconsistencies in the reported size of files and disks across operating systems, leading to more confusion. Notice the change is only in Finder, none of the other applications do this. We should be able to choose the preferred representation.

Thank you, Apple, nice job breaking it.

Now with 70% less fat!

2009-08-11T00:00:00+01:00

For the last few days, I’ve been optimising this blog in order to have it load faster. Why? A site that loads fast is a good site.

One of the most obvious things would be compressing the content sent to the client/browser. For somewhat obvious reasons, NearlyFreeSpeech didn’t enable the gzip module on Apache nor does allow one to enable it in .htaccess.

After a few digging in the NFS forums, I came to the conclusion that I had two options: either using MultiViews or a RewriteRule in my .htaccess. Since the MultiViews needed some more work, I opted for the following rewrite rules:

Header add Vary accept-encoding
RewriteEngine on
RewriteCond %{HTTP:accept-encoding} gzip
RewriteCond %{REQUEST_FILENAME} !\.gz$
RewriteCond %{REQUEST_FILENAME}.gz -f
RewriteRule (.*) $1.gz [L]

Translated to plain English, this checks whether the requested file isn’t already a .gz file and if there’s a gzipped version of the requested file in the server. If so, the gzipped version is sent to the browser instead. This allowed to reduce in more than half the size of most files (html, css and js).

The next step was “smushing” the images, that is, compressing them further. There’s a service (Smush.it) that tries several techniques to compress images without changing the image quality. This shaved a few more KB.

However, that wasn’t enough for me. I needed more. This was becoming almost an addiction, trying to make my blog so light it loaded instantly.

So I used another cool service (CompressorRater) to try several minification techniques on Javascript code in order to squeeze some more KB. Success!

I still had too many HTTP requests going on. Each HTTP request adds some loading time to the total. Since I was using three stylesheets (one for resetting the CSS styles, another for the code syntax highlighter and one for the blog stylesheet itself), I first tried merging them all into one file. That had disastrous results and I’m still not exactly sure why.
“Alright”, I thought, “I’ll just leave the reset CSS alone and merge the other two.” It worked fine. Then I minified it, which shaved about half the original size.

At this point, there wasn’t much more I could do. The bottleneck now was loading the comments from Disqus. But there was one thing bugging me: the code for updating the comment count was running in every page, even in the index/archive, where there was no need. That introduced some delay in a completely static page.
It turns out the code the guys at Disqus tell you to use do something silly for a reason I cannot understand: after checking for thread/blog post links, it contacts the Disqus servers to get the comment count even if finds no such links!

So, I changed it to the following:

(function() {
  var links = document.getElementsByTagName('a');
  var query = '?';
  for(var i = 0; i < links.length; i++) {
    if(links[i].href.indexOf('#disqus_thread') >= 0) {
      query += 'url' + i + '=' + encodeURIComponent(links[i].href) + '&';
      document.write('<script type="text/javascript" src="http://disqus.com/forums/scarybox/get_num_replies.js' + query + '"></' + 'script>');
    }
  }
})();

This fixed the problem without seemingly affecting the script’s behaviour.

I also updated the link to jQuery, from version 1.2.6 to 1.3.2. The new version is 3KB bigger but it’s also much faster than the pre-1.3 versions. For instance, the “About” slider on the top of this blog now slides up and down much smoother. All in all, it was worth the extra 3KB, since I removed much more in my little adventure with compressing stuff.

Now the slowest part of my site is loading the Disqus comments, and I have no idea how to speed that up. Any suggestions?

A new beginning

2009-08-03T00:00:00+01:00

In another treacherous act of blogginess, I nuked my tumblelog and started using Jekyll (a static site generator in Ruby). Actually, I’m using a fork created by Henrik Nyh that adds support for Haml (for templates) and a few other niceties.

The reason for this was, since my blog tends to be quite static, it doesn’t make much sense to use a full blown dynamic CMS like Wordpress or Typo, or even a custom one powered by Django, like I had once, PLUS a database for my posts PLUS caching, if I don’t want a slow site. Isn’t this too much overhead just for a tiny blog? And migrating posts between those systems is a pain in the neck. The only truly dynamic part of my blog are the comments, and those are handled very well by Disqus.

In Jekyll, posts are plain text files, using whatever markup you like (I use Textile, but you can use Markdown too, or any other filter if you fork the source). You edit them in your favourite text editor (I’m using TextMate right now), then invoke jekyll in the root directory of your blog and presto, your static blog is generated! Then it’s just a matter of uploading the files to your hosting provider and you’re done.

Another cool thing is, this way I can easily back up and keep track of changes in my blog by using git and a repository somewhere (I like github).

Oh, another thing: I’m redirecting scarybox.net to ricardomartins.cc. There was too much overlap between them to justify the separate existence of both at the moment. Don’t worry, scarybox won’t die anytime soon, it’s time will soon come, rising as the sinister “scarybox project”! <insert mad cackling>

NDS adventures: code for clearing the screen background

2009-07-29T00:00:00+01:00

I’ve been getting my feet wet with developing for the Nintendo DS. While I can’t afford the official SDK (nor would they sell it to me, a lowly student with no intention to sell games yet), I installed devkitARM, an unofficial SDK developed by “amateurs”.

Down to the basics

First things first, I wanted to learn how to clear the screen (actually, there are two screens in the NDS, but let’s leave that aside for now).

Actually, there are several ways to clear to background or, better said, painting it black.
One way is iterating over each pixel in the display buffer (BG_BMP_RAM_SUB) and setting it’s color as black (RGB 0,0,0).

/* Clears the background of the sub screen. */
void clearBottomScreen()
{
    u16* video_buffer_main = (u16*)BG_BMP_RAM_SUB(0);
    int i;
    for (i = 0; i < SCREEN_HEIGHT*SCREEN_WIDTH; i++)
        video_buffer_main[i] = RGB15(0,0,0);
}

One other way I read somewhere and which is surely more efficient involves doing something similar over DMA transfers, painting much more than a pixel at a time. I shall investigate this.