Set your project accounts (it's OK if you only use one host) then optionally set the appropriate filters - in my case my Google Code projects were prefixed with adamdotcom and I had duplicate projects on both GitHub and Google Code. By specifying remove:adamdotcom,remove:duplicate-items in my filters I filter out the duplicates and removed adamdotcom from the project name.

The title of Jeffrey Zeldman's book (Designing with Web Standards) says it all - this book promoted accessible, usable, search engine friendly web design and development through the use of XHTML and CSS while debunking the myths surrounding web standards. Zeldman is a well recognized name among web developers and designers - he's the the founder of A List Apart, and co-founder of The Web Standards Project (WaSP). His writing is entertaining, witty, easy to read, and insightful - it's very much like the content we're used to reading at A List Apart. It's also fair to mention that this book has been edited by industy experts and influencial writers like Eric Myer. Any developer that works with the web should read this book along with JavaScript: The Good Parts by Douglas Crockford.

Jeffery Zeldman offers this entertaining definition for Divitis and Classitis:

Classitis is the measles of markup, obscuring meaning as it adds needless weight to every page. The affliction dates back to the early days of semi-CSS-capable browsers and the many designers' initially childish comprehension of how CSS works.
Alas, many have not yet outgrown that childish misunderstanding of CSS ... Classitis is as bad in its own way as the <font> tag ever was; rarely does good markup require it ... At other times classitis is exacerbated by a still more serious condition ... divitis ... Classitis and divitis are like the needless adjectives with wich bad writing is strewen. They are the weeds in the garden of meaning. - Jeffrey Zeldman, Designing with Web Standards

An example of markup wraught with divitis and classitis:13 div elements and 11 classes for a single item. What a stench! :) View this markup in action.

The equivalent markup disease free:Cleaner, more meaningful, and with all the functionality of the former code. One div element and 3 classes for a single item. ShamWow! View this markup in action.

Both of these markup snippets are visually and functionally equivalent. In the first example the divs, classes, and cryptic ids weigh down the page and pollute the meaning of the markup. In the later, a more semantic / structural approach is taken Both these snippets were pulled from my attempts at the Google Web Developer Exercise.

Clean meaningful markup is the API that users and web crawlers consume - it's important and easy to keep things clean, it just takes a little experience. Thank goodness for patterns like MVC that let us control our API (the markup).

I always found the definition of "Semantic / Structural Markup" murky on the intertubes. I thought Jeffrey Zeldman described it well in his book Designing with Web Standards.

What Is Semantic / Structural Markup?

Markup is "semantic" when tags are chosen according to what they mean. For example, tagging a headline h1 because it is the most important headline on the page is a semantic authoring practice. Tagging a headline h1 "to make it look big" is not. ... I use the phrase "structural markup" to mean pretty much the same thing as "semantic markup." ("Structural markup" takes its name specifically from the idea that the web document has an outline-like structure.) - Jeffrey Zeldman, Designing with Web Standards

Zeldman goes on to make many great points on why semantic markup matters, here's my paraphrase.

A couple years ago I tried getting a Web Developer position at Google. After a few interviews they had me complete their Web Developer exercise. I did it, and my initial submission would have made any respectable web developer ill - you can read more here: Getting a Job at Google: A Web Developer Fizzbuzz. I redid the exercise over a year ago, but today even that code stink.

I did the exercise yet again (the third time) because my last attempt needed some improvements:

it performed poorly and wasn't accessible (everything was being rendered in the DOM, there was no immediate rendered markup which kind of violated the idea of unobtrusive JavaScript, nor was it screen reader friendly)

it wasn't making use of any JavaScript libraries to abstract browser inconsistencies out of the code

it suffered from my software ethnocentrism (my variable and object naming like GoogleExercise was mirroring statically typed languages and not the native language they were being written in)

Here's my latest Google Exercise (addressing all the above concerns):View this post outside your RSS reader to see it in action or view it here.

This attempt makes use of jQuery and uses 57 lines of JavaScript (almost 200 lines less from my last one).

Most languages and technologies used in web applications come with their own unique naming conventions - which is unfortunate, but necessary, because diversity is important. Languages like JavaScript and PHP use camelCase, CSS uses-hyphenated-delimiters, and ASP.NET / Java / and the like adhere to the conventions used in their respective libraries and frameworks. Managing the different naming conventions in a web application can be difficult, but with discipline, embracing each language's conventions can provide some great benefits.

A common mistake I've made in the past, was trying to make all languages adhere to a single convention. As a budding PHP / ASP developer I took the-single-convention-for-all-languages approach. In retrospect, I used this approach because I didn't completely understand the language I was using, and in order to compensate for this lack of knowledge, I'd try to meld the languages into the mental model I understood best. This was a mistake.

Today, I find that working with the conventions of the language facilitates re-use (experts in the language understand what I'm doing), promotes portability (modules can be used across projects regardless of server-side technologies), encourages global collaboration (open source modules and plug-ins can be easily consumed and contributed to), and helps to a nurture a more maintainable application (developers from other language domains can easily maintain the application with a relatively small learning curve). Like a carpenter working with fine material, I embrace working with the grain of each language. It's also fair to mention that breaking free from the monocultured (one-size-fits-all) approach to naming conventions provides a broader perspective, and also makes your development skills more universal - it might even open the door to different development domains in the future.

Then there's the discussion on name length, verbosity, and using meaningful names. Steve McConnell suggests that the optimum name size for a variable or function is between 8 and 20 characters (Chapter 11, Code Complete), but with tools like ReSharper (for renaming / refactoring etc...) I find myself using names well over 30 characters. So names like GetApproveeTotalFromNamedBasket are a common occurrence in my code. However, like most things, verbosity does need balance (everything in moderation right?). In the business layer, descriptive names are a godsend - they jog my memory as I rediscover what the module I wrote last month was supposed to do. But... in the presentation layer languages (like JavaScript, CSS, ASP.NET, or XHTML) you may want to reconsider using long descriptive names. Since verbose, long running descriptive names in the presentation layer are passed over the network and can degrade performance. Often times these verbose names are combined together - throw in ASP.NET name mangeling, start hooking in verbose CSS definitions, and then start inserting JavaScript events. All this compounds quickly and result in large page payloads filled with elements like the following:

Note: That mess of code above would fire a JavaScript event then an ASP.NET event. It's the result of placing an ASP.NET LinkButton, inside a Repeater, inside a Panel, inside a Masterpage, and adding a JavaScript event along with some CSS. We can see that using long names in the presentation layers results in a mess of text. It's also fair to mention that the ASP.NET MVC Framework lets developers write cleaner presentation code.
Sure, everyone cites premature optimization as the root of all evil, and we do live in a world of gzip file compression and JavaScript minifiers. But... keeping names short in CSS, ASP.NET, and XHTML isn't hard as long as you're mindful of the final goal. Smaller names in the presentation layer will reduce the amount of data transferred over the network which increase the performance of the application.

My preference (project requirements warranting) is to keep things short and concise in the presentation languages while using longer descriptive names outside the presentation languages. What's your preference?

Weighing in at 140+ pages of content, JavaScript: The Good Parts [Douglas Crockford] cuts through the obscurities, pleasantries, and filler found in most technical books. Instead, this book dives straight into the heart of the JavaScript language. It presents the clearest comprehensive explanation of what makes JavaScript a great programming language that I've encountered to date. It nails the important concepts, like JavaScript's: object oriented nature, its classless (pseudoclassical) nature, and functional nature. While covering the fundamentals like JavaScript's: functions, lexical scoping, lambdas, prototypal inheritance, and functional inheritance.

This book's size makes it approachable for all audiences, its style is terse and concise. This book has the potential to do for JavaScript, what Richie's inspirational classic the C Programming Language did for the C language.

JavaScript is the programming language of the web (AJAX), and this book will guide you through the good parts of this often misunderstood language - while this book is an excellent reference, it is not intended to replace JavaScript: The Definitive Guide, you'll do best to have both these books on hand.

If you enjoyed (or are considering) this book then you may want to learn more of what Douglas Crockford has to say, check out his great JavaScript video series on the YUI Theater.

There's no need to whip a dead horse (I've probably been griping about the ASP.NET AJAX Framework for too long), but... Jon Galloway and a group of other notable gurus (K. Scott Allen, Scott Koon, and Kevin Dente) have started a podcast, their latest segment sparked my interest since it covered ASP.NET AJAX and AJAX Libraries / Frameworks in general.

I share their sentiments so I thought I'd post a brief but choppy transcript:

[ASP.NET AJAX] ... does offer some some nice features, they did try to take some of the common pieces of the CLR that [.NET Developers are] used to working with and move that down into a JavaScript library. So you get classes like a WebRequest class that wraps the XMLHttpRequest ... and they have a StringBuilder, and they added methods that we're more accustom with ...

that's wonderful, but I don't find myself needing those extensions all that often. If you want to do strictly client-side programming then something like jQuery offers you a lot more capabilities to do things that you really want to do client-side like sorting and CSS selectors. ... That stuff is easy to do with an Update Panel and ASP.NET, but Update Panels aren't always the best solution to use. ...

the goals with ASP.NET AJAX was to integrate into the ASP.NET server-side model ... that's great for ASP.NET, but it needs more client-side features. ... It works if your thinking from the ASP.NET control perspective, but if you look at it outside the ASP.NET model there are a lot easier ways to do it. ...

ASP.NET AJAX [development] seems to have come to a standstill I'm not seeing a lot of development in that area and the rest of these [AJAX] Frameworks are doing monthly releases. Every month that goes by [the ASP.NET AJAX Framework] falls further and further behind ... it needs to evolve.

Back when the web turned 2.0, AJAX was all the rage, and gas was cheap, a Google recruiter contacted me. We worked through a couple screening interviews - I explained how I was a .NET / ASP.NET / C# developer with some experience with Java and PHP, I described how C# was somewhat similar to Java. Things went great, I moved on to the next step of the process - writing code (a JavaScript widget for Gmail) with a 2 day (weekend) hard deadline. At the time I was wearing JavaScript diapers, but tried the exercise anyways - I'm still convinced the recruiter confused my Java / C# experience with JavaScript. Anyhow...

The Google Web Developer Exercise:

Web Developer Exercise

Attached are three states of a new contacts widget. This widget will be used across Google and may be anywhere on the page. Designers will also use this in mocks for usability tests. Create the HTML, CSS, and JavaScript for the widget as described in the image. Your solution must work in Firefox v1.5+ and IE v6+. Bonus points for a solution that degrades nicely on older browsers.

Framework Web Developers (ASP.NET, Ruby on Rails, and so on) aren't really Web Developers - we depend on a framework (an API) as a crutch, where the law of Leaky Abstractions is very real, and often when it rears it's head we use our golden hammer (our multipurpose language of choice), but there are better tools at hand

Web Developers claiming n years of experience need to at least know JavaScript, CSS, HTML / XHTML, a server-side language, and some XML / XSL - NOT just a single multipurpose language or framework

Innovation can only happen when you become one with the technologies surrounding your realm - for example: Jesse James Garrett probably would not have publicized AJAX had he been an exclusive ASP.NET developer. Diversity is essential for innovation

In retrospect this exercise is brilliant, it's a more complex derivation of a Fizzbuzz exercise, which effectively weeds out the knowledgeable candidates from the n00bs. JavaScript is notorious for being one of the world's most misunderstood language, many developer (and the ASP.NET Framework) still use JavaScript techniques from the old days of Netscape. For example: <a onclick="return false;" ..., or <a href="Javascript: do something;" ... are common DOM Level 0 inline techniques that should be avoided. These techniques have been replaced, but finding developer that use these JavaScript techniques can be hard.

By having a developer complete this exercise you effectively determine that the they understands these concepts:

Cross browser compatibilities and work arounds for both JavaScript and CSS - with a preference given to feature detection (object detection) vs browser detection, an understanding of the different event handling models between browsers

An understanding of the separation of concerns - JavaScript, markup, and CSS should be separate files, or at least separated within the document

Importance of modular / compartmentalization of CSS and JavaScript - defensive programming techniques that minimize the risk of interfering with other scripts and elements within the page, part of the non-obtrusive techniques, how to avoid global variables

An understanding on how to debug JavaScript from both IE (link) and Firefox (link)

Today I'm wearing JavaScript training wheels - feel free to comment on the code, I'm always looking for improvements and suggestions. I did take a couple shortcuts on the CSS / UI side of things as I was focusing more on the functionality.

Using one of the AJAX Libraries (like jQuery) we could certainly do this exercise in significantly fewer lines of code.

This book was required pre-reading for my latest Technical Editing task - I'm editing Mr. York's newest book. So in the spirit of spring, de-cluttering, and giving. I'd like to give this book away. This book is like new with a couple minor dings (from an airport fiasco), it is in full color (like all good design books should be), and it's free!

Contest Rules:

Comment on this post.

Leave a valid email in the email comment field.

The winner will be chosen at random and notified through email on Canada Day (July 1st).