Web developers Sergey Chikuyonok and Vadim Makeev have built a nifty set of plugins called 'zen-coding' that work across a range of IDE's.

The niftiest idea from 'zen-coding' is a way of writing Html very very quickly, by a kind of reverse-application of CSS-selectors.

Ah, I think examples will show what words could never explain...

If you type:

div.name

and press the shortcut-key to invoke 'zen-coding' -- the snippet expands into this piece of html:

<div class="name"></div>

If you type:

div#name>p+p

and invoke 'zen-coding' -- the snippet becomes:

<div id="name">
  <p></p>
  <p></p>
</div>

There are more complicated scenarios as well: if you understand CSS selectors, you'll wrap your head around it very easily.

Hence, zen-coding lets you write markup very very quickly.

I've built an online demonstration, a simple web app that uses the code from Sergey's aptana plugin.

These ideas have been re-implemented for emacs, and there's a vim re-implementation in the wild as well.

There's some very good screencasts around, here's one from Vadim and one from Sergey.

This is a cool idea. In the same way that JScript takes CSS Selector DSL and re-purposes them, 'zen-coding' squeezes extra utility out of this tiny DSL. What other DSL's can be used backwards, forwards, sideways? Can linq expressions be reversed for generating .net classes (rebuilder style)? Can SQL Select Queries be parsed and turned into DDL for creating a database schema? Can XPath be used as an XML generation tool?

It's also gotten me thinking about how this style of code generation can be applied to my favourite little hobby-tool, 'World's Simplest Code Generator'

WSCG has come a long way lately, as I've been using my bus-rides to make WSCG more powerful (typing on the HP-mini I got at Tech-Ed) adding more macros, built-in functions, an extensive help file, and some powerful operators called $ONCE and $EACH.

"I knew I shoulda taken that left turn at Albuquerque!"

Rico Mariani has an excellent series about The History of Visual Studio.

There's one little 'detour' in Part 10 of the story, where Rico describes debugging.

I love his description, he's clearly delivered this bit many times. It's so polished it deserves to be quoted all on its own.

I was the debugger lead in the early 90s and I used to explain the utility of debuggers and debugging tools in this way: Imagine a program with a bug, it has been running along, everything is fine, everything is going wonderful, the flow of execution arrives at a point we'll call Albuquerque, where it turns right. Now as every Bugs Bunny fan knows, the correct thing to do at Albuquerque is to turn left. The program's decision to go right has led it down an incorrect path and sometime later we will observe a problem.

Now if we're very lucky "sometime later" will be very soon, like for instance it might be that we just de-referenced a null pointer and we're going to take an exception about 2 nanoseconds after the mistake. That's an easy bug to fix. On the other hand it could be that "turning right" was more subtle - maybe we corrupted a data structure in a minor way and it might be days before we can see an observable effect - that kind of bug is a nightmare.

Finding "Albuquerque" is what I call The Fundamental Problem of Debugging. The debugger provides you with tools (e.g. breakpoints) that allow you to stop execution while things were still good and slowly approach the point where things first went wrong. The debugger likewise provides you with tools to examine the state afterwards, hoping to find evidence of what went wrong in the recent past that will help you to see the origin. The callstack window is a great example of looking at the past to try to understand what might have already gone wrong.

To find the problem, you might start after the failure and try to look back, finding a previously unobserved symptom and moving closer to the original problem or you might start before the failure and try to move forward slowly, hopefully not overshooting the problem by too much. Or you might do a combination of these things. You might add assertions or diagnostic output to help you to discover sooner that things went wrong, and give you a view of the past. It's all about finding Albuquerque.

Rico nicely covers just about all the things you do, in the desperate search for that elusive bug.

Some say too much time in the debugger is a sign of a bad programmer.

The zero-debugging viewpoint says your code should be so well designed you can reason about it without having to step into it. Others says that the best way to avoid long debugging sessions is consistent use of assertions.

I'll do whatever I can to avoid the existence of bugs in the wild. I'll use any approach I can to cut down the necessity for a deep debugging session.

But all the same, debugging is powerful magic. I expect I'll give up the Joy of Debugging when you pry the debugger from my cold, dead hands.

Here is it -- 'the Real Time online JQuery Editor', or RTJQE for short.

Where do we start? Paul Stovell built a nifty little wpf app called JQueryPad.

It promises to get rid of the need to Alt-Tab while deving (and debugging) your JQuery code.

No, we have to go back earlier than that: Square free realtime html editor came out years ago... (I blogged about it in 2005)

So I got the two ideas and smashed them together in the large hadron collider that is my tiny brain.

The result is 'the Real Time online JQuery Editor', or RTJQE for short. It's guaranteed to work in every browser, except IE, and you may experience some quirks in Firefox, Chrome, Opera and Safari. ;-)

Mark Pilgrim (one of the internet's colourful characters) is writing a book on HTML5.

Chapter 3 is a great read but at forty pages it's too long for a busy and important person like you to follow along. So I'm gonna summarise (brutally), for your benefit.

Mark shows us before and after version of a document: it starts off using pre-existing HTML features, and he carefully simplifies the document (and expands it) with all the goodness that HTML5 provides.

The two following images show the resulting 'diff', as seen by SourceGear's DiffMerge tool.

Here's my very poor and half-baked summary of the diff:

1. You don't need quotes around attributes (unless there's spaces in the attribute, and then you do) *
2. You don't need closing tags in redundant situations (e.g. 'tr','p') *
3. Less "DIV"itis due to new and meaningful elements:
   

   <header>

   ...where you might've said <div id='header'> previously

   <hgroup>

   ...to tie a bunch of headings together, where they don't create subsections

   <nav>

   ...where you might've said <div id='navigation'> previously

   <article>

   ...to denote standalone pieces that can be extracted and read on their own (perhaps the <div id='content'> of your document)

   <aside>

   ...to denote diversions from your text that aren't part of an article itself (for example, pull quotes)

   <time>

   ...for text that indicates a time, this has a machine readable attribute, e.g. "datetime='2009-10-29'"

   <footer>

   ...where you might've said <div id='footer'> previously

* So this is not XHTML, it's not even XML. You can write it as valid XML if you're that way inclined -- but you don't have to. It's HTML. It doesn't have to pretend to be something it's not. That's cool. That's the bit I like best.

Some other Mark Pilgrim links, in case you don't know of him:

• Dive into Accessibility
• Dive into Python
• Addiction Is
• There are no exceptions to postel's law

Attention to all people on the project!

Some members of the software development team are currently working on high priority items which require their full attention.

For this reason, the project has purchased a number of iron codpieces, which will be worn by those developers who do not wish to be disturbed.

If, while kicking a developer in the balls, you discover the following:

1. You are not eliciting the expected response, and
2. You hear a 'chinking' sound

Then please:

Assume that the developer is in-fact busy.

If, after a moment's reflection you still feel, for whatever reason, that the matter is sufficiently important to warrant the developer's immediate attention, please escalate the matter by head-butting the developer across the bridge of the nose in the usual fashion.

We thank you in advance for your patience.

And please note that passive-aggressive emails sent to the developer list will continue to be given the highest priority.

Personal A3 story 'wall' on my desk... To-Do | In-Progress | Done

In the article 'No Surprises' Rands has a great throw-away line. He says:

"My move is to keep a yearlong log of significant work as a task in whatever task tracking system I'm currently ignoring."
[emphasis added]

I've got a 'wall' on my desk.

I've got an agile-style 'story wall' sitting on my desk at work: this is my latest task tracking system to ignore -- but so far, over three or so weeks, it's working out swimmingly. The most productive and least ignorable system I've ever used. (and, like most people, i've used a few)

Ingredients

• An A3 sheet of paper.
• A deck of extra-small post-it notes.
• A pen.

Instructions

• Divide the A3 paper into three columns. "To-Do", "In-Progress", "Done" (or synonyms there-of).

• Leave this thing on your desk, beside whichever hand you write with.

• Be quick to add post-it notes.

• One word is enough for many post-it notes. (I'm the only one who has to understand them)

Pro-tips

Post-it notes have a tendency to curl up slightly at the bottom. This makes them hard to read when they're stuck to paper sitting on your desk. So rotate them around and write on them upside down.

If there's a 'real' task system that you're s'posed to be updating, then make sure you write the task number (or bug number, or work item number, or whatever it's called) onto the corner of the post-it note. Write it in a consistent place and you'll be more likely to do this when required.

Reserve one corner of the A3 sheet, and give it a heading "Waiting for...". Park any post-its here where you're waiting for someone to get back to you.

The A3 sheet also acts as a good area for 'doodling' if you're a doodler. (I'm a seasoned doodler). When the sheet gets full-up, you can transfer over to fresh one in a jiffy.

The latest trick, is that I limit the amount of 'in-progress' tasks to just 2. I use the kanban/lean trick of having only two 'slots' available in the 'In progress' section. So if there's already 2 items in progress, and I want to do a new item, I have to either complete one of the current items, or move it to the back log. This little trick is a brilliant addition (thanks to James Brett for the suggestion.)

Why does it work so well?

People are often tempted to create internet-based 'todo-tracking' systems. I've said it before:

"Placing an anti-procrastination tool on the internet is like hosting an alcoholics anonymous meeting inside a brewery."

By moving the todo-list completely outside the computer, it moves it away from so many of the distractions that destroy productivity.

And by using little post-it notes, we get the benefit of being able to manipulate the tasks, with no pressure to over-describe the task at hand.

Here's a schematic that shows the approximate shape of my more recent versions of this (the photo above is a week or two out of date now) It'll be different again in a few days, this is very much a work in progress:

(Talk of 'systems to ignore' reminds me of an experimental WPF-app I built a few months ago, seemingly named 'OnTrack':

It looks nice, promises much... but I spent more time styling the stop button than i spent writing all of NextAction, hence, one is shipping and works well, while the other is now just a screenshot of some lost code.

A beloved secretGeek reader sent me something, which I assume he wished to be published anonymously as part of my 'ghost blogging' series. Okay Kaj, here goes ;-).

Some people are thick.

And it's not just that they're thick. The thickies have thick problems. And, all too often, the thickies come from thick families. And the thickies choose thick boyfriends, or thick girlfriends, and thick husbands and thick wives. And the thickies' thick families and thick boyfriends and thick husbands and thick wives have thick problems of their own. And they ring up their thickie partners on the telephone to have big thick conversations about the big thick problems in their big thick lives.

Thick people are thick magnets. Thick people solve their thick problems in thick ways that create even thicker thick problems.

Never work with thick people.

Edited for spelling, grammar, brevity and meaning.

In fact the only original word that remains is 'telephone'. It initially covered some kind of convoluted story about how our anonymous contributer failed to fix a printer for his ex-wife, but he went about it in a thick way and I lost interest part way in. Dear Kaj: in response to the extended section (from your original email) where you describe the way democrats, java programmers, and (eventually) even 'lesbias' are (as you assured me) 'rapping' the planet (like eminem, hmmm?) and so on Kaj, I strongly feel the need to tell you: lay off the weed, man. Step away from the internets.

If you too have a story to share anonymously: you know what to do¹.

_{1. Send it to the daily wtf. What do i look like? Alex Papadimoulis?}

Image credit

At work we've now got a dedicated machine for displaying the project status at a glance.

Someone suggested we use Leapstream's ScoreBoard to monitor Hudson (the CI system we use), but we found there were more things we wanted to show than just the build status.

So we built an Asp.net MVC application called 'Cosmo' that combines build status, number of bugs/stories remaining in the iteration, and a count down to the next release.

This thing is visible from the whole length of the floor. Ah the hilarity that ensues.

It's not exactly production-ready code but it does the job.

We've also got gource (and code_swarm) visualizations of our source repository (thanks to the guy ducking out of the way in the photo above) and, soon we should have a build lamp hooked up via X10.

These are the things that matter.

Many years ago, when the internet was young, when blogging was fashionable, and when Joel Spolsky was still cool, I had one of my blog articles published in a book, "The Best of Software Writing Volume I"

'Volume I' was an optimistic title -- there never was a Volume II. Software writing in general was already headed downhill rapidly -- and clearly that volume represented the zenith of the artform.

A strange myth arose. Apparently, Japan as always, was ahead of the game and put out a translated edition of the work, 3 years before the English edition reached the market.

Recently, I sent a member of secretGeek's research team on a field trip to Japan, in order to capture photographic evidence of the rumoured Japanese translation. It's a little blurry, but it gives the idea.

So here it is, 'Award for the Silliest User Interface: Windows XP Search', in the original Japanese:

Before satori:
herding cats through moving goal posts.

After satori?
herding cats through moving goal posts.

Definition

"Satori" --> "(Zen Buddhism) a state of sudden spiritual enlightenment."

Allegory

A Zen Buddhist, was allegedly asked to describe his life upon reaching enlightenmnet, and gave it thus:

"Before Satori, chop wood carry water; after Satori, chop wood carry water."

Thank you. Now, please go back and carefully read my post, pretending that you got the back-story ;-)

Acknowledgment:

cat herding quote, pure Joe Cooney