Topic: Developer’s Notebook

OS X Productivity Tip : Keyboard Shortcut for Zoom

Osx_shortcut

Quick and easy tip: I find myself using Preview.app quite a bit to read documentation (in addition to normal development tools), and usually zoom the currently active window to fill up the screen. Using the mouse in this case gets fairly tedious, so I took to mapping this command to a keyboard shortcut. While the mechanism for doing this is nothing new on OS X (it's been around forever), few people seem to take advantage of it.

Mapping a keyboard shortcut to the Window->Zoom command (in Windows, this is uniformly accomplished via "Alt-Space + X") helps a lot to quickly zoom in/out of whatever it is I am doing, but many OS X applications do not map this command by default. Enter the Keyboard & Mouse preference pane. This single change happens to work with many applications (Mail, iCal, Safari, XCode, etc). I find "CMD-/" to be a fairly reliable and easy to remember mapping.

This is a screenshot of a section in the "SystemPreferences->Keyboard&Mouse->KeyboardShortcuts" preference pane. As you can tell, I generally don't customize my system that much, but this one is a no-brainer. Give it a spin and see how you like it.

Developer’s Notebook: Mastering (your fear of) regular expressions

Regular expressions are one of the most difficult programming concepts for novices and journeymen to wrap their heads around. Take a look at most any blog posting about RegExes and the comments will invariably be littered with words like "hate," "pain" and "AAAAARGH!"

Once you get comfortable with them, though, regular expressions become one of the most powerful tools in your programming arsenal. For Ajax/JavaScript developers, they can lend power and elegance to everything from form validators to keystroke interpreters to JSON, CSS and DOM parsers - in short, many of the thing you'll want to do on the client side of any powerful webapp. Take a look under the hood of any respected Ajax/DHTML library and you'll see RegEx literals being used liberally.

It's no secret that I'm big on programming books, especially O'Reilly ones, but I can think of few books that have been more useful than Jeffrey E. F. Friedl's "Mastering Regular Expressions". One difficult aspect of JavaScript regular expressions is their syntax, which is completely different from the better-known Perl variety. Friedl steps back from the implementation details of individual RegEx engines to explain the central concepts common to them all. After having this book for a year, I still refer to it so often that I can't say when I'll be ready to graduate to Tony Stubblebine's "Regular Expression Pocket Reference." In the meantime, when I'm away from my copy of the Friedl book, there are plenty of online resources to guide me.

Cheat sheets & quick references

These links don't offer really in-depth tutorials, but they do show you the JavaScript RegEx syntax at a glance.

Interactive terminals

Apparently, everybody and their mother decided to build a little DHTML/Ajax app to let you create regular expressions, run arbitrary text against them, and check out the results. This is a fantastic way to play with the technology and get more confident in your abilities. Here are 9 different implementations of the same basic idea. I haven't used all of them, so let me know in the comments which are most useful.

And for the over-achievers

For those of you so advanced in your RegEx powers that you've hit the limitations of the built-in JavaScript implementation, check out XRegExp, an open-source regular-expression library that supports named capture and other advanced features.

Technorati tags

Developer’s Notebook: Forward-thinking CSS float-clearing

The art of float-clearing - getting containers to honor the height of floated elements inside of them - has slowly evolved over the past several years as Safari has taken over many Mac desktops, IE5/Mac has atrophied, IE7 has slowly caught on, and our use of CSS filters has improved. I'd like to share a slight variation on the state of the art that I believe makes for much cleaner markup. But first, a little background.

How we got here

Several years ago, Tony Aslett of csscreator.com convinced us to stop using clearing our floats using this sort of junk markup:

<div id="container">
   <div id="rail" style="float: left;"></div>
   <div id="content" style="float: left;"></div>
   <br style="clear: both; height: 0; visibility: hidden;">
</div>

His solution, popularized on Position is Everything, convinced us to use pure CSS to solve the problem:

.clearfix:after {
    content: ".";
    display: block;
    height: 0;
    clear: both;
    visibility: hidden;
}

.clearfix {display: inline-block;}

/* Hides from IE-mac \*/
* html .clearfix {height: 1%;}
.clearfix {display: block;}
/* End hide from IE-mac */

<div id="container" class="clearfix">
    <div id="rail" style="float: left;"></div>
    <div id="content" style="float: left;"></div>
</div>

The advantage, of course, was that you didn't have to litter your markup with extra <br /> tags that would eventually become totally useless once the state of the art changed.

Where we are now

For sites that have dropped support of IE5/Mac and adopted support of IE7, the recent concensus on float-clearing has been something like this (using the same markup as above):

/* float clearing for IE6 */
* html .clearfix{
  height: 1%;
  overflow: visible;
}

/* float clearing for IE7 */
*+html .clearfix{
  min-height: 1%;
}

/* float clearing for everyone else */
.clearfix:after{
  clear: both;
  content: ".";
  display: block;
  height: 0;
  visibility: hidden;
}

And now, a slight refinement

Which leads me to a technique used at Orbitz, my previous employer, to apply the same methodology with even less impact on the markup itself. Instead of declaring a single clearfix class and then applying it to countless containers inside their XHTML, the Orbitz UI team uses a grocery list of CSS selectors, like this:

/* float clearing for IE6 */
* html #container,
* html .classThatNeedsToBeCleared,
* html div.anotherClassThatNeedsToBeCleared,
* html #someDiv .someClass .yetAnotherClassThatNeedsToBeCleared{
  height: 1%;
  overflow: visible;
}

/* float clearing for IE7 */
*+html #container,
*+html .classThatNeedsToBeCleared,
*+html div.anotherClassThatNeedsToBeCleared,
*+html #someDiv .someClass .yetAnotherClassThatNeedsToBeCleared{
  min-height: 1%;
}

/* float clearing for everyone else */
#container:after,
.classThatNeedsToBeCleared:after,
div.anotherClassThatNeedsToBeCleared:after,
#someDiv .someClass .yetAnotherClassThatNeedsToBeCleared:after{
  clear: both;
  content: ".";
  display: block;
  height: 0;
  visibility: hidden;
}

<div id="container">
    <div id="rail" style="float: left;"></div>
    <div id="content" style="float: left;"></div>
</div>

The idea here, of course, is that each time you have another container that needs to be cleared, you add browser-specific selectors for it to each of the three blocks above. Suddenly, there's no need to apply a utility class to a zillion different nodes in your HTML. Instead, you apply the same CSS rules to a bunch of atomic CSS selectors. Voila: float-clearing with absolutely no impact on markup. Presto: a solution completely centralized in a single block of CSS code, so that it can be changed in one place as the browser landscape evolves.

(Props to Gena Wilson, Orbitz's CSS headmistress extraordinaire, for constantly synthesizing elegant solutions like this one.)

Final side note: As long as folks are going to keep griping about missing items from their CSS wish list, could we please just eliminate the need to clear floats altogether? I know that the need to clear floats isn't actually a bug, according to the WC3, but it should be. I can't think of a single time I've ever _not_ needed to clear my floats. Can you? Tell me in the comments.

Developer’s Notebook: Useful OO JavaScript resources

My post about learning to organize classes without the semantic sugar of Prototype earned me some wide-ranging comments here and on Ajaxian. My favorite was Isaac Z. Schlueter Matthew Smith's proposal of a new framework: JLJ (Just Learn JavaScript). To that end, I thought I'd compile some of the most useful sites and posts I've come across in my quest over the last couple of years to employ better inheritance strategies in my JavaScript.

Let's face it, in the wide world of web development, for every
dedicated client-side developer with a real taste for JavaScript, there
are 10 Java middleware developers who believe that JavaScript isn't a
"real" object-oriented language. Programmers with a broad range of
experience in a wide array of languages will argue that JavaScript's
loose typing, dynamic nature and prototype-based inheritance scheme are
actually far more "object-oriented" than, say, Java or C++. That may be
true, but there are lots of folks out there writing production code who
have never written complex software using any language _but_
JavaScript. For these folks, myself included, JavaScript's dynamism is
both a blessing and a curse. There's a lot of freedom, but not a lot of
guidance. Languages that rely on good developer
behavior rather than the intrisic properties of the language themselves
can be dangerous. Just enough rope to hang yourself, and all that jazz. For those of us whose primary language is JavaScript, a little structural guidance can help a lot.

As the inestimable Douglas Crockford illustrates in Classical Inheritance in JavaScript, the main benefit to inheritance in a dynamic language is re-use. Most of us are interested in getting the most mileage possible out of every line of code we write. Many JavaScript frameworks enforce or encourage a particular method of doing this; most are modeled on the classical inheritance schemes of other languages. Every serious student of JavaScript should learn the strengths and weaknesses of these patterns - and how to implmenet them on the fly, without a framework to fall back on.

A note on this list: It's a highly subjective smattering of articles I found useful. Some are high-level discussions of JS itself, or of inheritence strategies in general. Others grapple with the interitance models of specific libraries in ways that highlight the underlying issues. I could post a completely separate list of JS/Ajax frameworks and their various approaches to the topic. But that's a different post for a different day.

On to the list:

Inheritance Strategies

Closures, the Global Namespace and the Module Pattern

Singletons, Lazy Constructors and Memoization

Further Reading: DSLs, Aspect-Oriented Programming and More

Launch: Pathfinder Newsletter

    Get a monthly update on best practices for delivering successful software.

    Subscribe via email


    Subscribe via RSS      RSS icon

Topics

Search

WordPress

Comments about this site: info@pathf.com