Slate (or How I Learned to Hate The Finder)

Sometimes I find myself tolerating something that sucks because I haven't really thought about how much better it could be. Moving, hiding, and window switching in Apple's Window manager is one of those things.

I didn't realize how much it sucked until I discovered Slate (Installer & Github site). It's a great little tool that allows you to bind hotkeys to window focus, move, or hide events.

It is a hyper-configurable (in fact it'll be mostly useless to you without a configuration file; but I'll point you at my configuration as a starting point) app for managing focus, size, and position of your windows with hotkeys.

A few examples that I've set up:

Command-Shift-B: bring my browser into focus.
Command-Shift-T: bring my terminal app into focus.
Command-Shift-Space: hide everything other than whatever window I have in focus.
Command-Shift-Delete: hide the current app.
It would be worth installing as just a replacement for command-tab as a window switcher, but you can do super-complicated things by chaining a bunch of operations together like so:

Command-Shift-=: hide everything except safari, eclipse, and iterm. Then move eclipse to the right side of the screen taking up 80% it. Then move iTerm to the other side and Safari to the bottom left. Finally, bring eclipse to the foreground.

Oh, and if you find yourself moving between laptop and monitor (or monitors) you can set up operations like that one to be triggered automatically when you plugin your monitor and get your apps into the right positions on all your monitors as soon as the OS detects them.

Here is my current configuration file:
http://code.google.com/p/geekery-blog-code/source/browse/trunk/src/main/scripts/slate.config

If you want to install it, just download it, and save it to ~/.slate with terminal or something.

And here are a few more resources I've found:

The Github Site: https://github.com/jigish/slate

Closure could be a bit more javascripty

My new years resolution for this year has been to take javascript more seriously. In that time, one of the things that has caught my attention (and affection) has been the closure compiler.

I do love closure, I do but as it is now, it can't really think of itself in a universe where one would write code that would _ever_ be executed uncompiled.

Until there is a (working) realtime compilation plugin for Eclipse, I'm going to need to run my JS uncompiled until I get it right, and then compile it.

Consider the following two types: ns.Type1 and ns.Type2.

var ns = {};
(function() {

 /** @constructor  */
  ns.Type1 = function() {
  };
  
})();

/** @constructor  */
ns.Type2 = function() {
};

/**
 * @param{ns.Type1} bar
 */
function foo(bar) {
}

/**
 * @param{ns.Type2} bar
 */
function baz(bar) {
}

They only differ in that ns.Type1 is created inside a closure. This lets you have actually private variables in javascript and generally allows for the sort of encapsulation that javascript should have had built into it. The second one, just defines everything out in the global namespace.

Everything works great for Type2. For Type1, you get a warning (and a failure) for attempting to reference the type in @param{ns.Type1} in your function at the bottom.

If you are always going to run your code compiled with ADVANCED_OPTIMIZATIONS, it really doesn't matter. You'll define your privates private with annotations and any illegal usage is going to fail compilation. Thats great. Except if you do your development and debugging in naked JS, you won't find these problems until you compile.

Is that a bug? Hard to tell: I suspect, given what I've read from the closure discussion groups, that this sort of thing was designed in.

And it gets worse, the further you go off the reservation. Consider Crockford would have us believe (and I am pretty sure he is right, at least I'm not sure he is wrong and he is smarter than me) that we would do well to define our functions for our Types in their constructor. Thats great, but in both cases there seems to be no way to tell the compiler that your Types expose various properties.

At any rate, I love closure. It makes for better javascript, but it could go a long ways towards making better javascript easier by simply adopting some of the best practices that have evolved over the years for making javascript safter without compilation. As an added benefit, these sort of things would make it much easier to make tools like jQuery compile with ADVANCED_OPTIMIZATIONS.

Your Binary Search Implementation Is Wrong

I've lost count of how many times I've written:

     public static int binarySearch(int[] a, int key) {
         int low = 0;
         int high = a.length - 1;

         while (low <= high) {
             int mid = (low + high) / 2;
             int midVal = a[mid];

             if (midVal < key)
                 low = mid + 1
             else if (midVal > key)
                 high = mid - 1;
             else
                 return mid; // key found
         }
         return -(low + 1);  // key not found.
     }

On someone else's whiteboard, usually as a warm up to something more complicated.

Turns out every time I wrote that I was wrong (along with most everyone else). Why? The bug is in this line:

int mid = (low + high) / 2;

Why? Our good friends at google research pointed this out few years ago. Good read it to find out what the bug is and then do it right next time someone asks you to whiteboard binary search (or most other divide and conquer algorithms).

http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html