Google Apps migration and multiple accounts

Non-coding post today. If you use Google Apps for your Domain, you've either been transitioned to the new "full" infrastructure or you soon will be. If like a lot of people you have this crazy idea that your personal and professional lives should be separate, and so you have separate accounts for personal and private stuff, you'll run into the problem that your Google Apps stuff and your Google stuff now share an account cookie, and so trying to (say) view your personal email when you're logged into a Google service with your professional account will fail because you're logged in with your personal account. Sigh. If only there'd been a way to anticipate that this might be a problem and design and implement the solution properly before involuntarily migrating people over.

The good news is that Google now supports multiple account login in many of its services. You lose offline mail and calendar (huh?) and there are some other caveats, and it's still a PITA to use, but when/if you do manage to get signed into your multiple accounts on the services you mostly use, it does sort of work, a bit.

Hopefully as time marches by, the multiple accounts stuff will improve and spread to their other services.

Release: place5 placeholder emulator plugin (alpha)

Just briefly, folks, I'm writing to announcing the alpha release of my place5 jQuery plugin. It's just a dead-simple plugin that emulates HTML5 placeholder attribute behavior on browsers that don't support it natively. On browsers that do, it stays out of the way (unless you tell it to take over), but it quietly does the job for you on browsers that don't do it themselves. Check it out! This is alpha, throw issues into the issue tracker on the project site if (when!) you find them.

Appending to an array

JavaScript's Array#concat function is handy and cool, but it creates a copy of both arrays. That is, given array a and array b, a.concat(b) will create a third array c with the contents of both of them, leaving a and b intact. Now, sometimes that's what you want, but other times you just want to append b to a without creating a copy of a.

While JavaScript doesn't have a dedicated append function, there's a surprisingly efficient and concise way to do it:

a.push.apply(a, b);

That calls the push method via apply, which accepts a context argument (what the this value should be during the call) and any array-like object providing the arguments to give the call. Since push allows you to push multiple elements with a single call, that works a treat. And somewhat unusually for JavaScript, it's probably the most efficient way to do it on all platforms (where normally this sort of thing is faster on some and slower on others)

Now, if you do this in code other people are going to have to read, I'd recommend a comment saying "Appends `b` to `a` in place" or some such, because otherwise it's pretty opaque to people who don't know JavaScript well. Or, of course you could always add an append method to arrays:

(function() {
    var push = Array.prototype.push;
  
    function Array_append(array) {
        push.apply(this, array);
        return this;
    }
  
    if (Object.defineProperty) {
        Object.defineProperty(Array.prototype, "append", {
            enumerable: false,
            value: Array_append
        });
    }
    else {
        Array.prototype.append = Array_append;
    }
})();

As always, if you're doing that on platforms that don't have Object.defineProperty (and there are still a lot in the wild), make sure you don't have any broken for..in loops lying around.

jQuery 1.6.1 softens `attr` woes

jQuery 1.6's change to the attr function, and introduction of the prop function, raised quite a bit of confusion (and awareness) about properties and attributes. It was quite a breaking change, affecting a fair bit of code, and so jQuery 1.6.1 changes attr again to make it more backward-compatible. See the jQuery 1.6.1 blog post for details. According to the jQuery team, as of 1.6.1, most older use of attr should continue to work, although in many cases prop would be the preferred way to go.

Big compatibility break in jQuery 1.6

jQuery 1.6 is out, and unusually for jQuery, there's a pretty big API compatibility break with regard to the attr function. Details in the release notes, but basically, attr really is just for attributes now, whereas before it sort of conflated attributes and properties. There's a new prop function for interacting with properties.

Update 2011/05/11: jQuery 1.6.1 changes attr again to make it more backward-compatible for older code, details in the jQuery 1.6.1 blog post.

It's a seemingly-small change, but I've seen a lot of code that will be affected, especially around the "checked" property. If you've been checking whether a checkbox is checked using code along the lines of

// In an event handler, etc.:
if ($(this).attr('checked')) {
    // It's checked
}
// Or if you already have a jQuery object for the checkbox:
if (foo.attr('checked')) {
    // It's checked
}

...you'll need to update your code. Personally, I prefer going straight to the DOM element (that's what the jQuery team recommends as well):

// In an event handler, etc.:
if (this.checked)) {
    // It's checked
}
// Or if you already have a jQuery object for the checkbox:
if (foo[0] && foo[0].checked) {
    // It's checked
}

...and the above has the advantage of working regardless of what version of jQuery you're using. But you could use prop instead if you like:

// In an event handler, etc.:
if ($(this).prop('checked')) {
    // It's checked
}
// Or if you already have a jQuery object for the checkbox:
if (foo.prop('checked')) {
    // It's checked
}

(There's also foo.is(':checked'), but that's awfully round-about.)

The big properties I see people stumbling over are "checked" (hence the above) and "value" (but hopefully you were already using val anyway).

A brief, incomplete definition of 'an engineer'

Most of us, much of the time, react to "You're wrong" with "No I'm not! And you can't tell me otherwise!" An engineer's response is "How? Show me."

Thinking outside the box with the ASP.Net Development Server

A well-known limitation of the ASP.Net Development Server is that it will only bind to the local interface of the development machine, never the LAN interface, and so you can't bring up pages served from the development server from anywhere but on the box itself via the localhost name or 127.0.0.1 address. And fair enough, it's meant to be a debugger aid, not a web server. But there are situations where you want to think outside that box, and fortunately, it's dead easy to do so.

I wanted to do that because I'm working on a project where the server-side code is C# assemblies and the client-side is pure HTML, CSS, and JavaScript (no server controls or other ASP.Net-isms). I wanted to use VS.Net for debugging server-side C# code, and Chrome's Dev Tools or Firebug for debugging the client-side code in the browser. VS.Net makes it remarkably easy to debug server-side code — just mark the "project" with the client code as the startup project, chooose a port if you want, set the virtual path, make sure the server-side assembly projects are in the solution, and hit F5 (or click Run). It fires up the ASP.Net Development Server and you have full debugging of the server-side code (and client-side code as well, if you like, with its integration with IE). Excellent, couldn't be much easier. But for me, this is all happening in a VM (this is for a client, and I keep all my client stuff isolated from my work and each other using VMs) but I'd like to do the client-side debugging with Chrome's Dev Tools on my main machine.

It was only a mild irritation (I can run a browser in the VM happily enough), so I didn't want to spend any time on it, but I figured this has to be one of the simplest examples of the need for port forwarding or proxy serving on the planet (just bridging interfaces), and so I did a quick web search and found this article about using Squid to do it. Now, Squid is a big hammer for this nail, but it's so easy to set up, that it's still reasonable to use it.

That article's good, but I thought a few things weren't as clear as they may have been, so here's my step-by-step:

1. Tell the ASP.Net Development Server to use a particular port rather than picking one at random:
   1. Click the client code project in your solution
   2. Look at the properties
   3. Make sure that Use dynamic ports is False
   4. Choose your port under Port number (if you just turned off the Use dynamic ports option, you may have to click away from the properties and click back again to unlock the field; minor bug in VS.Net)
   I'll call that the "internal" port (the one that only works within the VM). In my case, I used 80; the VM doesn't serve any other web content.
2. Be sure your dev machine's firewall allows incoming connections whatever external port you're going to use.
3. Get and install Squid. The quick-and-easy thing is to get a binary from these nice people who are kind enough to maintain a Windows port built using the Microsoft toolchain: Just scroll down under the features list and click the "Squid download Page" link. Or, of course, you could grab the source and do it yourself (with the MS toolchain, or Cygwin and GCC). I grabbed 2.7.STABLE8 from the the nice people.
4. Unzip it somewhere handy. The Windows binary assumes C:\Squid, so I went with the path of least resistance and put it there.
5. Install it as a service:
   1. Open a command prompt (as Administrator, if you're on Windows 7 or similar)
   2. Change to C:\Squid\sbin.
   3. Type squid -i -n Squid
6. Set up the default config: Using your favorite file browser:
   1. Go to C:\Squid\etc
   2. Copy squid.conf.default as squid.conf
   3. Copy mime.conf.default as mime.conf (we're not going to edit it, but it's required)
7. Set up the proxying:
   1. Open squid.conf with your favorite text editor
   2. Go to the very end of the file
   3. Paste this in, replacing the bits in curly braces with your own values (without the curly braces) (mind the word-wrapping, Blogger is giving me a hard time yet again; best to copy and paste):

      http_port {EXTERNAL_PORT} accel defaultsite={EXTERNAL_IP_ADDRESS}
      cache_peer localhost parent {INTERNAL_PORT} 0 no-query originserver name=myAccel
      
      acl our_sites dstdomain {EXTERNAL_IP_ADDRESS}
      http_access allow our_sites
      cache_peer_access myAccel allow our_sites
      cache_peer_access myAccel deny all

      So in my case, since I want both the internal and external ports to be 80 and my VM's external (LAN) IP is 192.168.142.153, it's

      http_port 80 accel defaultsite=192.168.142.153
      cache_peer localhost parent 80 0 no-query originserver name=myAccel
      acl our_sites dstdomain 192.168.142.153
      http_access allow our_sites
      cache_peer_access myAccel allow our_sites
      cache_peer_access myAccel deny all

      ...but if you use different internal and external ports, be sure to set them according to the placeholders in the above.
   4. Save the file
8. In your (Administrator) command window, tell Squid to validate the config:
   squid -z
   You should see the message Creating Swap Directories and pretty much nothing else.
9. Start the service:
   net start Squid
10. You might choose to have Squid start when you boot the machine, via the usual services.msc settings

Sorted!