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? [↩]

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? [↩]

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. [↩]

Mostly for Pete, a follow-up to a thread on Facebook today…

The co-worker’s terminal font (click to make big):

Andale Mono 9pt

Now I used to have a big fat crush on Andale Mono but how could that be easy on the eyes?  The painfully mucky tilde, the one digit and the lowercase L practically indistinguishable!  And at 9pt?  Holy cow that’s tiny.

Now Pete’s:

Monaco 10pt

A wiser choice.  The one digit and the lowercase L are more distinct (though the latter is not all that distinct from the pipe).  A nice swoosh to the tilde.  And even at 10pt, it is nice and legible.  Still, there’s something about Monaco that’s always been a little unsettling to me.  Like the legs on the lowercase M are too bunched together maybe…?  Never could put my finger on it.

Now, Consolas, that’s the fixed-width font for me:

Consolas 14pt

Now I know what you’re going to say.  “Weren’t you just busting on Andale Mono for the one digit and the lowercase L being too similar-looking?” Yes.  But there’s always that risk¹.  I find the “1″ and the “l” here to be sufficiently distinct.  Especially at that luxurious 14pt.

1. Swing too far in the opposite direction and you get a lowercase L that looks like a pipe, eh? [↩]

Partly for my own enjoyment and partly to respond to Tweets from two friends of mine, I’d like to write a little bit about my experience with the Git source control manager.

Before we get too far in this process though, let’s get one thing out in the open.  I’m probably the least technical developer out there.  I’ve used Subversion “lightly” for a simple development project for about two years and CVS at the office for only about the past six months or so.  So keep that in mind as we move forward here:  my frame of reference is not a terribly technical one and is likely not to answer any burning questions that you may have about branching or anything else that moves into terribly complex terrain.

That said, my thoughts re Git versus Subversion and/or CVS?

LOVE IT.

Read the rest of this entry »

While banging through the home-stretch of Ortho 1.0, I decided to give MacRabbit’s Espresso editor a try. I’m “between” editors right now — feeling no special love or loyalty to any one text editor — and noting Espresso’s public beta, I decided it was worthy of some exploration.

THE SHORT VERSION: I liked it alright but there was nothing about it that blew me away.

Read the rest of this entry »

Almost exactly two years ago, I first unveiled Ortho, the home-rolled custom WordPress theme that you see here.  It is named in part after the character Ortho Stice from David Foster Wallace’s novel Infinite Jest and is also a vaguely tongue-in-cheek, slightly punny nod to the squared-off corners that graced the original design.

With this “1.0″ revision, I have tried mostly to go for some refinements.  I wanted to “widget-enable” the theme, I wanted to clean up some of the code, and ply a few other tricks to open up my future options a little bit.  I did my development primarily in Safari (with a soft-spot for Firefox) and tried to play nice with Internet Explorer.  I found that though IE7 is not nearly the nightmare that IE6 continues to be, that it still has a startling lack of support for many things¹; IE6 is still a nightmare but I gave myself a hard cut-off of two hours — anything that couldn’t get fixed or made to gracefully degrade got hacked out.  I conceded to use conditional comments but that was in the interest of ousting old * html hacks.  I looked at Ortho in Opera just for fun and in the two minutes I spent browsing, found that nothing obviously needed attention — not that I get much traffic from Opera users.

Some other handy technical notes for the web nerds out there:

1. I actually bothered to run my CSS through the YUIcompressor 2.4.2.  The gains were very very small but it was still a fun exercise.
2. I still hate CSS sprites which is part of why I’m not using them here.  Also, because I’m (er…) between graphics editors right now and had no effective means of making them.
3. I’m using the Google Ajax Libraries CDN-equivalent for the code jQuery here on blog.founddrama.net.  It takes some of the load off the server.  And should help for one of those tiny incremental decreases in load time.
4. I’ve kept Ortho in Subversion for the past two years and it has paid off well.  Though when it came time to deploy this site live, somehow a bunch of conflicts managed to make it into the master style.css file (despite the fact that I’d told SVN they were “resolved”) and that caused some panic for a few minutes.  Blargh.

Anyway, I think things turned out well.  Now that it’s up, it looks like I need to fix the trackbacks but I’m otherwise quite pleased.  Hopefully the transition went smoother for you (dear reader) than it did for me.  But anyway, should look nicer, read a little easier, and so on.

1. E.g., :last-child selectors, anyone? E.g., Unicode support, anyone? [↩]

I spent a little time this past weekend trying to wrap up my “for Ortho 0.5″ to-do list.  Fixed a few obscure bugs, polished up a few items that had bugged me, deferred a few others to the Ortho 1.0 to-do list.  And I was basically ready to close the book on Ortho 0.5 if not for IE6’s various inexplicable float bugs:

What you see is a carved-out screenshot from this recent post.  Looks fine in any decent, modern browser.  But as you can see from that screen cap, looks like shit in Internet Explorer 6.  My gut reaction is to take a page from Mr. John Gruber:

If Daring Fireball looks like shit in your browser, you’re using a shitty browser that doesn’t support web standards. Internet Explorer, I’m looking in your direction. If you complain about this, I will laugh at you, because I do not care.

But the evidence in my logs suggests that a significant-enough portion of my pages are getting served up to IE6¹ and so I feel like I should make a best effort to resolve something that so seriously screws up the layout.  So web standards aside, IE6 mockery aside, there was the challenge of getting things to look right.

Read the rest of this entry »

1. But my site stats log also tells me that the #6 browser visiting blog.founddrama.net is something called “porn_viewer larbin2.6.3″ so who really knows what’s up with all of that. [↩]