ITeMerge

Next we move from our HelloWorld application to something that has
stateful sessions. We’re going to build a registry of sessions and
push the canvas down a level so that the sessions hold the canvas.

The next piece of heresy: meaningful URLs don't carry enough
meaning. People put a lot of energy trying to create names that
describe the particular point in an application. Not every page in
an application is a meaningful part of an API. URLs, particularly
query parameters are classic place where people repeat themselves.
Don't repeat yourself. Lots of meaningless names create namespace
collisions.

Avi proposes using a registry to store IDs against page names. The
inspiration for this is TCL/TK: Register closures/blocks as callback
objects.

Avi remarks that pages are a lousy unit of reuse and partials ain’t
much better.

The idea to create a toolkit that would render web pages is certainly not new. I did something like this 5 or so years ago (Google for pyortal) and I seriously doubt I was the first one who did.

The problem of going GWT style is that it sounds very nice in theory, but breaks down horribly in practice. The reason for this is that it's a tedious way to write text into a page (just try doing it with something that has a fair amount of strongs and ems embedded).

But if you try to factor that part out and handle text differently, what you end up with is more or less a layout skeleton, which doesn't do you much either. There just aren't all that many widgets that would be complicated enough to warrant their own function call and would get used repeatedly.

Admitting idiocy is one of the most important things a blogger can do. It completely diffuses a situation that could quickly turn ugly.

“Yes, you’re right. I stand corrected.” As a listener I was completely disarmed…

And the funny thing is, that if you admit you’re wrong, people might just start assuming that in the other cases you’re right.

Know when to take it offline

Several times I’ve had folks come to my site and try to embarrass or criticize me personally in the comments on a post. Whenever this happens, you have to immediately take it offline. Send them an email and explain your situation. More than likely, they’ll cool down after that.

Link back to your good stuff

One caveat…rarely quote yourself. For some reason it’s a big turnoff…maybe too much self-flattery or something. Instead, simply repeat the idea in a slightly different way, resetting the context for the idea that you want to talk about again. But please, don’t quote yourself…quoting is an activity we should reserve for people other than ourselves.

Reread to yourself

Blogs aren’t books, poems, or even journalism. They’re conversations, so they need to be conversational. Make them read like how you talk.

Treat every post as a possible later reference

If you’re a programmer, think about the DRY principle: Don’t Repeat Yourself. Write something once, write it well (revise until necessary) and then feel free to refer back to it later.

Keep updating your best posts

So, if the post could use pruning, or additions, be sure to go back and add them. It’s OK…this isn’t paper we’re publishing on. Just go back and change it, and maybe add a note that you’ve done so.

Name things (e.g. The Del.icio.us Lesson, The Chanel No. 5 Lesson)

Link to the quiet, unknown ones

It works like this: people expecting company clean the house. If a blogger is expecting company (readers), they’re much more likely to work on their blog and make it better.

Use the comments for refining your point

Everything is beta

Have a schtick

Correct English be-damned

Show your greatest hits

And if you’re just starting out, put all of your posts in it. You can easily take them out as new greatest hits emerge.

Don’t let the simple posts fool you…that’s the goal.

for any project we need to clarify what is to be achieved and what specific actions are needed to achieve it

to do this thinking in advance, generating a series of actions which we can later undertake without any further planning

“Get everything out of your head. Make decisions about actions required on stuff when it shows up — not when it blows up. Organize reminders of your projects and the next actions on them in appropriate categories. Keep your system current, complete, and reviewed sufficiently to trust your intuitive choices about what you're doing (and not doing) at any time.”

Collect

Capture everything that you need to track or remember or act on in what Allen calls a 'bucket': either a physical inbox, email inbox, tape recorder, notebook, pda, or any combination of these. Get everything out of your head and into your collection device, ready for processing. All buckets should be processed to empty at least once per week.

Process

When you process your inbox, follow a strict workflow:

• Start at the top.
• Deal with one item at a time.
• Never put anything back into 'in'.
• If an item requires action:
• do it (if it takes less than two minutes),
• delegate it, or
• defer it.
• If not,
• file it for reference,
• throw it away, or
• incubate it for possible action later.

Organize

Allen describes a suggested set of lists which you can use to keep track of items awaiting attention:

• Next actions - For every item requiring your attention, decide what is the next action that you can physically take on it. For example, if the item is 'Write project report', the next action might be 'Email Fred for meeting minutes', or 'Call Jim to ask about report requirements', or something similar. Though there may be many steps and actions required to complete the item, there will always be something that you need to do first, and this should be recorded in the next actions list. Preferably, these are organized by the context in which they can be done, such as 'in the office', 'by the phone', or 'at the store'.
• Projects - every 'open loop' in your life or work which requires more than one physical action to achieve becomes a 'project'. These are tracked and periodically reviewed to make sure that every project has a next action associated with it and can thus be moved forward.
• Waiting for - when you have delegated an action to someone else or are waiting for some external event before you can move a project forward, this must be tracked in your system and periodically checked to see if action is due or a reminder needs to be sent.
• Someday/Maybe - things that you want to do at some point, but not right now. Examples might be 'learn Chinese', or 'take diving holiday'.

A calendar is also important for keeping track of your appointments and commitments; however, Allen specifically recommends that the calendar be reserved for what he terms the 'hard landscape': things which absolutely have to be done by a particular deadline, or meetings and appointments which are fixed in time and place. 'To-do' items should be reserved for the next action lists.

A final key organizing component of GTD is the filing system. Getting Things Done says that a filing system, if it is to be used, must be easy, simple and fun.

Review

The lists of actions and reminders will be of little use if you don't review them at least daily, or whenever you have time available. Given the time, energy and resources that you have at that particular moment, decide what is the most important thing for you to be doing right now, and do it.

Do

Any organizational system is no good if you spend all your time organizing your tasks instead of actually doing them! David Allen's contention is that if you can make it simple, easy and fun to take the actions that you need to take, you will be less inclined to procrastinate or become overwhelmed with too many 'open loops'.