Lets face it: Your coworkers can be a real pain in the ass sometimes. What better way to remind them of this than automated Rick rolls? They’re likely to never know what hit them.

What is launchd?

According to the launchd guide on Apple’s website:

The launchd daemon takes over many tasks from cron, xinetd, mach_init, and init, which are UNIX programs that traditionally have handled system initialization, called systems scripts, run startup items, and generally prepared the system for the user

launchd stores tasks in plist format. You can find your agents in ~/Library/LaunchAgents. Here is a typical launcd file that will open iTunes every 60 seconds:

  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
  <plist version="1.0">
  <dict>
    <key>Label</key>
    <string>com.alternateidea.article.test</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/bin/open</string>
        <string>-b</string>
    <string>com.apple.iTunes</string>
    </array>
    <key>RunAtLoad</key>
    <false/>
    <key>StartInterval</key>
    <integer>60</integer>
  </dict>
  </plist>

Obviously this would be seriously annoying, but for the purpose of this demonstration, save this file as “com.alternateidea.article.test” in your ~/Library/LaunchAgents folder.

This script won’t run automatically, so we need to load it up first using the launchctl program:

launchctl load ~/Library/LaunchAgents/com.alternateidea.article.test.plist

Our agent is loaded up now. After 60 seconds, you should see iTunes.app open. Pretty nice, eh?

Ok, so we don’t want to keep running this agent. Lets unload it:

launchctl unload ~/Library/LaunchAgents/com.alternateidea.article.test.plist

Never gonna give you up. Never gonna automate your Mac.

So, here’s the trick: Wait until your coworker goes to lunch or you know they’ll be out of the office for 10 minutes or so. Then, let the mischief begin.

The first thing we need to do is create our agent:

  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
  <plist version="1.0">
  <dict>
    <key>Label</key>
    <string>com.youtube.rickroll</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/bin/open</string>
        <string>-b</string>
            <string>com.apple.Safari</string>
            <string>http://www.youtube.com/watch?v=eBGIQ7ZuuiU</string>
    </array>
    <key>RunAtLoad</key>
    <false/>
    <key>StartInterval</key>
    <integer>1800</integer>
  </dict>
  </plist>

Everything should be pretty obvious in this plist. The StartInterval is in seconds. I want to be an asshole every 30 minutes (1800) seconds. If you want to be a bigger asshole (or Son of a Bitch) you could set this to run in shorter intervals.

Now, we need to save this and load it up on your coworkers computer. Save this to ~/Library/USERNAME/LaunchAgents/com.youtube.rickroll. And load it up:

  launchctl load ~/Library/LaunchAgents/com.youtube.rickroll.plist

If you want to test and make sure everything is in working order, you can run:

launchctl start com.youtube.rickroll

Question: Did you just Rick Roll yourself?

Now, if your test ran successfully slip back to your desk and wait in anticipation for that awesome intro.

var selection;
if(window.getSelection)
  selection = window.getSelection();
else if(document.selection)
  selection = document.selection.createRange();

Why are there so many lightbox implementations? Why are there numerous “versions” of widgets? Do you know which fork is the latest and greatest? Probably not, and for good reason. The current system sucks.

Over the past few days I’ve been studying the YUI library and it’s accompanying ecosystem. It’s truly a well oiled machine. But besides being developed by a web giant, what makes it tick? There are numerous things I’ve come to conclude, and it shines a light on why widget efforts by Prototype developers et al have largely failed.

The public face

• Documentation: This is the most obvious one, but the one we get wrong 90% of the time. If you’ve written a widget, you have intimate knowledge of it’s inner workings and how to use it, knowledge your audience doesn’t have. We make the assumption that consumers will understand our products on the same level we do. This isn’t the case. Even YUI beta code has full documentation and a host of examples.

• Centralization: If you want a YUI calendar control, where is the first place you look? On the YUI site. If you search Google for YUI, you get the official YUI calendar and also a collection of blog post showing some cool tricks and general usage of the official control. If you want to learn how to use the YUI Calendar control, where is the first place you look? The YUI site. It’s all organized and centralized.

• Standardization: Everything is standardized. Everything from how articles are written and structured to the release cycles and code conventions. Take a look at the Drag and Drop landing page and then the Dom Collection landing page. Notice the clear and concise explanation of what the component is. Also note the bullet points for quickly navigating a page, the “Getting Started” headers, the cheat sheets and the examples—It’s extremely helpful. Don’t forget about YUI Theatre either.

The code

• Modularity: The code is extremely well structured. It’s not all or nothing. I’ve not been a fan of deep namespacing (e.g. YAHOO.widget.Menu), but in this context I think it’s important. It not only has utility, it creates a visual hierarchy with only small overhead. I definitely prefer common utilities such as $('foo) and baked in enumerations (augmenting native prototypes), but I’m fine with doing var menu = new YAHOO.widget.Menu("mymenu");.

• Event Driven: This one was enlightening for me. Most of YUI’s widgets rely heavily on custom events to pass messages internally and externally. Notice how all of the “interesting moments”, both private and public are handled through events setup in a Menu’s initialization routine. None of them are directly invoked by another method.

• Inline documentation: I debated whether this was important enough to warrant a bullet point (it was encompassed with the public api docs), but as I continued to study the code the inline API comments were indispensable. Whenever I wondered what an argument meant, I could see it documented a few lines above where I was scanning the code. Check out this snippet from YUI’s CustomEvent object.

    /**
     * Notifies the subscribers.  The callback functions will be executed
     * from the scope specified when the event was created, and with the 
     * following parameters:
     *   <ul>
     *   <li>The type of event</li>
     *   <li>All of the arguments fire() was executed with as an array</li>
     *   <li>The custom object (if any) that was passed into the subscribe() 
     *       method</li>
     *   </ul>
     * @method fire 
     * @param {Object*} arguments an arbitrary set of parameters to pass to 
     *                            the handler.
     * @return {boolean} false if one of the subscribers returned false, 
     *                   true otherwise
     */
    fire: function() {
     //...
   }
   //...

Notice the method signature for fire. At first glance it looks like it doesn’t take any arguments, but take a look at the signature in the documentation. Pretty nifty trick. Notice this line in the comments: @param {Object*} arguments. The * tells JsDoc Toolkit to treat the following word as an argument for the method. JsDoc Toolkit can do some really cool stuff and has made vast improvements since it’s inception as JSDoc. It also now speaks Prototype.

Summing up

2,300+ miles, 3 1/2 days and 10 states later, we’ve completed our move from Memphis, TN to Portland, OR.

Wow, what a drive! The Oregon countryside is breathtaking. Wyoming and Utah were also beautiful, but the drive alongside the Columbia River in Oregon made the trip that much more enjoyable.

My wife and I, along with a long-time friend of ours, took one of the most amazing cross-country drives you could take. We’ve been planning the move to Portland for some time, and now we’re officially here.

One of the primary reasons for moving to Portland was to consolidate Active Reload into one city. We’ll be sharing an office with the talented guys over at Kongregate and couple people from Caboo.se. I expect some exciting things to happen as a result of this.

Nearly all the methods of Adobe’s SQLConnection class are asynchronous. While this is nice when your running expensive operations (your interface won’t hang up), it can be quiet tough to deal with considering we come from a land where database operations have always been synchronous.

Before we begin, you might want to download this SQLite database .

A short example

If you’ve been using ActiveRecord like me, you’ve probably forgotten how to write SQL. Well, dust off your SQL skills because you’ll need to know how to write queries if you plan on using Adobe AIR’s SQLite support.

var connection = new air.SQLConnection();
connection.open(air.File.applicationResourceDirectory.resolve('development.sqlite'));

The code above, albeit a little long winded, is the bare necessities for executing a query. While it looks fairly straight forward on the surface, we’ve already run into our first problem. If the execute operation is asynchronous, how do we know when we can begin to retrieve and manipulate the data returned? We can do it one of two ways, register an event listener or pass a Responder object to the execute method.

Using a Responder to handle results

The first option we have is passing a Responder instance to execute. A Responder is an object that encapsulates two functions, one for success that passes an SQLResult object, the other for a failure that passes an SQLError object. Lets modify our execute method:

statement.execute(-1, new air.Responder(
 function(result) {
   result.data.forEach(function(row) {
     air.trace(row.name);
   })
 },

If you execute this, you should get the names of our contacts printed to the terminal. Awesome! Now, change the query to add a table name that doesn’t exist, you should be the error message printed to the terminal.

The benefit of using a Responder object is there is no need to register and remove event listeners. In addition to that, there is no need to call the getResults method (see below) on the SQLStatement instance.

Registering Event Listeners

The second option we have is to register event listeners. Starting back at our original code, we can modify it to reflect the changes below.

//Directly below statement.sqlConnection = connection

This is a lot more code and it looks fairly nasty in comparison to good ol’ synchronous connections. Unfortunately, this is the world we live in with AIR. The shit hasn’t really hit the fan yet, let’s see what happens when we try to run a new query directly after our first one.

...
     statement.text = "SELECT * FROM contacts";
     statement.execute();
     statement.text = "SELECT * FROM cases";
     statement.execute();

We get an error: ”Error: Text property cannot be changed while executing.” Oops! It seems we can’t execute two queries simultaneously. We have to wait for one query to finish before the other one begins¹.

Dealing with multiple dependent queries

You can run single queries all day, preferably using a Responder object, but what happens when you need to run multiple queries and the later query is dependent on the results of the first one? It’s not pretty, but the cleanest way I’ve found to do it is to nest callbacks. I’m going to dump a load of code on you, and you can take a moment to soak it in.

 var SQLiteConnector = {
   connect: function() {
     return (function() {
       var connection = new air.SQLConnection();
       connection.open(air.File.applicationResourceDirectory.resolve('development.sqlite'));
       return new SQLiteAdapter(connection);
     })();
   }
 }

The above code is written using Prototype, but it’s fairly simple to see how to adapt this to PAJ. With that disclosure, lets see what’s going on here.

The first thing I’ve created is a singleton object that connects to the database and returns an instance of our ‘SQLiteAdapter’. The SQLiteAdapter just makes our life easier by wrapping some of the lower level database operations and also deals with setting up our callbacks so we don’t have to. Lets put it to use.

 var connection = SQLiteConnector.connect();
 connection.execute('SELECT * FROM contacts WHERE name = :name', {name: 'Bob'}, 
 function(contacts) {
   air.trace(contacts[0].name)
 });

So, I’m passing 3 arguments to execute, the sql, parameters and callback. The sql is an unprepared string (notice ’:name’). The parameters are what we use to replace the placeholders in our sql text. See here for more info on parameters. The final argument is our callback and it also accepts an argument of it’s own, our data returned by the query.

If you look in the execute method, you’ll see that we’re passing our own function to a Responder object, and within that function, we invoke our callback, passing it the results of the query via results.data. The bind isn’t necessarily needed, but if we wanted to invoke methods of our class, we use it to control the execution scope. If you run this you should see ”Bob” printed to the terminal. But now that we have a contact object, how can we use that in another query? Nested callbacks is the most efficient way I’ve found so far.

Why nested callbacks? Why not a separate function somewhere else in our file? The answer for me is simple; I want to group related code, I want to read my code as if it was being executed from top to bottom, I don’t want to have to fumble through potentially thousands of lines of code to find the callback that responds to a certain query. This is personal preference, if you want to use named functions or the like, go ahead. But, on with the show, what does this look like?

 var connection =  SQLiteConnector.connect();
 connection.execute('SELECT * FROM contacts WHERE name = :name', {name: 'Bob'}, 
 function(contacts) {
   connection.execute('SELECT * FROM cases WHERE contact_id = :id', {id: contacts[0].id},
    function(kase) {
      air.trace(contacts[0].name, kase[0].title);
    });
 });

Scary stuff, I know, but lets look at what’s going on here. The first thing we do is fetch a contact record from the database, and in the callback for this query, we execute another query that gets a case record for that contact, again passing in a callback so we can finally manipulate the data. In a traditional synchronous operation, this might look like the code below.

var bob = connection.execute("SELECT * FROM contacts WHERE name = :name", {name: 'Bob'})[0];
var kase = connection.execute("SELECT * FROM cases WHERE contact_id = :id", {id: bob.id})[0];
air.trace(kase.name);

So, it all boils down to either a) nested anonymous functions or b) named functions spread throughout your code.

AIR: The Good, Bad, and Ugly

The Bad

• No command line support, won’t be in 1.0 either.
• Can’t open native applications from within an AIR app.
• Psychedelic 70’s Desktop. Just look at the samples, not one with a native look. It’s really easy to slap something together, but it’s also possible to create native looking applications (Minus the unified toolbar on OS X).
• No direct Ruby support. You can use a local proxy server, but that server can’t be started from the application, so it has to be hand cranked if you want to use Ruby to write AIR applications.
• No XPath support (document.evaluate). Webkit has this, not sure why AIR doesn’t considering it uses what I assumed to be a fairly recent Webkit.
• Incomplete documentation (Note the Responder object says nothing about how we used it in this article, only refers to NetConnection.
• All the developers seem to be on the bus. I’ve yet to get a response on a forum post or email.
• Few details on when the next beta will be released or exactly what features/bugs will be addressed.

The Good

• Cross platform
• One CSS implementation, One JavaScript implementation. Sweet harmony.
• HTML and JavaScript or Flex and Flash
• Extensions to JavaScript, File System Access, SQLite support
• Free Book and Videos
• You can use Prototype, JQuery, Mootools, Dojo, YUI, it doesn’t matter.

The Ugly

• Asynchronous Database operations
• Did I mention the non native look?

Wrapping up