Jeff Atwood writes CodingHorror which has been steadily building an audience over the last few years and is now a very popular destination for programmers.

I'd like to share my current opinion of the formula for creating Jeff Atwood style articles, in the hope that it may inspire someone, somewhere to do something, somehow.

Here it is:

1. Get an opinion

Uncover some ugly half-baked opinion in the dank underground of your tortured soul.

Or, stumble upon some small yet intriguing factoid in the narrow side-streets of computing.

2. Resist the urge to blog at this point.

99% of bloggers would dash out their hideous wretch of a thought at this point.

Jeff holds back.

3. Research the classics

Remember: if you steal from one source they call it plagiarism. Steal from many, they call it research.

First, turn to books. What does Steve McConnell say? Tufte? Brooks?

Highlight any well written phrases you may wish to quote.

4. Beyond the classics

Ah, but the classics so often fall short. Particularly on contemporary topics.

Turn to the words of reputable bloggers, or better yet, wikipedia. Branch out from there.

Again, highlight phrases with a quotable turn of phrase.

But be ruthless and perfectionist in your approach: quote no trash.

5. Look for opposition

Actively seek out contrary opinions. Every topic has naysayers, and amongst such sayers of nay must be people who express valid concerns.

Be prepared to change your mind.

And again --

Highlight any well written phrases you may wish to quote.

6. First Major objective satisfied

Now you've collected the meat around which the gravy of your narrative shall flow.

Crack knuckles, sit straight, for now you can write the text itself. Lay out the quotes before you and choose only the best and most worthy.

7. Reader is ignorant yet intelligent

Assume the reader knows nothing about the specific niche topic at hand.

And yet -- here's the hard part -- treat the reader as your intellectual equal. Talk across to them, not down to them. They are exactly as smart as yourself, but it so happens that they have not, just moments ago, finished reading the very best writing on the topic at hand, and as such they need some friendly coaxing.

If new terms are introduced -- define them. Or failing that, provide a link to a definition.

8. Take a side - for now

Be willing to take sides, by all means. But present both sides of the arguments in a fair light: hence, do not try to make either side appear worthy of ridicule.

Amongst your readers are many informed people who may bring to light information that changes your opinion. So be honest in your opinion, but not dogmatic.

9. Why choose that heading?

Choose a heading that is open to misinterpretation.

The heading should raise questions, not answer them. Answers are complex things, and readers shouldn't trust any article that answers everything in the heading.

10. Google Search for images

It's near the end of this article and you are hardly reading now -- which is a shame, because the best tip is the final one.

Perform a google image search for something entertaining (or disturbing) to accompany and lighten your research. Your own biases will probably come into play here and you'll adorn your article with pictures of computer games, console apps and kittens. But you can't be perfect. After all, you're only Jeff Atwood ;-).

Scan over your writing one more time. Ensure the tone is friendly and informative: capable of causing upset, yet never quite, exactly "wrong".

Hmmm. To be honest, just go read his site and make up your own rules. He breaks these ones all the time.

The only absolute rule I know he follows -- is to be Atwoodistic. I would define Atwoodism as follows

When you mention a topic you've covered previously, provide a link. Always.

I posted something about the word 'Upsert' recently -- and I was kind of surprised by the comments.

My real feelings about the concept of coining a new term 'upsert' are simple:

Don't do it!

Upsert is a bad name. An evil name. And not because it is a silly portmanteau.

Coining a term upsert, to embody the concept of "Update or Insert" is bad because it fundamentally misses the point of "Why We Code".

Let's get back to basics

Just say you discover that your code is frequently peppered with this little snippet:

If (this.State != New) {
  this.Update();
} else {
  this.Insert();
}

So -- you decide to extract that code snippet and place it in its own routine.

Routines are nice, routines are great.

"Aside from the invention of the computer, the routine is arguably the single greatest invention in computer science."
  Why You Should Use Routines, Routinely

This is what you create:

private void Upsert() {
  If (this.State != New) {
    this.Update();
  } else {
    this.Insert();
  }
}

Now -- any instance of those fives lines becomes instead:

  Upsert();

Great! You've achieved one of the primary goals of routine construction: code reuse. Your code is now shorter, and thus hopefully cheaper to maintain. It's more versatile because now if you change the way "update or insert" works you only need to change it in one place.

Life is sweet. The birds sing and the flowers bloom once more.

But there's something amiss. Something foul remains.

You've failed on the other goal of routine construction -- you've failed to hide away the implementation details. You've failed to "raise the abstraction level!"

The user/programmer still has to think about the inner concepts: update and insert. Every time they see that words "upsert" -- the details "Update and Insert" are staring them in the face.

You lose sleep. Your dreams are troubled. Dark clouds follow you everywhere. And in quiet moments you hear the ominous echo of Alfred North Whitehead whispering:

"Civilization advances by extending the number of important operations we can perform without thinking."

--Alfred North Whitehead

Did you read that? What? You missed it -- here it is again:

"Civilization advances by extending the number of important operations we can perform without thinking."

--Alfred North Whitehead

By choosing the name "Upsert" we've failed in our duty to advance civilization! We want the user (the programmer who uses your routine) to perform these two important operations without thinking about both of them.

Let's think of a better name -- a name that alleviates the consumer from having to think about the constituent parts of the routine they're using.

How about this: Save.

private void Save() {
  If (this.State != New) {
    this.Update();
  } else {
    this.Insert();
  }
}

Isn't that nicer? And civilization has taken another tiny step forward.

Incidentally -- it seems this 'Alfred North Whitehead' was a functional Programmer in the 1800s -- before Church and the Lambda calculus that gave rise to functional programming. Here's a comment about him:

"There are no fundamental "things," or "objects" in the world of Whitehead. Whitehead's ontology, or parts-list of the universe, contains only processes."
--Richard Lubbock in 'Alfred North Whitehead: Philosopher for the Muddleheaded'

I've found a new word, buried deep in the internals of dot net.

(this is a real word)

"Upsert."

It means "update if you can, or insert if you have to."

It also looks a lot like a combination of the words "Upset" and "Berserk," and it sounds much like "Absurd."

All up, it's a keeper.

I was offline for a few days over the past fortnight, and found it really refreshing. Without the continual distraction of the internet I was able to concentrate on achieving a lot of things that had been niggling me for a while.

Amongst those was the addition of some long overdue 'luxury features' for TimeSnapper that I hope will make it more meaningful for a lot of users. (No doubt I'll bombard you with the details when we release the next upgrade).

With the internet out of the way, my 'at home' productivity went from its usually mid-40's mark to a whopping 98%.

There were a lot of blog entries I jotted down notes for, but now I'm just happy not to contribute too much to the hyper-noise of the internet for one more day ;-).

But here's an example of an 'awesome Atli tooltip' found deep inside the codebase for TimeSnapper.

It's these kind of gems that help me enjoy work on this product more and more with every version.

Now, back to the usual un-productive fare:

If you too have been tricked into using twitter, you can follow me here.

First here's a code example:

Single line 'TextBox':

Multi line 'TextBox':

Now here it is in pictures:

The single-line TextBox respects the maximum length property. The multi line textbox does not. We see other differences too: these two 'TextBoxen' differ from each other in far more than the number of rows.

The cause here is a classic 'Leaky Abstraction' - and asp.net is riddled with such leaks.

The 'abstraction' of "TextBox" is used to emit either one of three underlying html elements -- "TextArea", "Input type=text" or "input type=password" -- depending on the 'TextMode' property. The three controls are wildly different animals.

"Solutions" to this problem tend to use javascript to stop input once the maxlength is reached.

Edge cases are frequently missed, for example:

• Once maxlength is reached, ignore input, but don't ignore: Arrow keys, Delete key and Backspace. Others?.
• Pasting of text should truncate down to maxlength.
• Disabling of javascript is always possible, so length validation needs to be applied on server side as well.
• Now that javascript is in play, browser compatability becomes a bigger problem.

That's pretty nasty stuff to have to perform -- and worse, you're given no warning that you need to perform it.

The API tells you that there is a maxlength property you can use... but the API, in this case, is lying.

I'm not really concerned with this problem technically. And I think the asp.net abstraction is so extreme that it's admirable. I'd like to know how to patch this kind of leak.

Here's what I'm wondering:

Is there a way the text box class could have been implemented so that you get a compile error for setting the maxlength property when the textmode is multiline?

That would be enough to make it a safe abstraction in my books. It's more extreme than the static typing afforded by most static type systems.

I expect that such a constraint could be achieved with a language/tool like Spec#.

An alternative would be to throw an exception when setting the maxlength property if the textbox type is multi-line, and vice versa. But that seems like quite a faulty approach.

I'm just not happy about this at all. I think I will need to write a very stern letter to Scott Guthrie.

"Everything of importance has been said before by somebody who did not discover it."
--Alfred North Whitehead

Yet, once in a while, a true genius will strike upon a genuinely original thought.

Here's some such wisdom from JCooney:

"Who would you back in a fight: Cab Calloway or Darth Maul?"
--JoCo Loco

Tell me there isn't a multi-million dollar best-selling console game and movie franchise in that question?

(see also.)

Today's crazy idea.

For serious exception handling:

throw new VirtualMachine();

...immediately spins up a new virtual machine, identical to the currently running machine, only with a debugger attached and paused on a breakpoint at the currently active line of code which caused the exception.

The development/operations team are notified and given a url with which to connect to the new virtual machine. A bug is lodged in your support system.

Meanwhile, execution continues essentially 'uninterrupted' in the original machine.