found_drama

While I was reading this, I liked to imagine that I was at university and that Douglas Crockford was the insanely popular genius professor that showed up late for lectures, and then either spoke too fast or else mumbled a lot, and then locked himself in his office refusing to answer the door during office hours while he worked on his Next Big Thing that would make everyone oooh and aaah and validate his brilliance.  Meanwhile, in that same imaginary university, Nicholas Zakas was the graduate student that served as the TA to that class—and he happened to be equally brilliant and super-accessible and willing to take the time out to explain it all in a way that was thorough and comprehensible.

So that being said, if you consider yourself or would like to consider yourself a professional front-end engineer for web applications (or in any way want to become a JavaScript expert), I cannot recommend this book enough.  On the one hand, you have Crockford’s The Good Parts—which does a great job of eviscerating JavaScript while at the same time extracting its (well…) its Good Parts—but it’s like someone ran the text through a minification utility and made it tokenized and super-dense and stripped out all the comments.  And on the other hand, you have Zakas’ Professional JavaScript for Web Developers which one might describe as The Good Parts (the long version).

What Zakas gives us—while assuming that you are already doing some professional JavaScript web development—is a good overview of JavaScript/ECMAScript, with special care given to make the text practical.  This is not strictly an academic exercise; he is careful to make sure that each example applies to real world scenarios (i.e., web apps running in a browser) and that you are able to take away something useful and meaningful from the text’s discussion.  In other words, he provides a road map for how to make the most of JavaScript as a language¹ and how to make it work in all the convoluted, counter-intuitive situations that you are basically guaranteed to encounter².

In a nutshell, if you are doing professional web development on the front end, this book needs to be on your desk.  I can’t wait to check out his next book³…

BONUS ROUND: Zakas says that Wrox has made this book available as a DRM-free ebook.

DOUBLE BONUS ROUND: Apparently, I made the man laugh.

1. …since, as a front-end engineer on the web, you’re stuck with it. [↩]
2. Even if you don’t expect to ever work with XML.  Even if you do think that the JavaScript 2 and ECMAScript 4 stuff is a little too future-forward/in-the-weeds type stuff. [↩]
3. Reading this before Feburary 24, 2010?  Sign up for your chance at a free copy! [↩]

An experiment (in part to settle something of academic debate); what is faster new Array() or []¹?  The function for the test case:

function makeSomeArrays(){
	var outputter = function(fn){
		var ts = new Date().getTime();
		fn();
		var te = new Date().getTime();
		console.log("total time: " + (te-ts)/1000 + " seconds");
	};

	// 1 million:
	var L = 1000000;

	// use Array constructor; push L new arrays...
	var test1 = function(){
		var a = new Array();
		for (var i=0; i<l ; i++) {
			a.push(new Array());
		}
	};

	// same as above - but in each case, declare a length to the array
	var test2 = function(){
		var a = new Array(L);
		for (var i=0; i<L; i++) {
			a.push(new Array(0));
		}
	};

	// same as above but via index assignment
	var test3 = function(){
		var a = new Array(L);
		for (var i=0; i<L; i++) {
			a[i] = new Array(0);
		}
	};

	// for 4-6: replace Array constructor w/ Array literal notation
	// except where declaring a length (container array, 5 + 6)
	var test4 = function(){
		var a = [];
		for (var i=0; i<L; i++) {
			a.push([]);
		}
	};

	var test5 = function(){
		var a = new Array(L);
		for (var i=0; i<L; i++) {
			a.push([]);
		}
	};

	var test6 = function(){
		var a = new Array(L);
		for (var i=0; i<L; i++) {
			a[i] = [];
		}
	};

	var tests = [test1, test2, test3, test4, test5, test6];

	for (var j=0; j<tests.length; j++) {
		console.info("test #" + (j+1) + ":");
		outputter(tests[j]);
	}
}

Yes, I realize that test #2 and test #5 result in an array with a length of 2,000,000 (vs. 1,000,000 for the other 4 tests).

Now for some chart porn; results:

As usual in these kinds of performance tests, shorter bars mean better/faster performance.  (And yes, test case #5 was wildly out-of-scale when run in Firefox².)

Test case #3 wins out in Firefox (1.536 seconds), but test case #6 wins in both Chrome and Safari (0.313 and 0.397 seconds, respectively).  Interestingly, Safari out-performed Chrome in 4 of the 6 test cases; but Chrome came out on top overall with that 0.313 second figure for test case #6.  The trick seems to be in assigning a length to the array and then assigning values to the indices instead of just pushing the values onto the end.

But this seems to wind up not answering the original question about Array() vs. [].  So really quickly (in Chrome), I re-ran test #6 with a new “test #7″ that replaced a[i] = [] with a[i] = new Array().  Console output:

test #6:
total time: 0.405 seconds
test #7:
total time: 0.892 seconds

Oh wait… that was basically the same as test #3…  Hooray for Array literals!

1. Knowing full well that it’s never as simple as that. [↩]
2. Due in large part to the fact that it paused execution to request my intercession.  But that doesn’t exactly bode well anyway, does it? [↩]

On a regular basis (talking “daily, all day” here), I run n tabs in an open Terminal window where n > 1 (and usually n > 4).  And so each time I open up on these tabs and cd into the directory I need, I’m hitting ⌘⇧i to set a custom title on that tab; and 99% of the time, that custom title is the last node in the pwd output.  So what I was thinking was to set up a little shell script, backed by an AppleScript to:

1. cd into a specified directory;
2. get the title I want via pwd | cut -d'/' -f5¹;
3. and pass that as an argument to AppleScript (via osascript in the shell script) to have it set as the title of the tab.

The shell script² piece ought to be easy enough:

alias mycd="cd /path/to/directory/of/interest;
    osascript ~/Library/Scripts/set-terminal-tab-title.scpt
    `pwd | cut -d'/' -f5`;"

And the AppleScript ought to look something like:

on run argv
  tell application "Terminal"
    set terms to every window in application "Terminal"
    repeat with term in terms
      if term is frontmost then
        set tTabs to every tab in term
        repeat with tTab in tTabs
          if tTab is selected then
            set cTitle to item 1 of argv
            set custom title of tTab to cTitle
          end if
        end repeat
      end if
    end repeat
  end tell
end run

…and this almost works³.  Almost but not quite.

First:  let’s gripe about how verbose AppleScript is.  Loop through every window to find the frontmost?  And then loop through every tab to find the selected tab?  Apparently this is what I need to do.  Now, accepting that and moving on…

The first thing that breaks down in practice is the pwd code cribbed from Stack Overflow.  Throwing that into the command line gives me what I want.  And executing that within backticks to generate the output to the osascript’s argument works.  But it doesn’t work when wrapped up in the alias⁴.  What’s frustrating though is if I pass a string literal there, the AppleScript accepts that.

Rock and roll, right?  Wrong.

Doing this for the first tab (let’s call it “interest”) seems just fine.  Start the second tab (let’s call it “interest2″) and do it there and both tabs are now named the same thing (“interest2″).  Do a third tab (“interest3″) and now they’re all “interest3″.  Well this is a drag!

Quit Terminal and start over…  What?  The new window is named “interest3″?  How can this be?  It would appear that setting the custom title on the selected tab is actually reaching into the application’s preferences and setting a custom title there and applying it app-wide and then permanently saving it as a preference.  So it seems I have two problems.

1. How do I get the standard output actually passed as the argument to the osascript?
2. How do I get it to only set the title on the tab?

Any takers?  Thoughts?  Suggestions?

1. Tip o’ the hat to this thread on Stack Overflow. [↩]
2. Yes, I know that setting an alias in .profile is not technically a shell script. [↩]
3. And on that note, I’d really rather skip passing arguments into the AppleScript at all and have it take care of the pwd trickery, but that’s a separate bit of frustration… [↩]
4. It occurs to me that I should try this as a “real” shell script? [↩]

I broke down and decided to try out Google’s Chrome browser after having heard so many positive reviews of it.  It’s backed by WebKit—just like Safari, my current favorite—and so if nothing else, I know it has a tried and true and powerful engine going behind the scenes.  That said, I’ve tried out more than a few browsers over the years and almost always wind up “switching back” after a day or two (or at most: a week or two).  With that in mind, I was more than expecting to go “Meh, back to Safari…” by the end of the week.

But at the end of that week, I’m beginning to think that Chrome might stick around for quite some time as my day-to-day browsing¹ browser².

First, what I like:

1. The tabs. The tabbed browsing experience in Chrome is nearly perfect and without a doubt the best I’ve seen so far.  The tabs in Chrome are “on top”, which Apple tried to do in the Safari 4 beta and failed to execute properly.  What Apple did wrong in the Safari 4 beta was to try to have the tabs merge into and replace the title bar; this is wrong.  From a UI/visual hierarchy perspective, the tabs definitely belong “above” the browser controls and the address bar, etc.—but they are themselves a part of the window and as such you need adequate clearance.  Under Safari 4 beta, the tabs went all the way up to the window edge; Chrome nails it by providing a just-about-right-sized buffer between the tab’s top edge and the window’s top edge—from what I can tell, it’s about ½-⅔ the size of the title bar’s normal height.  So there’s no ambiguity with respect to what you’re going for:  you’re either going for the tab (to rearrange it or do the also well-executed tear-off behavior) or else you’re going for the title bar to move the window around.  To crib a phrase, in the platform’s UI grammar, this is correct³.
2. The animations. You may call it superfluous if you wish, but this kind of spit-and-polish work can be important in setting one application apart from its peers.  Most of the animations are with the tabs, so I’ll list off a few that I instantly noticed and instantly loved:  the way a tab pops up when you create a new one; the way a tab sinks when you close it; the tear-off animation; the tab rearrangement animations; how the loading circle in the tab goes anti-clockwise and much slower until it gets a server response (and then starts to load).  These are not key features, but they sure make things feel more complete.
3. Fast. It feels like a very fast browser.  Maybe I’m distracted by the animations, but it seems a little snappier to render pages and to respond to in-browser events.  I’ve read that it’s faster than any other browser; but I’ve also read that Safari has the slightest edge on it.  But then again, I’ve also read that Chrome knows how to use more than one CPU core at a time.
4. Unobtrusive UI elements. When I first noticed that Chrome didn’t have a status bar across the bottom of the browser window, I went looking for it.  I want this thing to be turned on.  But after using it for a few minutes, I noticed that it didn’t need a status bar because it just displayed status messages on an as needed basis in a little messaging space that was only as big as it needed to be.  (Win!)  And then when I downloaded a file and instead of popping up a “downloads window” it just put a “downloads bar” across the bottom…  Well, I must say I was impressed with that, too.  Unobtrusive, and only as needed.
5. Additive tabs. If you (like me) tend to open big batches of tabs all at once from a bookmark group in the bookmark bar, you’ll appreciate that Chrome just appends these to the open tabs.  Instead of replacing the ones you have open.  (Safari, I’m looking you direction.)

What I do not like:

1. The icon. Chrome’s icon blows.  It looks like a Pokémon egg.  Or a half-baked Simon-from-the-future.  If asked to rate the browser icons, it would go something like this:  Shiira, Firefox, Safari, Opera … a whole bunch of other guys … Chrome, and finally Internet Explorer.
2. I miss my “open in tabs” command. Allow me to rephrase:  I’m annoyed that I need to right-click my bookmark group and click “Open All Bookmarks”.
   
   Safari just has this at the bottom of the bookmark group.  And I use it a hundred times a day⁴.
3. Text fields do not (always) play by the rules. Folks on the Mac that “switched” from Windows machines will probably understand this one right away.  You get used to hitting “home” and “end” to go to the beginning and end of lines (respectively) and then you switch and have to learn that you now press up and down to do the same thing.  And then you get used to it.  And then you start using Chrome and this isn’t the case.  Or at least isn’t always the case.  In the browser’s address bar, up and down are bound explicitly to the history/search results/bookmarks suggestions list that appears.  And within the browser window itself, a text field may play nicely with this convention.  And sometimes it won’t.  And I haven’t figured out the pattern yet.  If there is one.  Which just makes this worse/more frustrating/more annoying.  Perhaps I’m just being hyper-vigilant to it and Safari et al. are the same way.  But I’m not so sure.  [UPDATE 1/12/10: I think this is just a matter of waiting for Chrome to catch up with me and my browsing history and habits.  It does in fact seem to prompt-and-fill-in the same way as Safari.]
4. Double-clicking the tab bar doesn’t start a new tab. This is a behavior in Safari that I use all the time.  It drives me nuts that this minimizes the Chrome window.  I hate being forced to use the little “+” icon.  [ADDED 1/12/10]

What I’m undecided about:

1. The auto-completion in the address bar. Perhaps I’m just too used to how Safari auto-completes, but Chrome’s does not sit right with me.  I mentioned this immediately above w/r/t/ how the up and down keys are bound to the suggestion box; but I’m also expecting the address bar to instantly try to auto-complete my typing.  When I type “ama” I’m expecting it to instantly suggest Amazon.com.  Chrome does not always seem to do that.  Again:  it’s inconsistent.  Maybe it will learn as I go?
2. The way you close tabs. To quote the venerable and inscrutable Gruber, “It’s a grammar thing — in the Mac UI grammar, close buttons go on the left.”  But that said, Gruber writes that in response to a thoughtful missive of Chrome’s tab closing behavior by Basil Safwat at The Invisible.  The nutshell version of Safwat’s argument is that putting the tab closure icon on the right allows users to quickly close them with mouse-clicks with minimal mouse movements regardless of if they are closing from left to right or right to left.  I won’t go much further with that because you should really just read the article.  But that said, tabs in a browser are pretty wily and protean beasts by their nature, and while Safwat has some great points about tab praxis, the pedantic part of me wants desperately to reject the closure-on-the-right more/less out-of-hand because it’s a pretty fundamental violation of (there’s that phrase again!) the UI’s grammar.  Could it be that we need a corollary for the “closure on the left” rule?  Does praxis override all else in this case?  Or is there a way to accomplish this same fluidity without violating the placement assumptions?

1. As opposed to “development” browser. [↩]
2. Though Camino spent (almost?) a year or so as my day-to-day browser before it got displaced by Safari again.  So, who knows, eh? [↩]
3. Of course, they put the close button “the wrong side” w/r/t/ this platform’s UI grammar; but we’ll get to that in a bit. [↩]
4. All right, I am exaggerating.  It’s more like fifty times a day. [↩]

It started simply enough.  A simple¹ question:  ”Is it a button?”  Referring to this:

This is (of course) the “All Sizes” button for any given photo on Flickr.  And (also “of course”) depending on how pedantic you want to get and/or how technical, it’s arguably not a button at all:

…it’s an <a> masquerading as a <button>?  Or is its “buttonness” defined by its appearance?  Or is it defined by its function?  Or by some other, harder to define, harder to quantify quality?

Read the rest of this entry »

1. Really? Simple? [↩]

Following up on the September post (“advise me: enhancing storage“)—we went ahead and put a shiny new 1 TB Western Digital hard drive ¹ into Malkovich, effectively quadrupling the storage (re this particular problem) and paving the way for a lot more life out of this ol’ iMac.

The idea for this particular upgrade owes some thanks to Arden at dtgeeks.com and Wilson Rothman at Gizmodo.  For those of you looking to do this as well, budget about an hour and make sure you’ve got a small Phillips head screwdriver and also a TORX 10 bitdriver.  Oh, and your Leopard install disk and your Time Machine back-up drive.

Now… here’s where we started:

The plan:  remove the 250GB Maxtor drive (“seemed big at the time!”) that came with the thing² and replace it with the 1TB Western Digital drive that boasted all the speed benefits of SATA with some additional optimization for reduced energy consumption.  Alright… go.

First order of business is to pull the back of the iMac off.  This is easy.  There are three “lossless” screws on the bottom grill.  Lay the iMac flat and unscrew; gently lift the chassis backing off.  Well done.

OK, now we’re inside.  Do yourself a favor and blow out the dust.  Good job.  Now you see the hard drive?  It’s the green PCB in the sea of blue PCB.  Upper right.  Yeah, that’s it.  We want to get that out.

Now that we have gone in for a closer look.  Observe how the hard drive is in that bracket?  What we need to do is: (1) unscrew the bracket; (2) remove the tiny cable on the “bottom” [see photo at this link]; (3) disconnect the power etc. cables; and then remove the bracket from the drive — because we’ll need it for the new drive.

Use the Phillips to unscrew the bracket from the chassis.  Should be one screw on the bottom (by the memory modules) and two up top.

Now gently lift the drive up just a bit and use your fingernails to gently pull that tiny cable from the bottom of the drive/bracket.  It’s delicate, so be careful.  Nice job.

Lastly, pull the data and power cables from the rear of the drive with your fingers.  Now lift the whole drive out of the slot.  This is where your TORX 10 bitdriver comes in handy.

The hard drive is held into the custom-designed extra specially awesome Apple chassis by this weird little bracket.  And that’s fine — but the bracket isn’t held to the drive with your usual flathead or Phillips screwdriver.  Oh no.  They went extra fancy and used TORX screws.  Fortunately, I happened to have a toolkit that just happened to have the right size TORX head — a size 10.  Use the TORX 10 to remove the 4 TORX screws (2 on the top, 2 on the bottom) and thus remove the bracket from the old drive.  You may now commence celebrating.  This is basically the halfway point.

As I mentioned above, we went with a 1 TB WD Caviar Green drive (pictured here, above) to effectively quadruple the storage capacity of our aging iMac.  The rest should feel easy:

Use the TORX 10 to put the bracket on the new drive.  Attach the data and power cables to the new drive.  Lower it down into the bay and attach the little “other/misc.” cable.  Screw the bracket into the chassis.  Replace chassis backing etc.  Awesome.  Hardware section complete.

Now comes the software section:  for this section, I will basically defer you to the above mentioned article by Wilson Rothman.

Start the computer with the Leopard install DVD in it and boot from the disc.

You’ll need to use Disk Utility to format/partition the drive.

Then you can restore from Time Machine.

Except it’s a little more complicated than that.  Rothman wrote it up as follows:

Once you open up the system and swap out the drives, you can set the old drive aside, hopefully never to use it again. Assuming all went well, you restart the system and insert an OS X Leopard installation DVD. You won’t need the OS installer on it, but you will need it to act as mediator between the Time Machine backup drive and the newly installed blank drive. Once it boots up (you may need to manually restart to get it to work right) follow these instructions CAREFULLY:

1. Choose your language.

2. At the main screen, choose Disk Utility from the Utilities pull-down menu.

3. Select the drive itself and click on Partition.

4. In the Partition menu, select 1 Partition and Options… where you choose GUID Partition Table. Click OK then Apply, then say “yes” to whatever warning comes up.

5. Once you have reformatted the drive, close the Disk Utility window.

6. Do Not Go Forward. Instead, when you see the main Welcome screen, click the Back button, which takes you to the language select page. It sounds silly but DO IT. This shakes the system into action.

7. Once you have reselected your language and are back on the Welcome screen, click Utilities and select Restore System From Backup…

8. The process should go smoothly from that point on. You simply select appropriate disks to copy your chosen backup data from your Time Machine drive to the new internal drive, as shown in the following sequence:

…and then a bunch of pictures.

Now note: he means it when he says to follow those instructions carefully.  Especially that “Do Not Go Forward” bit.  The installer system will lose track of the drive you just formatted/partitioned if you do that.  Do the instructions above EXACTLY as described.

Except where he says “GUID Partition Table”, I did “Apple Partition Table”.  Just pay attention to what the prompts say.  It says right in the app which partition type is for Intel vs. PowerPC systems.  Just “RTFM”³ and you’ll be fine.

That concludes the hour.  Then you just wait for your backup to finish restoring…:

Nine hours was a bit of a stretch though. It was really more like four or five.

FOLLOW-UP NOTES:

Spotlight is going to want to reindex itself; that will take a couple hours depending on how much data you have.  Mail is going to want to set itself up again; but if you’re fortunate enough to use IMAP, this won’t be a big deal.  iTunes is going to get confused about what computer you’re on again; you may need to re-authorize a few songs.

1. Sorry Zeb; the 1.5TB was a good deal but bit-for-byte this was going to work out plenty fine for us. [↩]
2. Only partially true: that Maxtor was already the second or third drive we’d gone through.  But let’s not digress too much. [↩]
3. Whereby “M” I mean “Screen”? [↩]

Since moving into our new home, we’ve been trying to sort out our home audio situation.  We listen to a lot of music¹ around here.  Though we were feeling cramped, one of the nice things about our condo’s small footprint was the fact that that the music could be heard throughout the house without having to “go to 11″.  The iMac was hooked up directly to the stereo and one click in iTunes and we had music.

Though we love our new place, things are significantly more disconnected:  the iMac is in the office, the stereo is in the family room, and we spend most of our time upstairs (where there is but an old shelf system with a broken CD player but a working tape deck).  We’ve made due with the aux inputs and old iPod minis.  But it’s not quite the same.

Our preference would be to ape our previous situation as much as possible² and some kind of wireless situation seems to be the way to go.  But wireless systems out there all seem either woefully inadequate or else require a svelte new lifestyle and lots of extra cash.

In that way, “oddly enough” an Apple hardware-based solution has seemed thus far to be the way to go.  Airport Express appears to be pretty close to ideal in many ways, at least for resolving the situation upstairs.  And while we’re looking into it, there is a certain appeal to the tv; that is to say it looks like it might be what we need for pushing music from the iMac, over the air, to the stereo in the family room.  And while we’re at it, it can tap into some movies³, and access to Flickr and our photos.  Sounds great.

There’s just one important (to us) question:

When I play a song via tv is it going to increment that song’s play count in iTunes (like an iPod syncing back to the mothership)? or is it going to give me the audio but that’s all (like iTunes sharing over WiFi)?

Thus far I haven’t found a straight answer to this⁴.  And as I look further into this, and as the answer to my question starts to look more and more like a “no” then the chief advantage of the tv seems to have gone out the window.

Without that synchronization of the play counts, ratings, etc., then there is effectively nothing that the tv can give me (at “just $229″ USD, MSRP) that I cannot get from a shared-over-WiFi iTunes library and the MacBook (and/or Pro) we already have in the house.  And if we want to add video, a mini DisplayPort to HDMI adapter is just $6.40⁵.  And on further consideration, this may actually be a superior option:  the tv offers no integration with Netflix (for example) which otherwise streams just fine via WiFi to the laptop.  So in that case, it sounds like there are really no advantages⁶…

1. I dare say we constantly have tunes going. [↩]
2. I.e., and push all the music from iTunes, incrementing the play counts for each song, etc. [↩]
3. Alas, for an extra charge that I’d rather not get into. [↩]
4. Which I find super-hard to believe.  But maybe that ought to tell me something.  If it isn’t hyped in the marketing literature then it must not do it. [↩]
5. Though I could go to $70 if I wanted to get fancy and push the audio over HDMI as well. [↩]
6. Except maybe (just maybe) the small sleek footprint? [↩]

…or, how I added storage to my iMac and successfully put off getting another computer for at least another year?

Malkovich¹is running low on storage.  Today’s free space count is something like 26.09 GB.  Still reasonably respectable but considering total drive capacity started at 250 GB, we’re certainly feeling cramped.  Personally, I blame all the photos we keep dumping into Aperture.  Let the data speak for itself:

At this rate we’re likely to run out of space by say…  Xmas?  Or thereabouts.

Now, advise me (gentle readers) what do you think is the best way to expand storage without going all out and replacing the machine all together?  Current proposals:

1. Pick up a NewerTech Voyager Q “docking station”² and start loading up on internal SATA drives.
2. Replace Malkovich’s internal 250 GB hard drive with a 1 TB drive and then restore from the most recent Time Machine back-up.
3. Daisy chain another Firewire external hard drive or three off the current Time Machine drive.

Of course…  I’m open to suggestions.  What say you?

UPDATE: See also:  the thread on Facebook.

1. Loyal readers will remember Malkovich from this post speculating on the poor iMac’s eventual demise. [↩]
2. I prefer the Voyager Q to the Thermaltake BlacX mainly on the basis of Firewire support. [↩]

Snow Leopard (OS X 10.6) is here, and that’s plenty exciting. All the refinements—in the UI and under the good—are getting their due play¹. One of those refinements: all of Java’s roads lead to 64-bit Java SE 6².

If you’re not panicking (or at least a little alarmed) then don’t bother reading onward.

If (however) you’re asking about giving priority to the 32-bit version and/or if you’re looking for J2SE 5.0, you may find this article on the OneSwarm wiki to be helpful.

1. If all you need to do is give priority to the 32-bit mode, try launching the Java Preferences app (in /Applications/Utilities) and re-ordering the preferred modes.
2. If you need J2SE 5.0, try downloading and untarring the 1.5 version that shipped with Leopard (OS X 10.5).  The instructions from OneSwarm:
   1. cd /tmp/
   2. wget http://www.cs.washington.edu/homes/isdal/snow_leopard_workaround/java.1.5.0-leopard.tar.gz
   3. tar -xvzf java.1.5.0-leopard.tar.gz
   4. sudo mv 1.5.0 /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0-leopard
   5. cd /System/Library/Frameworks/JavaVM.framework/Versions/
   6. sudo rm 1.5.0
   7. sudo ln -s 1.5.0-leopard 1.5.0
3. And if all else fails, don’t forget to check where your ${JAVA_HOME} is pointed.

1. Either in the marketing literature or in blog posts circulating “discovered” improvements. [↩]
2. Which is to say, when you see 1.5.0 in /System/Library/Frameworks/JavaVM.framework/Versions, you’re just seeing a symlink to 1.6.0. [↩]

A self-professed miser and amateur budgeteer, I’ve been hearing rumors of Mint.com’s awesomeness for quite some time now.  A long-time Quicken user, I’ve been a bit reluctant to try it out — once I’ve gotten into the groove of a particular apparatus or routine, I’m loathe to break from it¹.

But Quicken has left me feeling wanting for a while now², despite (or perhaps because of?) how entrenched in it I’d become.

So I decided to give Mint.com the ol’ college try for (give or take) 30 days:

Read the rest of this entry »

1. Not for lack of an innovative spirit, mind you.  But on certain fronts (i.e., tracking your household expenses), the reward for even trying something different seems so… not worth it. [↩]
2. Brief and informal list of complaints against Quicken:  (1) I don’t really like how it does budgets [and consequently, I don't use the budgets feature]; (2) it stopped syncing with my bank statements more than two years ago and no amount of “resetting” the application seems to help for longer than two cycles; and (3) the reporting is all manual and tedious and the UI is just so clunky… [↩]