found_drama

CSS. Verbose, repetitive, rife with bizarre quirks.

Can’t say that I’m a fan. On the web, you’re using it out of necessity. Even the CSS masters out there must admit, there has got to be something better.

Fortunately, there’s Sass. A super-set of CSS, it helps to eliminate some of CSS’s most obnoxious aspects during the development lifecycle. By way of example, my ten favorite parts about Sass:

1. Nesting. Let’s get the most obvious one out of the way first. You know how CSS makes you write stuff like this:

   #container .post code,
   #container .post tt,
   #container .post pre {
   	font-family: Consolas, Courier, monospace;
   }
   

   Well, Sass will lets you do that like this:

   #container .post {
   	code, tt, pre {
   		font-family: Consolas, Courier, monospace;
   	}
   }
   

2. Nesting. Again? (you say)—check this out. Whereas CSS would require this:

   .styledText {
   	font-family: Georgia, Times, serif;
   	font-style: oblique;
   }
   

   In Sass you can do this:

   .styledText {
   	font: {
   		family: Georgia, Times, serif;
   		style: oblique;
   	}
   }
   

   More lines perhaps, but it feels less verbose. And more manageable.

3. Includes. CSS already has this notion of an @import rule, and while Sass overrides borrows the directive (with a twist on the exact syntax), it goes a step further. While the CSS @import results in an extra http request for the imported stylesheet, Sass will auto-concatenate the files—getting the request down to one. (And as a side-benefit, reducing your CSS build/deploy phases down to just calling Sass on your scss file(s).)

   /* CSS: */
   @import url("_reset.css");
   
   /* Sass: */
   @import "reset";
   

4. Variables. Totally missing from CSS, Sass brings these to the table. Observe:

   $theme_accent: #771100;
   $theme_bg: #222222;
   
   #container {
   	h1, h2, h3 { color: $theme_accent; }
   	.post {
   		border: {
   			$accent_border: 1px $theme_accent;
   			$dark_border: 1px $theme_bg;
   
   			top: $accent_border;
   			left: $accent_border;
   			bottom: $dark_border;
   			right: $dark_border;
   		}
   	}
   }
   

   Need I go on?

5. Line comments. Again: // need I go on?
6. Mixins. Like variables on steroids. The Sass site’s example is great; I’ll reproduce here:

   @mixin rounded-top {
   	$side: top;
   	$radius: 10px;
   
   	border-#{$side}-radius: $radius;
   	-moz-border-radius-#{$side}: $radius;
   	-webkit-border-#{$side}-radius: $radius;
   }
   
   #navbar li { @include rounded-top; }
   #footer { @include rounded-top; }
   

   And did I mention that you can set up your mixins to take arguments?

7. Validation. This shouldn’t be hot shit, but it is. If you’ve been screwing around with CSS long enough, you’ve likely run into a situation where some rule you’ve written isn’t taking and you can’t figure out why and it turns into a two-hour wild goose chase only to discover that you fat-fingered border as boarder or failed to close a curly bracket or some such thing. Your IDE might be warning you. But Sass goes a step further and puts the error message right into your page—right there at the top where you can’t ignore it. (It’s also a useful error message.)
8. Auto-minification. This is right up there with, and arguably part of Includes. Either way, depending on how you have your Sass compiler set up, you can have it crunch the CSS output, stripping all comments and extraneous whitespace^[1].
9. SassScript functions. As if the variables and mixins weren’t enough for you, there’s also a whole host of hot functions and operations that you can perform in “SassScript”. For example, Dan Rubin recently Tweeted:
   

   CSS needs to allow me to write: * { saturation:+15%; }

   And of course, Sass has almost exactly this:

   $my_color: #77110;
   .post-title { color:  saturate($my_color, 15%); }
   

   …and a whole bunch of other color functions. Among other functions.

10. Directives, control statements, and other functions. Maybe just more of the same from the SassScript functions above, but damn is there some great material here.

    article {
    	$base_font_size: 12px;
    	$base_line_height: $base_font_size * 1.5;
    
    	font-size: $base_font_size;
    	line-height: $base_line_height;
    
    	/* simple math */
    	h1 { font-size: $base_font_size * ($base_line_height + 1em); }
    	h2 { font-size: $base_font_size + 4px; }
    }
    
    /* some looping with conditional logic */
    @for $i from 1 through 10 {
    	#flickr_badge_image#{$i} {
    		@if $i % 2 == 0 {
    			color: 3993FF;
    		} @else {
    			color: #ff1c92;
    		}
    	}
    }
    

All this amazing power… and I have just been casually exploring Sass over the past couple days. This project is a treasure trove and I hope that it is here to stay. My hat is off to the folks working on Sass. Marvelous work.

1. Granted, your mileage may vary on the download time savings from this kind of minification in a CSS file. After all, provided that you’re stripping your comments from your production CSS, most the file’s trivial bytes are whitespace and gzip basically does away with that overhead. [↩]

In preparation for an up-coming post^[1], I did a bit of extra legwork on syntax highlighting plugins for WordPress and wound up switching from Google Syntax Highlighter for WordPress (GSHW)^[2] to SyntaxHighlighterPro. Both of them are backed by Alex Gorbatchev’s Syntax Highlighter library. But more on that in a moment.

What prompted the switch was the fact that I noticed that GSHW was mangling some CSS syntax highlighting operations. The regex used to grab hex colors was getting greedy and highlighting #id-selectors as if they were colors^[3]. After a little digging, I came to discover that GSHW was using a quite-out-of-date version of Gorbatchev’s library.

Exploring the Syntax Highlighter site a bit, I found a couple of other plugins that appeared to be more up-to-date. I gave a crack at SyntaxHighlighter Evolved and the above mentioned SyntaxHighlighterPro. Both had more recent versions^[4] of the library baked in. Both seemed a step up in that regard, but I went with -Pro because it was going to require the fewest tweaks and changes^[5] in the code samples already posted^[6] and also because its control panel offered the ability to toggle specific syntaxes at will.

That said, the “Evolved” plugin has a nice suite of options.

This is likely just a temporary stop-gap measure, however. I may pull the plug on the plugins and just drop in Gorbatchev’s script directly—the latest version appears to offer on-demand loading of the “brush” scripts. Combine that with a minified version of the script and that may prove a better overall solution than the plugins can offer.

Nevertheless, the problem remains that the CSS highlighter “brush” script needs some work. It doesn’t really seem to recognize common selectors (#id and .class selectors, I’m looking at you)… and this bugs me.

But until then…

1. Quite likely the next post… [↩]
2. Which I’ve been using for a few months now. [↩]
3. Meaning that it was only coloring the hash and the first six characters of #container. [↩]
4. Though neither was using the most recent version. [↩]
5. I.e., it more gracefully relented to my efforts to kludge in the AppleScript and Sass support. [↩]
6. I.e., -Pro recognized the <pre> formatted blocks whereas Evolved was going to require changing all those to use BBCode-style [bracket] syntax. Ick. [↩]

Following up on the Google JavaScript Style Guide that made the rounds recently: I did a couple of passes through the document and absorbed as much of it as I could^[1]. After discussing the style guide with a few peers, I thought that it might make sense to provide some annotations—in part for personal reference^[2] but also to engage in the dialogue. There are a few implicit points in there that I thought might be interesting to pull together. And I also felt comfortable indulging in the hubris of splitting hairs.

And so, without further ado: an annotated guide to the Google JavaScript Style Guide:

Read the rest of this entry »

1. Nutshell version of my reaction: Well that all seems like common sense, just spelled out rather eloquently; but I’ll be damned if you want me give up my double-quotes. [↩]
2. To aid with digestion. [↩]

In the realm of technical, programming-related, computer science-type books, The Joy of Clojure is a bit of an oddity. And this is a very good thing.

WHAT THE BOOK IS NOT: The Joy of Clojure is not a beginner’s introduction to the language. The Joy of Clojure is not a glorified appendix of methods and syntax. The Joy of Clojure is not a “cookbook” or a “how-to” or an “FAQ”. The Joy of Clojure is not an explanation on how to shoe-horn your Java code into (some (graceful [parenthetical syntax])). The Joy of Clojure is not a dry or sterile technical manual.

WHAT THE BOOK IS: The Joy of Clojure is as much a philosophical text as it is a survey of the language. The Joy of Clojure embraces the language’s own flexible nature and describes itself in that way. The Joy of Clojure has a sense of humor. The Joy of Clojure expects a little work from you (but is willing to lend a hand along the way). The Joy of Clojure respects the baggage that you bring from your other programming languages, but expects you to check those bags at the door. The Joy of Clojure wants to make you a better programmer, not a Clojure programmer.

Rating? ★★★★☆

So… why 4-stars? I seldom give out 5-star reviews—I reserve those for books that completely blow my mind. While this one was a real eye-opener, my lid did not pop fully and totally off. Why not? Partly because I’m coming into Clojure as an outsider. It isn’t a book for Clojure beginners—you could be a Clojure novice and get a lot out of this book, but I believe you would need a little more background in Lisp^[1]. How to get that 5th star…? A “chapter 0″ for the complete novice? or maybe an appendix that can help that novice wade through some of the more esoteric-feeling elements of the language.—i.e., folks such as myself that are unfamiliar with Clojure (and/or Lisp in a more general sense^[2]) may find the language’s syntax a bit… opaque? oblique? There’s a learning curve with every language, I suppose but there are certain things in Clojure that look FUNDAMENTALLY WRONG to someone accustomed to a language like JavaScript or Java. The onus is (of course) on the reader to embrace these things (i.e., “Who is the one that opened the book and wanted to learn something new?”) but it’s sometimes easy to get lost in these little details.

I would absolutely recommend this to anyone I know that had an interest in Clojure and/or functional programming.

1. Lisp’s syntax can be a bit off-putting to outsiders and novices… and the authors even come out and say this in the book. [↩]
2. Viz., I haven’t looked at/used Lisp in probably… 10 years? [↩]

…but I’d feel remiss for not saying anything at all.

I first caught wind of Google’s JSConf.eu scholarships-for-females program in a roundabout way. I had just started following Rebecca Murphey’s posts^[1] when I saw this tweet.

At first I thought very little of it but after seeing Nicole Sullivan’s and then Murphey’s more in-depth posts, I followed through to the rest of the thread.

1. Personally, I’m strongly in the camp the Google is doing the right thing with these scholarships. These sorts of scholarships exist all over the place, targeting all kinds of specific groups. If we^[2] are going to grow as a community, we need a broad range of voices. Sometimes the best way to get those voices is to give them a boost on the way up.
2. I feel like this thread of discourse comes up at least once a year. Every time that it comes up and someone cites that we are far from a 50/50-male/female mix in our professional community, I think “there must be some perfectly logical explanation for this” and almost always, when you look at it logically, the sad truth is that sexist pressures drive women out. I don’t know what is going to change this, but it needs to change.
3. To the women that have spoken up about this; to the men that have come to their support; to Google for inadvertently starting this year’s furor: thank you.

The politics of this subject are complicated and subtle; that doesn’t help. But we can help ourselves to make this a vibrant and productive community by speaking out and speaking up—even if it’s just in some small way^[3].

1. In a bit of an ironic twist? What with this women-in-tech thread getting going at around the same time that I start following the blogs/posts of several women developers. [↩]
2. ”We” here being web developers; but really “we” could be “any community”. [↩]
3. It’s a start, eh? [↩]

Despite the carpenter’s advice about the hammer, I continue my search for an exemplary satisfactory IDE^[1]. The most recent experiment was with JetBrains’ WebStorm^[2].

The short version: I wanted to like it…

First, what I did like:

• It seemed fairly forgiving — which is to say that it did not try to coerce me into creating projects just so I could open up a few directories and files. I could just randomly open directories as if they were projects etc. and I did not need to fuss around with VCS integration etc. This is not to suggest that any of the other editors and IDEs require this^[3] but at least here was easy and (more so) immediately obvious how to do this.
• Code-folding seemed well implemented. It had a good sense of scope and would let me fold down just portions of a method, or just one branch of an if statement, etc.
• The code-sense/auto-complete features are great. When they work, and disappointing when they don’t (see below).

What I was iffy on:

• The code-sense. Sometimes it seemed to have suggestions… sometimes it has no idea what I was typing. Sometimes it would have indexed my project files and made suggestions based on them. Rhen the next time it had amnesia. And so it goes.

And finally, what I did not like.

• Come on guys. That icon is lame. I could get over that but…
• It often forgot the files related to a given project. When I did set up a couple of repos as projects, WebStorm seemed to “forget” what was in it about half the time. References to related files would be missing — e.g., it would open the previously open files as tabs but the snapshot of the filesystem would be missing from the Project inspector.
• It seemed slow and sluggish. It was not exactly crashy, but on more than a few instance, it would completely lock up my machine for several minutes. Perhaps it was a thread hog? On at least one instance, I noticed in the OS X Activity Monitor that it was using more threads than any other process except the kernel (also: it was using a ton of memory). The cause? Maybe, maybe not. But it was an awful coincidence that its resource consumption would be so high right around the same time that the rest of the system was pegged.
• And while we’re at it: I gave up trying to get the colors/syntax highlighting “just right”. (I like a dark blue background with light text; thanks for only bundling black-and-blue-on-white.)

I wish the JetBrains guys good luck with WebStorm. I know tons of happy IDEA users and I gave WebStorm a try following their recommendations. But this one did not work out for me.

1. As I have not written about this before, the short version: jEdit is like a hand-me-down car; Espresso got a B- for not being mature; I love TextMate as a quickie text editor but it’s hardly an IDE; and (for better or worse) lately I keep coming back to Aptana. [↩]
2. Apparently, not to be confused with Brightidea’s Webstorm. [↩]
3. At least, I haven’t tried one that does. [↩]

Inspired by some recent entanglements with a vendor’s API:

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^[1] 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^[2].

1. And therefore you get what you deserve? [↩]
2. And by that I mean: Don’t be one of the ones writing it. [↩]

In case you haven’t heard yet—Flickr is rolling out a new photo page (pictured here) and I must say… It looks great. Congrats to the team that worked on this, they did a hell of a job.

A few notes that I pulled together from playing around with it this week:

• The lightbox mode is gorgeous.
• Many of the actions previously available as buttons just above the picture are now inside of an “Actions” menu. This consolidates them and I think that for most folks it will make more sense—the menu has a little better contrast than the previous action buttons: a slightly darker color, a border, a disclosure arrow… Overall, I like this improvement.
• That said, certain adjustments seem a little bit too buried. Example: there is not easy (i.e., one-click or even “two-click”) access to adjusting the photo location. This is a big one for me^[1] because I tweak these all the time. In this particular case, it wasn’t too tough to figure it out. When I did not see an “adjust this location” link under the map, my first instinct was to click on the map. That was close… You have to click on the map, then click “Edit location” on the thumbnail, then drag/drop the thumbnail, and then you can adjust the privacy settings and save your adjustment. So not too bad—but it does seem like a few extra clicks.
• I’m still getting used to the whole “title under the photo thing”. It doesn’t seem wrong or incorrect, but I’m also not accustomed to it yet.
• I haven’t seen this promoted too much but… new “Medium” size! It used to go Small (240px on the longest side) ➝ Medium (500px on the longest side) ➝ Large (1024px on the longest side); now there is a “Medium 500″ and an additional “Medium 640″ (640px on the longest side). Convenient.
  

Lastly, I saw the following comment on Facebook attached to the post announcing the new photo page. The guy wrote:

…I find it ironic that Flickr has finally moved to a larger page layout as smaller screens have started to regain popularity.

I definitely disagree here. Smaller screens are more popular now? Which smaller screens are we talking about here? Netbooks, and/or mobile devices? Both have become more popular and mobile devices are becoming ubiquitous at this point, but it would be a huge mistake to design for the lowest common denominator. And by “lowest common denominator”, I’m definitely talking about the netbooks. Mobile devices have already gotten first-class treatment by Flickr; if you haven’t seen it, check out m.flickr.com. It’s a great mobile-optimized site and if I’m not mistaken, the new Flickr “main” site certainly took quite a few cues from the mobile site^[2]. So though smaller screens are more common now, I think it’s because devices with small screens have become popular—but that said, most folks probably won’t choose to “go deep” with Flickr on a netbook. And even if they do, I’m sure it will still look just fine.

1. Two reasons there: (1) the iPhone’s geotagging often needs to be moved because they’re often miles off and (2) although I want my default visibility for a photo’s location to be “everyone”, I also lock down many of them to be “Friends & Family” only (even if the photo itself is visible to everyone). [↩]
2. E.g., putting the title beneath the photo. [↩]

Because I have developed some sort of weird obsession with this particular niche product in Apple’s line-up, a couple of quick notes about the newly announced Mac mini:

1. Putting the SD card slot on the back seems… well, that seems wrong (but the ports etc. were always on the back, weren’t they?);
2. wouldn’t this be the first time that “the foot” of one of their machines is given a high-profile product shot on the landing page?;
3. thanks for putting the memory in an easy-to-reach place this time, guys;
4. built-in for-reals HDMI FTW;
5. looks overall like a nice upgrade from the last round and I would like to have one in my living room.

Have you ever wanted (as an object-oriented JavaScript developer) to work with an object before you had an instance of it? For example, perhaps there’s a method that you would like to call without going through the overhead of instantiating the object^[1]. How would you go about doing this? Can you invoke myWidget.doSomeStuff() if you don’t have an instance of myWidget yet? Do we have static methods in JavaScript like we do in (for example) Java^[2]? (HINT: the short answer is “not exactly”.)

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^[3]. 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^[4], 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^[5]—and all without creating an instance of a given class until it is needed^[6]. Marvelous!

But this approach is not without some dangers^[7] 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^[8]. You can^[9] 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^[10] 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. …only to find out that it’s not even the right object for the task! [↩]
2. For the record, I’m a Java neophyte; this is the comparison explained to me, and the one that makes sense. [↩]
3. But now we’re just talking “best practices”. [↩]
4. I won’t go into prototypal inheritance and the various JavaScript constructor patterns here—it’s too big of a subject for this footnote (or even this particular blog post). However, may I recommend familiarizing yourself with “parasitic combination inheritance”, which you may recognize as the extend() method from frameworks such as Ext JS or YUI. For a great overview of inheritance and constructor patterns, may I recommend chapter 6 of Nicholas Zakas’ Professional JavaScript for Web Developers [↩]
5. We’re (of course?) assuming here that there is a 1:1 binding relationship between editors and widgets for the sake of this example. [↩]
6. Granted, in this example, there still needs to be some apparatus in place to manage calling the inspector method from each prototype (bringing us right back around to the “global function and/or namespaced util” question) but depending on the specifics of the implementation, there’s actually an opportunity to cache or curry the results from the inspection. And/but this is not at all to diminish the huge advantage you get from having the class’ method actually on the class; everything you need to know about the class is that it exists (and it takes care of the rest). [↩]
7. As many JavaScript developers have discovered by their “journeyman” stage, messing around with the prototype of a given object is not for the faint of heart. [↩]
8. That is to say, if you think this is an instance, then you’d be mistaken—and you’d be missing the whole point of trying this method in the first place. [↩]
9. …and for maximum effectiveness probably should. [↩]
10. But when aren’t the arguments important…? [↩]