I'm not talking about programming for the iPhone -- I mean sitting down with just your iPhone and using that device to bang out a new program.

Why not I say?

Fools (and people much smarter than me) are stumped because they point out that the hardware has restrictions which disallow the conversion of data (such as the programs you type) into executable code. And thanks to this deliberate hardware limitation you categorically cannot program on the iPhone. You run apps, not write them. That's what they say.

But -- it has a browser. A browser.

A BROWSER! Don't you see?!

I'm reminded of that bit in Harry Potter and the Goblet of Fire, when harry says he doesn't know how to win the dragon ball Z challenge, against a REAL dragon.

What are you good at? asks Professor Moody,

I'm good at flying, whines Harry, but I'm not allowed a broom.

Moody flares his nostrils and shouts You're allowed a wand!!

You see, if you are allowed a wand you can use it to get any other damn thing you want. So he uses the wand to get the broom and uses the broom to win the challenge. QED.

We're not allowed to program, but we are allowed to "browse."

With a browser we have javascript and with javascript we have:

ULTIMATE AWESOME!! This kind of awesome:

So I've built a simple domain specific language, which emits javascript targeted at the iPhone. Via which you can build apps for the iPhone, without resorting to a regular computer.

More to follow in part 2 of this 3 part series with a bitter, tragic end.

(a short advertisment for part 2 of this series now follows, as requested by my angel investors)

Part 2: IT WILL MELT YOUR FACE

A simple domain specific language, which emits javascript targeted at the iPhone:

Will it really melt your face?

Let's see what gas-mask girl has to say:

And how about Jeff Atwood, what does he say:

So, from a scientific point of view, the assertion is proved.

Stay tuned for part 2.

Immediately thereafter I cracked open the box labelled 'the secretGeek Disaster Recovery plan' and inside I found only an empty biscuit wrapper and a few stale crumbs.

So, after many hours of labour, I present:

The revised SecretGeek Disaster Recovery plan:

Every Sunday night, at 10pm, syncback fires up and downloads the contents of this website onto my most reliable home computer. If the computer is asleep, it wakes up to perform this task.

When syncback is finished, it uses powershell to tweet that it's done. It twitters to a single-purpose account that no one else need follow but me ('secretGeek_bkup').

Every night, syncback wakes up the local computer and copies all of the family files (documents, photos, code and websites) onto external media. These are rotated fortnightly to an offsite location. We're prompted to do this by scheduled tasks in windows.

The most fun part was getting syncback to tweet -- so I want to share that with you here.

I used the script Out-Twitter.ps1 -- from Jeffrey Hicks of Sapien, with some cheap hacks I've added.

Jeffrey's original script was very clever. It stored the credentials (the username and password) in a very secure 'best-practice'-oriented way. But that bit of the script kept exploding for me, so I threw it out. Since the twitter account I'm accessing is very low value (it exists for one purpose only) I'm happy to hardcode the username and password into the script. A compromise like that is the sort of corner cutting upon which enterprise thrives ;-).

Here's the exact callout string I put into syncback.

powershell -command " 'backup complete (secretGeek) @secretGeek' | out-Twitter "

Getting the quotes just write was by far the most annoying part. Followed by getting the firewall to play nice.

What's your backup strat? And did the coding horror blogapocalypso inspire you to make it better?

Also -- this just in: an authentic photo of Jeff, taken at the moment he first realised his VM wasn't coming back:

Possibly the only genius who can challenge the genius of KNVTn is that master of computer science, DE |(nuth.

Unlike thinkers of bygone eras, I guess KNVTn and DE |(nuth are lucky that they live in an era where the marvels of OCR technology can be used to perfectly preserve their works for all time, without their mighty shadows being usurped by popularist hacks, like that pretender Knuth and his ilk.

This guy knows it. Do you?.

Joseph Cooney and I were talking about the incredible revenue monster that is Balsamiq, a tiny software company which brought in over a million bucks last year. As such, the conversation soon turned to a lament for the paltry stipend that our own ISV's tend to bring in.

Pretty soon, one of us hit on a terrific winner of an idea, which you will see is far superior to any other possible money making venture, as it brings about exactly the right behaviour in people.

What one needs is a way to get the customer to take the wallet out of the pocket, and the credit card out of the wallet.

These are difficult steps with which potential customers are reluctant to demonstrate sufficient compliance.

Some products -- balsamiq being a great example -- seem to have a tremendous 'wallet-appeal'. After just a minute or two of testing that baby out, people realise this product will help them kick ass, and their WERF falls to almost zero, while their CCED rises to 100%. (WERF: Wallet extraction reluctance factor; CCED: Credit Card Extraction Desire)

So, Joseph and I devised a product of our own that has (I humbly submit) a better WERF curve, and a superior CCED factor than all your balsamiqs. And the time to market has been astounding: I time-boxed the development at 1 bus ride, and pretty much met this criteria.

So, here's the new product, I proudly present:

CreditCardOlogy

A big thanks to Mr Crazy Grumpy Smurf for agreeing to be the mascot of this little link out.

Web template from Ginger the Ninja of Open Source Web Design (OSWD).

Real ideas coming soon.

The new prisoner's dilemma

Assuming you're paid X per day on your current project, what multiplier of X would you have to be paid to voluntarily go to prison?

So instead of a 3 month project you do 3 months in stir, for example.

Assume in prison you are unable to see your loved ones, your freedom to do what you want when you want is curtailed, choice of food etc is reduced.

Unlike real prison let's say you're protected from forcible sodomy.

Before deciding on the exact value of X that would suit you, consider the following facts:

There's no internet access of any kind. This means you'll almost never have to worry about cross browser incompatibilities or CSS positioning.

There are no meetings in prison. None. Parole hearings, maybe, but even those are avoidable if you spend enough time in solitary.

What value of X would it take for you to accept?

Naturally the multiplier does not have to be greater than 1.

Original Premise for a road movie

Our hero is a nerdy kid, a computer lover. And he's also a fan of a particular rock band.

At 2 AM one morning the kid, our nerd hero, discovers that his favourite band's web domain has expired!

He springs into action and snaps it up -- he becomes the owner of www.WhateverTheBandIs.com -- and writes to them and tells them what happened.

Far from grateful, the band are furious! They demand it back.

Kid responds: he'll only give it back if they make him an official member of the band and take him on tour.

The band talk to their lawyer, it goes like this:

Lawyer: Well, technically the kid hasn't broken any laws. The only state this is a crime in would be (insert state name here). So if you can think of a way to get the kid to that state, then you could have him arrested.

Band: Our tour finishes in [that state].

Lawyer: So take him on tour. Get him to [state name] and arrest the little f*cker.

And that's the premise. Nerdy kid's on tour with a rockband, he tunes their guitars for them, fixes their computers, meets a girl, and is destined to be arrested.

It practically writes itself.

I've done the hard part. Now the rest is up to you.

Note that 'the kid' could instead be an overweight 48 year old bachelor. And 'the rock band' could be an all-girl Japanese rap group. Just sayin.

(Added benefit: changes like that would make me less likely to be sued by Cameron 'Almost Famous' Crowe)

Research needed: do bands actually value their webdomain so much that they'd pretend to have a kid join their band then arrest him?

Way more awesome variation: same story, except the domain that has expired is NASA. Kid snaps it up, tells NASA he wants *in* on the upcoming journey to Mars. NASA look into it and realise that it's the only way to save face, so they reluctantly agree, plus taking a kid top-side is good for publicity. What happens next? This sucker writes itself! So don't just stand there, lick yer pencil and start scribblin.

(Sorry for bleeping the swear word above, [F*cker that is] but this is a family-friendly blog. And sorry for swearing in the first place, but, well, I think we all know that lawyer's are a potty-mouthed bunch of f*ckers)

Working from home was interesting. I setup my usual task board, and tore through the actions.

Still I missed the physical reality of the office environment. I asked my colleagues what was going on, and they sent through some very enlightening screenshots.

It seems they'd been playing a game even more awesome than DevShop.

Cubicle Attack!

The First Person Shooter in a Peaceful Office Setting.

> p1 brandishes foamy hot latte.
> p1 attacks p2.
> p1 misses.
> p2 brandishes blue stapler.
> p2 attacks p1.
> HIT!
> p2 wins.
Play again y/n?|

Which leads me to side with Wally on a possible reason why working from home is so much more productive than going into the office:

Ah, 'tis true. But I'll be there Monday.

Despite my earlier protests about the damn thing, I went and bought a bloody iphone.

And on this new device (with which I am utterly utterly obsessed) I've been playing a bunch of games, and hence, have been thinking about inventing new games of my own.

Now one of the most intriguing games I've played is 'Sally's Spa' (pictured at right) from Game's Cafe.

It's a kind of 'lemonade stand' game, tailored around running a day spa, with a few interesting little details.

I played an intense session of this on the way to work one day last week, so when I arrived I was still in a game-trance and couldn't help but see my life as an 'extended bonus round' of Sally's Spa.

At the 'daily team standup' we were throwing the over-inflated tennis ball around, in a mesmerising, slightly trippy dance, then later the 'build chicken' flew past me, and i saw the automated test failures popping up like members of a cosmic game of whac-a-mole.

Over lunch, while munching my avocado chicken bonus food supplement, I used one hand to draw-up detailed plans for a classic iphone game, based around the establishment and advancement of a software development shop. Let's see what happens as you take your humble development house from the small time to the big time...

So, here's this week's ridiculous plan, complete with iphone scanned images, for a face-melting platform mega killer:

DEVSHOP!

How does it start?

You're a dev who decides to go it alone, and start their own... (wait for it...)... DEVSHOP!1!!

You start out with a crappy office, a few plastic chairs, an old 386 with a 15 inch CRT. Your development tool of choice is 'notepad.exe'. Source control? What's that.

You do have a story wall, a cheap desk for extracting customer requirements and a typewriter for creating invoices, once the product ships.

Here's the basic layout:

The only staff member is you. And I'm sorry to tell you, your skill-level is very low in terms of business analysis, development and testing. You're a basic 'Jack of No Trades'. With no other staff, you have to do it all yourself.

As new customers arrive in the bland reception area (lower left), you take them to the meeting 'room' (top left) where they divulge their requirements, which then appear on the story wall (top middle). You head to your cubicle to develop the requirements, then pick up those same requirements for final testing, and finally, if the work passes your testing, to the billing desk where customers are presented with an invoice.

Due to your lack of skills, things can go wrong at every step. The analysis, the coding and the testing are all error prone in multiple ways. Poor analysis can create invalid requirements that need clarification during development, or for which the customer later reject the works (or pays less, or demands re-work). The development itself is slow and buggy, while the testing is inconsistent, and likely to either let bugs through or cause wasteful re-development.

But even with these limitations you can still earn a trickle of dollars to get through those first few awkward rounds.

When each round finishes, you get a chance to invest the money you've accumulated to improve your devshop, and raise the bar.

You might upgrade your equipment. Maybe turn that 15 inch cathode ray tube into a triple-panel flat screen, for added productivity. Replace that plastic chair with an Aeron -- including added lumbar support. Add a lolly jar to the meeting room, to keep customer's happy; or get a work blind or a camo cube.

You can upskill your staff, buying them copies of 'Code Complete' and so forth (the game could be monetized through product placement?) or by sending them on training in a myriad of topics.

Training (and books) are centred around topics that apply to the chief disciplines: Development, Testing and Business Analysis, always with a view to increasing speed of a step (a step is done faster), decreasing turbulence (less steps over all), or improving customer satisfaction (better pay at the end of it).

Really swimming in cash? You might be ready to increase your headcount. Go to the job market to hire extra people. Each candidate advertises a certain competency in terms of Development, Testing and Business Analysis, and they all demand a hefty price. But until you've hired them and seen them in action, you don't really know what you're getting. Unless, of course, you've given yourself enough training in Human Resourcing and you've upgraded your lie-detector to the most expensive model on the market.

Here's how the same office might look once you've hired a bunch of people and equipped them well.

Still, the difficulty for me, is trying to see my life as anything other than an extended, life-size game of 'DevShop'. Maybe if I put the iphone down for just long enough, reality will begin to find its way back into my state of mind.

Reality. There's an app for that, right?

<FONT COLOR='BLUE'>
   <FONT COLOR='RED'>
      HELLO WORLD! (should be purple)
   </FONT>
<FONT>

Well, I can see that this would appear tragic from most angles, but it's working out okay for me.

I setup the kitchen at home to have an 'agile' story wall, for managing my software hobby projects.

This was only a temporary arrangement (no way would Mrs SecretGeek allow me to permanently comandeer a wall in any of the liveable areas of the household, you understand.) The kitchen was briefly devoid of furnishings, while we had the floor repaired. And while the room was in this bare state, there was a big empty wall staring at me, just daring me to use it up with some ridiculous leon ideas.

So I turned it into a story wall to manage all the little hobby projects, web-sites, and applications, that are fighting for my nonexistent spare time.

The workers who repaired the kitchen floor probably realised there was a freak in the house. I can handle that.

Along the top I put headings, "Project", "Goal", "Backlog", "In Progress" and "Closed" (see orange arrow at right).

Each project forms a swim lane of its own (shown by purple arrow in picture at right). I seem to have 9 projects in flight at the moment.

I use little coloured 'bread-ties' as icons to highlight certain tasks (indicated by green arrows in shot above):

1. Blue bread tie

   Blue is the 'next-action' -- it's whatever task is top of mind at the moment. (This lets me have multiple projects that are officially in progress, when only one can really be the winner -- usually TimeSnapper).

2. Red bread tie

   A red bread-tie indicates a task on which i'm blocked, stuck, making no progress.

3. White bread tie

   White is the next item to work on in my HP-Mini computer (which I only use on the bus to and from work). This bread-tie is like the GTD idea of a context -- some items can only be addressed in a particular location or situation. (in gtd they have '@work', '@car' etc)

4. Green bread tie

   Green is stuff that I must ask Mrs SecretGeek to do for me. (She is my chief financial officer).

Once the kitchen floor was rpeaired, we moved the furniture back in, and I moved the 'task-wall' into the study. Here's a more recent photo:

The little cardoard-cutout of R2-D2 seems to have disappeared in the move. A certain toddler will need to be interrogated, Darth Vader style, on its whereabouts.

The projects I've got in flight, according to this wall, are:

• TimeSnapper 'site-wide' license enhancements
• TimeSnapper professional (general dev/support)
• 25 Steps series
• Blogging
• NextAction
• Project NR (skunkwork commercial product to be)
• Metanote
• WSCG
• Project CSD (skunkwork opensource project to be)

(and I've added three more since these photos were taken)

See also:

And here's a similar article from my colleague Ben Arnott, Fatherhood, People Leadership and Agile, where he admits using Agile to manage the kids.

In response to this, someone else at work admitted, very sheepishly, that she uses Agile-style retrospectives at home.

There was also an elegant code podcast episode covering this talk: Agile Practices at Home: Iterating with Children from Agile2009.

Makes me wonder how many people are secretly using these kind of techniques at home with their kids and partners, without having the guts to talk about it in public.

Ever taken your work home in this way?

And the latest shiny thing is Google's "Go" language. (Google Wave is sooo last month).

One of the authors is Ken Thompson, creator of Unix and the 'B' Language (pre-cursor to C).

I'm fascinated by little details, and here's one that I like:

If

In Go a simple if looks like this:

if x > 0 {
    return y
}

Mandatory braces encourage writing simple if statements on multiple lines. It's good style to do so anyway, especially when the body contains a control statement such as a return or break.

No parens required for an if... but braces are required. This is the opposite of other languages, but makes great sense to me!

It's kind of like Visual Basic, if anything.

In fact, there a whole bunch of things that are reminiscent of Visual Basic:

var s string = "";

This is the var keyword, followed by the name of the variable, followed by its type, followed by an equals sign and an initial value for the variable.

This is more than a little reminiscent of VB:

Var s as string = "";

Although with GO:

we could go even shorter and write the idiom

s := "";

Similarities continue...

Functions are introduced with the func keyword

Much like the way the 'Function' keyword is used in Visual Basic, hey?

And nothing like C-family languages that begin a function declaration with the type being returned. (Personally I wish they'd gone a ML-style choice of keyword, and used 'fun' for function.)

How is the return type shown? Almost exactly like VB...

GO:

func Area(side int) int {
   //code goes here
}

VB:

Function Area(side as int) as int
     //code goes here
End function

The similarities end approximately there. Did I miss others?

(Note that the similarities with Javascript are just as pronounced, and just as superficial.)

Another superficial detail I like is that semicolons act as separators, not terminators.

The coolest little language-nerd item for me is that capitalization is used to indicate scoping.

In Go the rule about visibility of information is simple: if a name (of a top-level type, function, method, constant or variable, or of a structure field or method) is capitalized, users of the package may see it. Otherwise, the name and hence the thing being named is visible only inside the package in which it is declared. This is more than a convention; the rule is enforced by the compiler. In Go, the term for publicly visible names is ''exported''.

That is a beautiful little detail. I love the simplicity of this approach. If a language is going to be case-sensitive, then it should *do something* with the casing.

But superficial details aside and onto the important stuff...

Indentation

We use tabs for indentation and gofmt emits them by default. Use spaces only if you must.

Sorry Google, I'm afraid Go is not for me.

References

1. Effective Go
2. Go Tutorial
3. Language Specification

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. ;-)

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:

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

While it is from the java world, it has some useful .net plugins, and it is so easy to extend that .net programmers can get a lot out of it. This blog post is a good guide for .net developers wanting to get started with it.

One oddity about Hudson is that it uses Blue to indicate success, rather than the more traditional Green.

Perhaps this is done to help people with red-green colour blindness.

Either way, I was happy to see there's a plugin called "Green Balls" which changes the success images to green, rather than blue.

I thought this worked fine, and I was quite happy with the newly installed Green Balls, until we'd been running for a few days.

There was a loud crashing sound, I turned around to the build monitor and noticed something unexpected:

Yes, yes. I am groaning too. It is bad. Yes.

Jesus almigthy! Employers are crying out for employees who "hit the ground running" and let me tell you, IT'S NOT THAT HARD.

And yet, I see people fail. Many, many people -- intelligent people -- they hit that first tiny hurdle, they bellyflop into it and collapse on the floor in a ball. Why people why!?

I guess I have to start by quoting the rules of 'fight club' since i'm clearly referencing them, and then I need to define what I mean by 'stand-up' since that is the matter at hand.

The rules of 'fight club'

1. The first rule of Fight Club is, you do not talk about Fight Club.
2. The second rule of Fight Club is, you DO NOT talk about Fight Club.
3. If someone says stop, goes limp, taps out, the fight is over.
4. Two guys to a fight.
5. One fight at a time.
6. No shirts, no shoes.
7. Fights will go on as long as they have to.
8. If this is your first night at Fight Club, you have to fight.

About 'stand up'

By 'Stand up' I mean "the Daily Stand Up Meeting" as introduced by the scrum software methodology and (pretty much?) adopted by all software teams everywhere.

At stand up, you stand in a circle and each speak in turn. We stand up because time is precious. Each person says... well, let me just explain 'the rules of stand up' in the style of 'fight club'. Let's see:

If this is your first day at Stand Up, you have to talk.

The Rules of Stand Up

1. The first rule of Stand Up is, you do not talk while someone else is talking.
    
2. The second rule of Stand Up is, you DO NOT talk while someone else is talking.
    
3. You talk fast and you keep it moving fast.
    
4. Tell us what you did yesterday.
    
5. Tell us what you FAILED to do yesterday.
    
6. Tell us what you will do today.
    
7. Tell us who is BLOCKING you today.
    
8. If this is your first day at Stand Up, you have to talk.
    

I could go on, but I already have. ;-)

"Never attribute to malice that which can be adequately explained by stupidity"

and this maxim has been my good friend for a long time.

But sometimes the stupidity is too acute to be plausible. Surely stupidity has limits?

Here's a case that left me gobsmacked.

For the last few years, airport security checks have been confiscating any liquid that is over 150ml or is not in a clear container. This is due to a security scare at some time. Fair enough, I accept that.

It turns out that they are also confiscating items purchased in-transit -- perfumes and duty free liquor, for example. I accept this too: I mean it's stupid, but it's within the usual bounds of plausible stupidity that we encounter every day. It's been going on for a few years now.

But here's the case of implausible stupidity I encountered last week at Syndey airport.

There's a duty free store encountered in-transit, just before a blind corner, at which there is an unexpected security check point.

So a store is selling items to people who will be forced, just 10 metres down the road, to relinquish their purchases.

Here's my mud map of the situation:

(Note that I didn't suffer this fate myself, I witnessed it happen to about 10 percent of the people from my plane.)

A duty free store sells goods just before a blind corner.

You walk around the blind corner and you enter a small, fast moving security check point.

Once your liquid goods have passed through the x-ray machine, they are confiscated. Everyone looks surprised. Even the security guards act like this has never happened before.

For many of the victims of this situations, this is their very first experience of Australia. Some kind of a crazy country where everyone is out to trick you.

(My wife and I were so impressed by this, that we found a quiet spot to observe the security checkpoint from above. It definitely wasn't an isolated case, it was very common. And the security guards looked amazed every time.)

I am pretty sure there's some organised crime occuring here, because the alternative explanation, stupidity, is just too impossible to be believed.

In the absence of a criminal conspiracy, here's 6 solutions that would've been better than confiscating the liquor:

1. The shop should inform the in-transit passengers that their liquor will be confiscated, before making the purchase.
2. The checkpoint could allow the passengers to return to the shop and demand a refund on the sale of the liquor.
3. The airline could warn the in-transit passengers (before they leave the plane) that any liquor they purchase in transit will be confiscated.
4. Instead of issuing the actual liquor, issue some kind of voucher which the person can use to collect the liquor at a final destination.
5. Respect the shop's tamper-proof packaging, as this ought to indicate that the goods are safe for travel. (If need be, an upgraded form of tamper proofing would be sufficient).
6. The security checkpoint could confiscate the goods, put them into tamper proof bags of their own, and deliver them to the cargo hold of the plane. (This is how 'dangerous items' like fruit knives used to be transported)(If this costs too much it could be reimbured by fining the shop who sold the goods)

But what's really going on here? What do you think happens to all that liquor?

I sincerely hope that there's a racket of some sort. Maybe it gets sold back to the shop. Maybe the security guards hang onto it.

I'm not sure, but I just hope there's a profitable crime going on, because in such a blatant case, malice is far more understandable than stupidity.

_{Sorry for the hiatus. Have been on holiday.}

At times like that, you can block out the idea immediately, but I find it's best to follow the idea through to it's logical conclusion.

So here's a repulsive idea I had, which I've since discussed with a bunch of people who helped flesh it out a little more, making it extra terrible.

Introducing 'The ReBuilder'

Ah, yes. It's called 'The ReBuilder'

Here's an example of what happens when you're foolish enough to use it.

So, you open up Visual Studio and choose to create a new console application.

You type the line:

var person = new Person();

Try to compile and see an error, essentially 'Person? No such type!'

"Error 1 The type or namespace name 'Person' could not be found (are you missing a using directive or an assembly reference?)"

Rather than have the programmer waste his or her precious time creating this new class, the Rebuilder does it for you. It goes right ahead and creates a class with the name 'Person'. It doesn't ask you to confirm the action, it just goes ahead and does it. No ifs or buts. Where does it put this new class? Wherever is the most conventional place. It builds the application again, right away. There's no new compilation errors, so it rests.

You type another line of code... you now add:

person.FirstName = "Jim";

The rebuilder picks up on this straight away. (Actually, screw it, you don't need to specifically try and build... this is a background compilation. It's always present.)

Rebuilder notices the resulting error...

"Error 1 'Person' does not contain a definition for 'FirstName' and no extension method 'FirstName' accepting a first argument of type 'Person' could be found (are you missing a using directive or an assembly reference?)"

Clearly you're not after a method called FirstName, you're after a property. So rebuilder adds a property named FirstName of type string. No magic.

Next you try to save your object...

person.Save();

This yields a fresh error:

"Error 1 'Person' does not contain a definition for 'Save' and no extension method 'Save' accepting a first argument of type 'Person' could be found (are you missing a using directive or an assembly reference?)"

This time the missing method is, indeed, a missing method. So ReBuilder gets in builds a method with the appropriate signature.

And it doesn't flesh out the body of the method with some dodgy 'Throw New NotImplementedException()' bullshit like the 'Generate Method Stub' feature in Visual Studio. It analyzes the name of the method, and implements it on your behalf.

"Hmmm, 'Save'," thinks the ReBuilder. "I guess you want to 'save' a person." So rebuilder writes a save method, saving to the most conventional place it knows: the database.

If there's a useful database connection in the application, then it uses that. If not, it creates one.

If the database contains a table named 'person', it will save to there. If not, it will build a table.

If there's no database to begin with -- well the ReBuilder goes ahead and builds it.

Obviously, you wouldn't do all this without any code coverage, so hell, RB churns out a sweet suite of tests to cover all the branches of the save routine.

(If the database, and the person table already exist, then we make sure all the relevant properties exist. This might include creating a migration script for updating any other environments with previous versions of our database)

Next you type:

person.GetByFirstName("Jim");

"Hmmm. Judging by the name GetBy<PropertyName>(<string>)..."

It looks like you expect a well understood pattern to be implemented.

(Yes, this bit is blatantly inspired by Ruby on Rails's use of method_missing...

"def method_missing(method_id, *arguments)
   if match = /find_(all_by|by)_([_a-zA-Z]\w*)/.match(method_id.to_s)")