JavaScript Patterns

Web applications these days, am I right? With all their user experience and fancy A/B tests. It’s all thanks to JavaScript, or, more correctly, browsers and developers alike finally biting the bullet, putting a paper bag over the language’s proverbial head, and getting some good use out of it.

Analogies aside, JavaScript is not so great, but the experts have found ways to reclaim their software engineering integrity. Buried under metric tonnes of “Top 43 jQuery Plugins and Extensions for the Colorblind”, you might actually find such a beacon of knowledge. One of those beacons is a new book, JavaScript Patterns, by Stoyan Stefanov.

My copy is already getting dog ears.

A little bit of personal background, a couple years back I was starting to feel pretty comfortable with jQuery and even started writing my own extensions (not for the colorblind). I was also reading a new book, JavaScript: The Good Parts, by Douglas Crockford. Even though I strongly recommend it, JS: TGP raised more issues than it clarified. Sure, don’t use this and that part of JavaScript, but is that all there is, just a minefield of features, waiting to trip me up? Furthermore, many of those antipatterns he described really only became problematic in larger projects. Shouldn’t I be more concerned about confidently architecting and building those larger projects? I was unable to convince myself that JavaScript was a safe platform on which a very small team could build a stable product. (I even have an ActionScript 3 book from those days.)

Now, end of 2010, enter JavaScript Patterns. It aims to provide insight and best practices for teams who want to create a JavaScript product that won’t be hell to develop and maintain. And for the most part, it’s successful. Stoyan is an engineer at Yahoo, working on YUI, and just off the top of my head, he’s also written Object-Oriented JavaScript and a chapter in High-Performance JavaScript.

Pros

1. Really does deliver on holistic, well-justified JavaScript programming techniques that embrace the language.
2. Assumes the appropriate amount of JavaScript and CS knowledge, not too much, not too little.
3. Focuses mainly on JavaScript, not too much on the specifics of external libraries like jQuery. Libraries these days are big and numerous; a dedicated book for those would probably be more helpful. This one is library-agnostic and might even stay applicable longer.
4. Adequate treatment of server-side JavaScript. By which I mean, almost none. Similar to the library issue above, server-side JavaScript is still JavaScript. It’s also very volatile and most of the server-side-specific stuff is not unique to JavaScript.

Cons

1. Could give a little more focus to external libraries. I know I just got done saying that it was a good thing that it didn’t, but face it, almost everyone uses some external library. I think there’s a lot of general advice that one could give to allow developers to extract more from their library of choice while loosening any coupling that may occur along the way.
2. Lulls a bit in Chapter 6, Code Reuse.
3. The quote on the back of the book is probably the weakest bit.
   

   “Stoyan has written the go-to guide for JavaScript developers working on large-scale web applications.”

   Don’t get me wrong, it’s definitely my go-to guide (outside of good old Google), but the quote is from Ryan Grove, YUI Engineer. No offense to Ryan, but if you write a sweet book the publisher should try to hook you up with a quote from someone a little more prestigious than your own coworker.

And that’s all I have to say about that. For the time being, 8.5/10, highly recommended. It’s not very long and it really sets some precedents on which to build. For more study, I recommend you check out YUI Theater and follow some blogs. Ajaxian is great and all, but the real in-depth stuff comes out of projects and project contributors, check out Kangax’s blog (of Prototype fame) and Tim Caswell’s How to Node.

LESS and incron: CSS at its finest

less is, once again, more.

Web development is full of challenges. That’s my nice way of saying writing CSS blows. CSS is powerful, but at the cost of being too fine grained and low level for easy development. It’s like the assembly of web design. Other developers are all-too-aware of the situation and have come up with a few solutions, including CSS frameworks, which reduce the amount of from-scratch code and provide a system (e.g., Blueprint or the 960 grid system), versus the freeform mess of raw CSS, and CSS extensions, like LESS, which is the topic of the day.

Act One: L-E-S-S spells bliss

If you aren’t using something like this yet, you might as well be punching yourself in the crotch every time you code.

I have also messed with Sass, which was not as “Syntactically Awesome” as LESS, and xCSS, which was overkill (but I might revisit it later). LESS is good because:

• Any standard CSS file is a valid LESS file – easy to only use the features you need
• Just as powerful as Sass, offering variables, functions, nesting, CSS-specialized math operations
• Aptana CSS highlighting works great:
1. Go: Window->Preferences
2. General->Editors->File Associations
3. Add file type: *.less
4. Add editor: Aptana CSS Editor (right at the top)

I mean, look at this syntax:

@left_column_width: 300px;
@column_margin_width: 15px;

/** Palette **/
@light_blue: #d0dae3;
@pastel_blue: #7492ac;
@med_blue: #1e5d97;
@dark_blue: #0b3c68;

@light_orange: #f6b860;
@pastel_orange: #dfab62;
@med_orange: #e9951f;
@dark_orange: #a1630c;

/** Colors **/
@top_nav_color: @light_blue;
@top_nav_hover_color: @light_orange;
@header_color: @pastel_blue;

#header {
	clear:both;
	float:left;
	width:100%;
	border-bottom:1px solid @dark_blue - #111;
	background: @header_color;
	padding-bottom: 12px;
	margin-bottom: 7px;
	
	.page-title {
		float:left;
		clear:none;
		display:inline;
	}
}

/***** Two column layout a la   *********
****** http://matthewjamestaylor.com/blog/ultimate-2-column-left-menu-pixels.htm  *****/

/* column container */
.colmask {
	position:relative;
    clear:both;
    float:left;
    width:100%;			
	/*overflow:hidden;*/	
}

/* 2 column left menu settings */
.leftmenu {
    background:#fff;
	overflow:hidden;
	.colright {
	    float:left;
	    width:200%;
		position:relative;
		left: @left_column_width + (2 * @column_margin_width);
	    background:#fff;
	}
	
	.col1wrap {
	    float:right;
	    width:50%;
	    position:relative;
	    right: @left_column_width + (3 * @column_margin_width);
	    padding-bottom:1em;
	}
	
	.col1 {
	    margin:0 @column_margin_width 0 (@left_column_width + (4 * @column_margin_width));
	    position:relative;
	    right:100%;
	    /*overflow:hidden;*/
	}
	
	.col2 {
	    float:left;
	    width: @left_column_width ;
	    position:relative;
	    right: @left_column_width + @column_margin_width;
	}
}

Now you have an easily customizable two column layout and color scheme. Change your values in one place and they gracefully propagate. If you wanted to change the colors or column width before, you would have to change dozens of values. Really, stop what you’re doing, change your CSS file’s extension to .less, and become a happier person.

Act Two: Incron

So the only problem that I ran into is the bump in the workflow: compiling from LESS to CSS. This is where incron comes into play. Incron monitors files for changes and can trigger actions as specified by you with a cron-like syntax we can all love. I have a little Gentoo development box I use; I put incron on it and set it to run lessc whenever my LESS file changed. Just install/emerge incron, run incrontab -e and add one line:

	/path/to/less/files/mystyles.less IN_MODIFY lessc $@

Now you’ll have a file called my_styles.css and everything will be hunky dory. Of course this could easily be extended to do more powerful things with your styles, like move them into the right place or give them fancy names or version them or whatever. The potential here is also not limited to LESS, so consider it an investment. If this intrigues you, I think this tutorial should be all you need for now.

Well, web development is a big basket of ugly and this only addresses one aspect. There’s still cross-browser grossness and JavaScript debugging horror. But LESS helps. LESS helps.

SILT: bcrypt, IZZE, and burp edition

Delicious drank

• For all password storage, use bcrypt. Don’t use salted md5, definitely don’t use plain text. Also, don’t email users their passwords. The crypt() function in PHP actually has the blowfish algorithm alternative built in for versions >5.3.0, though you may want to set up the system libraries yourself, to allow for updates.
• I recently invested in some IZZE sparkling juice. It’s pretty much carbonated juice cocktails. There are a few flavors and I’ve tried the Pomegranate, Clementine, and Grapefruit. Cranberry’s cranberry, Clementine is ok, Pomegranate could taste more like pomegranate, but is still good, and Grapefruit is probably the best. Grapefruit’s a little too sweet, so I like to add some tonic water. For drinkers, these would probably be great mixers. I get mine on Amazon, where they go on sale every once in a while for like $15 for 24.
• Speaking of security and carbonated things, you’ve got to check out Burp Suite. It is an amazing application for security testing web applications. It automatically fuzzes apps. For the click-lazy, fuzzing is just providing wildly invalid data where only a computer could think to put it. As soon as I develop something security-sensitive, ya’ll know I’m buying this.

mplayer-fu

I am a big, corpulent fan of thesauruses and mplayer. Mplayer has about a billion command line options, as any respectable linux staple should. Unfortunately, I’ve had some difficulty tracking down some of the more useful options. For instance, I was looking for a way to trim a sound file from the command line.

With mplayer you can specify output devices, so the command to play a song through your speakers and the command to write a new file often differ only by the output specification. Where this comes in is that the command I was looking for is also useful for playing a segment of a sound file.

I googled around for “mplayer trim audio file”, “mplayer crop audio file”, “mplayer start end command line options” (to see if the ones I wanted were in the main list), and “mplayer start end positions”. I think I ended up going through my own shell history until I found the commands I used for creating GIFs from movies (like I said mplayer/mencoder is great). There I found the elusive -ss and -endpos command line arguments. Why ss is ss and not startpos, I don’t know.

Next time you’re looking to trim anything or play anything, use the following commands as a template.

mplayer -ss 16 -endpos 1:21:33 [additional options] [input files]

Note that ss and endpos have the same input specification. So you can go by number of seconds, or mm:ss, or hh:mm:ss. endpos is the number of seconds you want to capture/play, so ss=5 and endpos=10 will play the 10 seconds starting at the 5th second.

(Note here that I had some strange results on one file, but that could have just been mplayer.)

Anyway, I hope that was helpful. As a postscript, here are some other examples for you.

Create a trimmed wavefile from an input file, including ripping audio from video files:

mplayer -ss [time] -endpos [time] -ao pcm:file=output.wav [input_file]

If you want to trim a video, you’ll have to switch to mencoder. Don’t worry, ss and endpos still work:

mencoder -ss [time] -endpos [time] -ovc copy -oac copy -o mytrimmed.avi [input_file]

(There might be a way to do it with mplayer, but I don’t know how. This works fine though 🙂 )