var n = new Number(1);
alert(n);				// 1
typeof n;				// object
n instanceof Number;	// true

var nn = 1;
alert(nn);				// 1
typeof nn;				// number
n instanceof Number;	// false

n == nn;				// true

typeof n == typeof nn;	// false

n++;
nn++;
alert(n);				// 2
alert(nn);				// 2

n == nn;				// true

typeof n;				// number
typeof nn;				// number
typeof n == typeof nn;	// true

The type coercion will ultimately work in your favor but the main point is that the type coercion has to take place in the first place. Granted, it is probably an edge case to do something like:

var n = new Number(x); // where x is a global storing an incrementer

function doMath(a){
	if (typeof a == "number") {
		return a + x;
	}
}

…but you never know. There’s some strange code out there.

First: what are the more traditional options?

A global function. If the mechanics of the function are not specific to the object’s implementation, then this might be a perfectly acceptable approach. If your function is just “doing stuff to” (or “…with”) some arguments then this might be fine. Performing some mathematical operations? Who needs an object-oriented approach for determining Fibonacci numbers? Or trimming whitespace from strings? Certainly that would be overkill.

A namespaced util method. Not too dissimilar from the global function approach; but if you’re namespacing, you’re less likely to have collisions in your variable and function names, and maybe some better sharing of common code, etc. As far as “static methods” go, we’re just calling these methods off a singleton—fine (for example) for converting constants, or otherwise working with and manipulating known quantities.

But what about something more sophisticated? What if you have a family of classes (e.g., widget editors) that are all related but may each require an ever so slightly different approach to the context inspection? A global function or namespaced util won’t quite cut it here. What are we to do?

Now it turns out that JavaScript’s prototypal inheritance apparatus provides us with a way to do this. Depending on how you’ve designed and implemented your object classes, this could be a relatively trivial operation.

Observe (using our suggested example above):

// the "usual" way...

// (1a) init your class and assign to a variable:
var myWidget = new net.fd.SomeWidget();
	// now we have our instance

// (1b) call the method from your instance:
myWidget.inspectContext();
	// ...except inspectContext() tells returns false
	// meaning that we created myWidget for nothing

// (2) try something a little different
net.fd.SomeWidget.inspectContext();
	// error! - "inspectContext" is undefined
	// ...because "net.fd.SomeWidget" is the constructor

// (3) try it again, with a twist
net.fd.SomeWidget.prototype.inspectContext();
	// still returns false but this time we didn't have
	// the extra overhead of creating the instance

Nifty, eh?

Imagine a scenario where you have a few dozen classes like this (e.g., each class representing an editor for a specific widget that you might deploy to your WordPress-based blog)—using this technique, each class could perform its own inspection of the context (e.g., the DOM fragment representing the widget) and depending on the outcome of the inspection, assign itself as the appropriate handler—and all without creating an instance of a given class until it is needed. Marvelous!

But this approach is not without some dangers and does require careful attention to detail and some discipline. Because you’re invoking the specified method from the prototype, you should assume that the method is not “scope safe”. This is not to say that this is unsafe; but this might not be what you think it is. You can still tap into this in your “static” method, but you better be damn certain that your this is what you need it to be and that whatever it is you’re trying to access was declared as part of that object’s prototype. As for the method itself, the arguments passed to the function become of critical importance for how the method returns. But, if you are aware of the possible scope issues, and engineer the “static” method in such a way that it is sufficiently scope agnostic, then invoking methods from the prototype in this manner can be a powerful technique to add to your JavaScript repertoire.

(1) To continue with the JavaScript University metaphor (from my review of Zakas’ Professional JavaScript for Web Developers): Finals are coming up in Prof. Crockford’s upper-division JavaScript class. You’ve been a diligent student all semester and although you’re not failing, it always seems like you’re somewhere in the middle of the pack. You want desperately to ace the final exam, so you reach out for some help. Zakas (the graduate student/teaching assistant for the class) offers to show you the thesis he is working on. Then It hits you like a bolt from the blue — every bit of it resonates with you. “It’s so simple! so clear!” you exclaim. The inner machinations of the language snap together in a way that makes it all feel new and exciting — the possibilities are boundless! You go back over your notes. You were close — oh so close — the whole time. But the last little bits drop in. A refinement here, a re-factor there… and the next thing you know, things are blazing. Your pages load 60% faster, execution time is down an average of 40%. You’re amazed at yourself. And when the grades for the final exam come back, you’re pleased to see that you aced it (aside from that little Oops on scoping closures — but you try to think of that as a conscious trade-off). Prof. Crockford is pleased (if a little disappointed that it took you this long to Get It) and you’re the envy of your peers. At least until next semester’s RegEx class with Prof. Levithan.  [Rated: ★★★★★]

(2) The frustrating part about working at a well-organized shop is that you get yourself all excited for a book like this and then half the recommendations in there are things that you’re already doing. Put scripts at the bottom of the document? Check. Minify and compress? Check. Concatenate and package? Check. So on the one hand you say: “I guess I can sleep a little easier at night knowing that our build system adheres to the best practices recommended by the experts out there.” But on the other hand, you’re a little disappointed because you were hoping for some startling revelations. Again: not that this makes it without merit. From this perspective, what is noteworthy about this book is that these best practices and techniques are all gathered up in one place and presented in a logical order; even if “you’re already doing it right”, it is still a worthwhile exercise to meditate on the specifics, and to really go deep on why these best practices are important. (Plus, it’s great to see the data — nothing beats a little chartporn for proving the point.) [Rated: ★★★★]

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.

TRIPLE BONUS ROUND: Shout from the man himself, albeit with a pointer to this review as it appears on Amazon.

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. 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?

UPDATED 7/7/2010: Thanks to all the helpful suggestions. Turns out however that AppleScript was not the way to go at all. Setting PS1 in my .profile turned out to be the winner:

PS1='\[\033]0;`(basename $(pwd))`\007\]\n[\t \w]\n\u@\h $ '

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?

It’s an interesting question.  On the web—where anything can “be a button”—what makes something a button?  What instills an object with “buttonness”?  Let’s try a few definitions on for size:

1. Only a <button> is a button. If we wanted to be strict about it, this gives us a good baseline.  Only that won’t work in any practical sense because then hardly any modern site actually has a button.
2. Any <input> element in the DOM with a type of button, reset, or submit. (And maybe also type of image?)  Again, this is a decent “strict” definition to use as a baseline but probably not one that is terribly practical.  But certainly this gets us closer.  Some flexibility in the input types.  But still, when I looked at Amazon.com’s homepage, I saw only two <input> elements in the mark-up—and neither was a button.  But this arguably isn’t a terribly good definition for a button anyway because you’re still just one line of CSS away from having an invisible button.  (And what good is an invisible button?)
3. If it looks like a button (and quacks like a button?) then it must be a button. Sufficiently vague?  This starts to feel more correct though.  Someone needs to be able to look at something and say “when I click on this, something will happen”.

But that brings us around to our original question:  is it more the look of the thing that makes it a button? or is it the action of the thing that makes it a button?  We know that it can’t be a strictly technical, strictly mark-up definition—because then hardly anyone would have buttons.  Where then is the middle ground?  What bastardized hybridization of links and graphics and input mark-up and JavaScript turn a “simple link” into button?

Because a link isn’t a button, right?  Unless it is a button?

Let’s agree to disagree here; let’s at least settle on this much:  there are going to be some times when a link and a button are visually indistinguishable from each other; and there will be times when a link and a button will be behaviorally indistinguishable from each other.  So perhaps we can start with this premise to at least differentiate these two concept (maybe un-muddy the waters a little bit):

A link is a navigational tool that moves the user between separate pages (and not necessarily within a given site) with no expectation other than acting on that navigation; a button acts on an object within the page and the user expects some non-abstract contextual change as a consequence of acting through that button.

That being said, from a functional perspective, “buttonness” comes from performing an action.  (Any action?)  What about format then?  What is the shape that a button takes?

A couple of questions come to mind almost immediately:

• Must a button have a border?  If not, do you embellish in some other way?
• Will your buttons have icons?  Always?
• Will your buttons have text?  Always?
• Do your buttons ever contain (or is it “conceal”?) a menu of additional/alternate/secondary actions?
• Are buttons always bound to toolbars?  Or can they show up anywhere?

In other words:  not so obvious, not so straightforward.

A few cases to consider:

Flickr.com

It was their button example that started this whole thing; vide supra.  Their design seems to eschew “buttons” in favor of action-bound “links” (e.g., “Add a Person”, or “Add a Tag”).  Where they have buttons (which are not actually <button> elements but <a> elements), the buttons are borderless and ghosted until you hover over them; and they’re lined up as though they are in a toolbar but—if you have a portrait-oriented image—that invisible toolbar may extend beyond the boundary of the image (i.e., the object that those buttons act upon).  And then there’s the buttons bound to the comment form—which are blue and have no border but are <input> elements.  But OK—I’ve heard that the Flickr team are heretics.

Amazon.com

Again, a design that seems to eschew buttons in favor of links.  But where we do have buttons, they appear to be graphics that are both bordered and embellished in such a way that they “come off” the page (i.e., with that raised plasticky 3D look) and they’re bound to specific widgets like the carousel (bordered, with icon, no text) or else they are bound to major actions like adding an item to the shopping cart (bordered, with icon, with text).

Facebook

Hmm…  I see a lot of “links” and a few “icons” but no…  Oh wait, there’s a button.  (And for those keeping score: bordered, no icon, with text.)

Google

A canonical example?  Bordered (and with simple corners!), no icons, just the text—and no real special embellishments of any kind save for a little light gradient.  (They’re even <input type="submit"> elements.)

Hmm… And hmm again.  A pattern emerges?  But does the border really make it a button?

Perhaps the whole thought experiment is a bit pedantic but in considering usability and user experience, the button ought to be (instantly?) recognizable.  Ultimately it comes down to having a consistent and predictable scheme across your application/site—so if you really aren’t interested in putting borders around every button then I suppose you don’t need to; perhaps always pairing icons with text is enough.  But if you’re to crib from the big successful players then we can infer that there is some magic fairy dust sprinkled onto the border.

For my money, I’m not a fan of the “ever-present” border—buttons are usually in toolbars (right? no?) and that ought to be enough to give away its intended purpose.  But I think I can come around on the borders.  What about you?

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.

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.

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.

From a strictly user-experience perspective, Git is a simpler, friendlier source control system.  It seems to be a little more forgiving of your blunders and makes it easy to back yourself out of a corner if needs be.  It’s less worried about your conflicts because those are your conflicts until you try to push those commits up to the origin (the central, master repository).

“What?” (you ask) “Central, master repository?”

Yes, that’s right.  By all accounts, Git is a distributed versioning system.  From the Git website:

Every Git clone is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server. Branching and merging are fast and easy to do.

The way I like to think of this:  every time you check out the project from the origin, you are creating a branch.  And all the development that you do on the project, every commit that you make, is committed only to that branch.  And when you’re satisfied with your changes, you push those commits to the origin.  Coming from Subversion and CVS, it feels like making a whole bunch of low-risk “micro” commits and then one great big giant commit to push all those changes back up to the central repository.

So what about branching then?  Well, I haven’t really done that yet.  Part of the reason for trying Git in the first place was because I was having a bear of a time getting branching and tagging to work properly under Subversion.  If I was wrestling that much with Subversion’s branching anyway, why not just Git a whirl?  Which is approximately where I’m at right now.  Again, each checkout feels like its very own branch.  Now, I’m at least smart enough to know that these are not true branches.  I’ll get there at some point.  But for now I’m just glad to be using a version control system that doesn’t bitch me out every time I try to commit a file.

While we’re on the subject…  Publishing/deploying projects has also proven to be much easier compared to the strategy I had going for Ortho under Subversion.  Under Subversion, I did my work, updated to resolve conflicts, made my commits, then SSH’d into my web host to re-checkout the project into its correct directory — and then hope that that did not introduce conflicts into the published version.  With Git, it seems like all of those conflicts are resolved cleanly and stay resolved once your changes pushed into the origin.  It seems to me that this because you resolve your conflicts in your distribution of the repository before Git will even let you push those changes into the origin.  At least, in my limited experience thus far, Git seems to politely decline when you try to do something unwise.  Anyway, my points is that you can feel about what is in the origin — that is nice and stable — so when you want to deploy, just go to the location for your deployment (e.g., in my example case $WORDPRESS/themes/ortho) and type: git pull git://github.com/founddrama/ortho.git

Bam.  A cleaner deployment there never was.

An exhaustive review?  Hardly.  Detailed and technical?  Not a chance.  Nevertheless, those are my (amazingly, uniformly) positive impressions of Git after spending about a week with it.

For other impressions on Git, try this write-up on Webdesinger Depot. And if you’ve decided to try out Git, do yourself a favor and download Zack Rusin’s Git cheat sheet post-haste.

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

First, the stuff that I did like:

1. The “lite” style previews that appear in the right-hand sidebar while editing CSS files.  That’s a nice touch.  (But what do you expect from the makers of CSSEdit?)
2. The default editor font (Espresso Mono) was actually pretty easy to read and by the time I got around to writing this, I realized that I never once considered switching it to Consolas (my fixed-width favorite of ’08 and ’09-to-date).
3. From the sidebar:  single-click to view, double-click to add it to the workspace.
4. The cold-folding interface was cool.  I wound up not using it that much, but I liked it.
5. MacRabbit’s clever little beta software graphic.

Stuff that took some getting used to:

1. The layout.  It took me a while to get oriented.  Especially since the toolbar just seemed so… sparse.
2. Dirty document indication.  My first reaction is to look for the darkened center of the main window’s red “close” jewel — and if the active document is dirty then this window jewel is dirty, too.  But if you have a dirty document that is not the active document, but the active document is not dirty, then the window’s close jewel is not dirty.  It took me a while to realize that I should also be looking for blue dots next to the files open in the workspace.  I feel like this needs some work still.
3. Workspace vs. tabs.  I like tabbed interfaces, so that’s my own bias here.  But it took me a while to get used to the idea that Espresso’s left-hand sidebar was home to all the files in the project and also all the open files in the workspace.  In light of my comments about the dirty file indicators (vide supra), I felt that this made it too easy to forget to save documents.  (Not that Espresso doesn’t prompt you on the way out…)  Anyway:  wasn’t sold on that aspect of the interface.
4. Codesense and auto-complete seemed…  incomplete?  Example, when editing a CSS file, Espresso felt compelled to suggest all the properties in the world — just start typing (“fo…”) and then hit down a few times and enter and suddenly font-family is there.  But then the actual values for these properties were not suggested, even when there was a finite number of responses.  Not recommending Lucida Grande when I’m entering font-family? Sure. But not suggesting visible vs. hidden vs. collapse for visibility? That’s not OK

Stuff I didn’t like:

1. Not enough “baked-in” syntax highlighting options.  Which shouldn’t have been a big deal because of the “sugars” and how easy it’s supposed to be to extend Espresso but…
2. …I found that it was not in fact very easy to extend Espresso.  Or perhaps more accurately, I invested entirely too much time trying to figure out how to get started writing a sugar or two of my own but it wasn’t clear.  I’m not even saying that I wanted it to be obvious but it just seemed like the documentation was buried and what little I found was poor.
3. The currently set syntax highlighting should not be buried in a menu.  That needs to be in the toolbar or in a status bar.  It needs to be immediately accessible.  Especially if your application is not “nesting” syntax highlighting.
4. Why can’t I preview my project’s images from within Espresso…?
5. The document mark-up tree in the right-hand sidebar.  At first I thought it was neat.  But eventually it just felt distracting and not terribly useful.

Overall grade?  B- — it’s pretty strong for its beta phase but I didn’t see anything terribly innovative or compelling.  Which was sad because I loved the name and the icon.

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.

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.

Now as a brief aside:  I have no intention of bending over backwards on this issue.  The site’s footer looks pretty shitty in IE6.  And probably for the same reason (viz. the floats) that the images do.  But the footer is way down there and generally not something that folks are spending too much time worrying about.  And so I’m spending no extra effort on the footer.  Though I, incidentally, believe that once I get this thing with the image floats figured out, the fix for the footer will seem downright trivial.

Now where was I?  Oh right, the float styles that are applied to the images.

This isn’t something that I made up on the spot back in March of ’07.  I did not pull these styles out of my ass.  I did what any smart coder would do:  I ripped it off from somewhere else — somewhere where I knew it to be working.

Now, there is the obvious argument that ripping off code from one place and dropping it into a new context is no guarantee that it will work the way that you expect it to.  After all, you didn’t write it, so you can’t very well say that you know all of what it’s doing.  What else does it depend upon? &c.

But let’s brush off that argument as irrelevant.  I understand these dozen-or-so lines of CSS well enough to know what they’re supposed to do, that they function well enough on their own without additional supporting code, and that I haven’t created any conflicts.

Or at least:  no conflicts that I know of.

In the screenshot above, the image has a class of alignright applied to it.  The “meat” of this class is as follows:

img { border: none; }
.post-body img, .post-body * img {
    margin: 0.25em;
    padding: 2px;
    border: 1px solid #666;
    max-width: 100%;
}
img, .alignleft, .alignright { display: inline;/*forIE*/ }
.alignright, img[align="right"] {
    float: right;
    margin-right: 0px;
}

Or so it was at the time I began my examination.  I did a couple of searches for IE6 float bugs and how to resolve them.  I found a lot of stuff about sidebars, three-column layouts, and the usual forum posts with the usual litany of complaints that either go unanswered or else answered by unhelpful trolls.  I did manage to find two interesting pieces but nothing that seemed to solve the problem I was experiencing.  I was already using the “it’s so simple, it’s almost stupid” display:inline fix so I felt as though I could safely assume that wasn’t the answer.  So I tried…:

1. adding clear:none to accompany display:inline (no luck)
2. adding width:auto to accompany display:inline (and though that partially helped with the otherwise unusually large size of next/previous links, I still wouldn’t call it a win)
3. adding width:auto and clear:none to accompany display:inline (no luck here either)

Leaving me pretty much out of ideas.  Baffling!  Everything I have found so far seems to suggest that setting display:inline is enough and (where it’s not) you probably just need to set a width (e.g., width:auto) and you’re good to go. The clear:none business was just me grasping at straws.

Any readers out there with ideas on this one?

UPDATE: In case you’re curious: (1) I also wound up removing the position:relative from #page and (2) the current state of the CSS applied to the img elements stands as such:

img { border: none; width: auto; }
.post-body img, .post-body * img {
    margin: 0.25em;
    padding: 2px;
    border: 1px solid #666;
    max-width: 100%;
}
img, .alignleft, .alignright { display: inline;/*forIE*/ }
.alignright, img[align="right"] {
    float: right;
    margin-right: 0px;
}

And again: ideas? Because I still can’t seem to track this down — despite trying to recreate this one from scratch by reverse engineering it. Such a dilly of a pickle.

Where do we stand?

As of this evening, and after lots of unacceptably bad best case scenarios described, the damage is relatively minimal.  Mail has been back solidly for a while; A.’s project seems to have escaped the outage with a little stress and downtime as its only casualty; this blog here has fared slightly worse.  Things seem to be back up and no data seems to have been lost but the WordPress admin app was curiously inaccessible at first.  Trawling the forums turned up a tip that recommended adding DirectoryIndex index.php to the root .htaccess file and though this appeared to buy us a ticket in, it’s horrendously slow to load the Dashboard page.  The only other thing that seems to help folks is a complete reinstallation.

Hmm…  I’d rather not.  Time will tell if I can live with the slow initial load or not.  I’m backing up my plugins, my custom theme, etc. in the meantime.

As for the hosting provider…  Dreamhost has been a pretty good value to date.  We pay next to nothing for what we’ve got through them and thus far the service has been good and the uptime tolerable.  What has me torn is that on the one hand, this inflammatory response appears in the comment thread of the related post of their system status blog:

…but it’s a comment thread so…  Really, that could have come from anywhere.  The official email response that went around was much better, talking about a full recovery of the data and a credit toward the effected accounts, etc.  Which does seem like an adequate response…  So again:  I guess we’ll see what happens.

In the meantime:  (1) Backing up and (2) any of you dear readers have any idea why that .htaccess trick would help but still jam things down to a creeping crawl?

But with OS X 10.5′s release, Automator got a few useful additions to make it a bit more useful.  In particular, support for variables added some flexibility that was previously impossible within the framework it provided.  So I decided to throw a little task at Automator:

Take my selected photos and export them to a folder on the Desktop called “4Uploadr” (and create that folder first if it isn’t already there).

Straightforward enough, eh?  So I dropped in two actions:

1. Aperture: Get Selected Images
2. Aperture: Export Versions
   • Destination: (Variable = ~/Desktop/4Uploadr)
   • Export Preset: JPEG – Original Size
   • Export Name Format: Current Version Name
   • Export subfolder: No folder…

Which I naïvely believed would do the trick.  Wouldn’t Automator know that if 4Uploadr didn’t exist that it was supposed to create it?  Nope.  It just quietly fails, recording in the Automator log that such a folder does not exist.  Alright, what about setting “Export subfolder” to “Custom”?  No, that only appears to output the selected images into a folder with the name “<untitled>”.  Perhaps there is a preference buried somewhere in there for setting “Custom” to “something useful” instead of “<untitled>” — but if it’s in there, I couldn’t find it.

Unsatisfactory!

So instead:  AppleScript to the rescue!

One of the variables that Automator now accepts/supports is an “AppleScript” variable wherein you set a script for Automator to execute.  In my case, I wrote a script to test for the existence of “4Uploadr” and the create it as necessary before exporting all those images from Aperture into it.

The AppleScript:

That’s:

tell application "Finder"
  if "Malkovich:Users:rob:Desktop:4Uploadr" exists then
    return true
  else
    make folder at desktop with properties {name:"4Uploadr"}
  end if
end tell

The Automator action:

Sure enough, it worked. It creates the folder if it’s not there, passes through quietly if it is there and then exports all the selected images from Aperture just like we would want. A little heavier lifting than originally expected but nothing too terrible.

(1) I love this plug-in.  Truth be told, I probably abuse it.  The right answer would be to develop a better writing style and use the footnotes only where they’re really needed.  The easy answer is: fuck that, I love my footnotes.

(2) Could we have the “opening” and “closing” syntax be a configurable option?  The defaults don’t work for me and I hate having to go back through the source code and fix this every time the plug-in requires an upgrade.  Seriously, there are so many other settings in the current version that this one seems the logical next step.

Give us a break?

That is all, thanks.

With the advent of Quick Look however, we are faced with a little bit of a conundrum.  Quicksilver is still the fastest way to locate and access those files but for many documents Quick Look provides a much faster way to view them.  And sometimes that’s really all that you need to do.  Spring open the document, scroll through it and find that one phrase or that one number or just confirm that it is (in fact) the document for which you’re looking.  So why add the additional 15-20 second wait while the Behemoth Application opens?  Quick Look provides an instantaneous glance at the contents.

It’s just too bad that Quicksilver does not provide us with a “Quick Look” action or command.  There certainly isn’t one built in.  The closest I came on my own was ⌘+Space ➟ type a few characters to find the document ➟ tab over ➟ “Reveal” ➟ and then hit Space again (this time in the Finder) to invoke Quick Look.  Faster than opening the Behemoth Application?  Yes.  But it still feels cumbersome, like it has a whole lot of extra steps.

Rather than research or experiment with alternatives myself, I let Google do the walking on my behalf and together we identified an AppleScript-based solution over at MacOSXHints.com.  Well, it’s sort of a solution.

The AppleScript as initially suggested references an external shell script.  Not ideal but it… works?  A clever commenter then re-factors the AppleScript to wrap the command line elements in a “do shell script” line.  Which is… better?  Both methods worked for me — though imperfectly.

First of all, both versions include the following line:

tell application Quicksilver to hide

Wrong because:

1. The application name needs to be wrapped in double-quotes to be valid: “Quicksilver”; and
2. “hide” is not valid AppleScript (if you compile the script, you’ll notice it turns green, indicating it’s now a variable).

Putting that minor gaffe aside, does it work?  Does it take the selected item and pass it to Quick Look?

Yes, but not without a delay.  A 15 second delay.  So we’re not really all that better off.  The other major sticking point (for me) was that we somehow manage not to give the system’s focus over to Quick Look.  So even after the delay, even after Quick Look brings up that spreadsheet or document or whatever, when I hit “Space” again, it doesn’t dismiss the Quick Look window, it does… what?  Well, the application otherwise active in the background captures that keystroke.  So you wind up with another space in the email you were composing or accidentally clearing out the values in that spreadsheet’s cell, etc.

Clearly this is non-optimal.

I attempted to author an alternative version of the script that appeared on MacOSXHints.com with some limited results:

An AppleScript-based Quick Look Action for Quicksilver.

Don’t bother asking why I didn’t just publish it in a copy/paste-able format because this isn’t really an improvement over the versions that appear at MacOSXHints.com.  What I “fixed”: use System Events to set Quicksilver’s “visible” to false.  What I tried to fix: in my experience, Quick Look appears to behave like an appendage of the Finder.  So I figured that I could tell application "Finder" to activate and that would give the space keystrokes over to Quick Look/Finder as expected.  But no.  Fail.  We still have a 15 second delay.  And we still can’t direct the spacebar keystrokes to Quick Look “where they belong”.

The quest continues?

High nerdery; join us.

Though the documentation is a bit thin at the moment, the core code is not too difficult to figure out and if you start with a straightforward example (like this one) then you can get a quick-and-dirty one going in about as much time as it takes you to write out the XML.

Considering that the community garden shut down for the season yesterday, I decided to experiment with the Simile Timeline API by building out one for our 2007 garden foray. Again, getting the initial events into the XML data file is super-easy (if a bit tedious); tweaking the JavaScript to get your timeline looking the way you want? That takes a bit longer… Most of the main variables (e.g., the height/width of the timeline) are well-enough exposed that a novice would be able to get it right with a few guesses. Customizing the theme and “zooming in” on sensitive “hot zones” however, that takes a bit more experimentation. That said, considering what I was able to accomplish in an afternoon (between loads of laundry), I must admit to being impressed with its relative simplicity — Simile Timeline is certainly an elegant solution for these kind of visualizations. Poking around on their site a bit, it seems I’ve just barely scratched the surface of its sophistication.