Fight Diabetes with TimeSnapper

Help Cure Diabetes

Special Offer! We haven't done a special offer before, so please forgive me if I'm not very good at this.

For two weeks, starting now, if you purchase TimeSnapper Professional (US$39.95) (direct download here), we'll donate half the ticket price to help Team Hanselman Fight Diabetes.

So the American Diabetes Association are trying to cure diabetes. It's obviously a noble goal, but I think it's also an achievable goal, and it will be one of those gifts that never stop giving.

At a more personal level, as many of you know, my friend and longtime supporter of TimeSnapper, Scott Hanselman battles this nasty condition every day. It permeates every moment of his life -- and even wakes him from his sleep. (Check out this transcript showing what he went through on one fairly typical day.) I mean this is seriously intrusive stuff!

You can of course also make a direct donation, which will be tax deductible.

Team Hanselman Fight Diabetes

(At a deeper level I grapple with two personal problems here: 1. Why help diabetes in particular, i.e. "when the world is so full of good causes why choose this one?" to which i say, it's better to help someone right now than to hold out until you find the perfect cause. and 2. Am I an evil bastard because if, for example, this 'promotion' increases sales and I end up making more money than I would've without doing this? This one has me stumped -- and has caused some delay before going ahead with the promo. How about i agree to show a report on how the sales rate compared over these two weeks with the preceeding weeks, so that we can decide together if we've used Scott's illness for our own gain, and then we can investigate the moral aspect of it at that point from a real point, not one of pure speculation. So with those concerns aside, the promo is on, and you're invited to take part! Yes, i still overthink things ;-) )

 

Perfect Productivity with TimeSnapper 2.4

TimeSnapper 2.4 now available

TimeSnapper 2.4 is now available. There's two big new features.

First up is the Productivity Calculator. You can now mark certain applications and certain keywords as 'Productive' -- and then keep track of your productivity.

It takes no time to set it up (there's a wizard!) but it's very effective. Because you have a complete record of how you work, you can focus in on the unproductive stuff -- see how it started, how it progressed and how it ended.


TimeSnapper: Productivity Calculator!

This is really powerful stuff. I've learnt a lot about exactly how I personally slack off, and from that I've worked out what techniques will work to keep me in the zone. In the time I've been using the productivity features of TimeSnapper, my ability to stay focused on a task has risen dramatically. Give it a go -- and if the feature doesn't quite suit you, tell us what would work best for you.

But the biggest new feature is that we now include reports that let you get a quick visual feel of various measurements timesnapper has recorded for you.

Program Statistics Report

We've got five of them in there for starters:

  • Program Stats
  • Productivity
  • Flags
  • Daily Computer Time
  • Disk Space Usage

We'll be adding more in future releases. In the meantime, true hackers can also modify the existing ones, as they are xslt based. (Just backup any files you're modifying, in case you go overboard ;-) ).

Flags Reports

There's numerous other little improvements, and of course some bug fixes. The release notes are here.

Something I've never mentioned before is that TimeSnapper works nicely on Vista. This has been the case since version 2.0 was released. We haven't got an official Microsoft seal of approval on that yet, so I can't put up a "Works On Vista" logo. Try it for yourself.

Thanks to everyone who's provided feedback at the forums, and to people who tried out the private beta builds.

TimeSnapper's really started to achieve the core features that Atli and I originally discussed. There's still a bunch of stuff we haven't gotten around to, and of course version 2.5 is already well underway. New ideas are still welcome. Marketing is the thing we do worst of all -- so any help in that regard is definitely needed.

Best of luck!

 

TestDriven.net-Gate: Don't Blame Microsoft, Blame Jason Weber

There's a kerfuffle about Microsoft vs TestDriven.Net Express at the moment.

It's interesting stuff, to say the least!

Many of the comments are prefaced with comments like "I haven't read everything about this, but I feel..." and this is a shame because opinions became too polarised, and leap for tabloid explanations such as "Microsoft is Evil" when the truth, as always, is far murkier.

If you have time, you really ought to read the whole thing.

I've read as much as I can, and here's my analysis.

Right from the start, before tempers flared, Microsoft's representative, Jason Weber should've done a much better job of convincing Jamie not to release the express sku. Jason did put a lot of effort in, and Microsoft spent a lot of effort on this, but Jason sabotaged his own sides efforts right throughout.

The first clear mistake is that Jason should've never referred to Jamie's work as a "hack". He did this repeatedly -- and it seems to have greatly exacerbated the situation.

What did that wording gain Jason (or Microsoft)? It only worked to insult the person he was trying to come to agreement with. Name calling doesn't aid negotiation.

When Jamie finally agreed to remove the express version, he wanted a credible reason to put on his website. Note that Jamie had backed down now, and with good treatment the thing should've been resolved at that point. Here's the wording that Jason recommended:

"After speaking with Jason Weber from Microsoft I realized that by adding features to Visual Studio Express I was in breach of the Visual Studio license agreements and copyrights. I have therefore decided to remove support for the Visual Studio Express SKU's from TestDriven.Net. Jason was very supportive of TestDriven.Net's integration into the other Visual Studio 2005 products and I was invited to join the VSIP program. This would allow me to fly to Redmond each quarter and work closely with the Visual Studio development team on deeper integration."

This wording is offensive on four levels. One Two Three Four. That's a lot of offense!

Firstly -- it acts as an advertisement for Jason Weber. Why? Arrogance maybe? He's lording it over Jamie.

Second -- it supposes that Jason should publicly admit to violations. He need never admit such a thing.

Third -- it includes mention of breach of "copyright". I don't think such an allegation ever came up until that point. So this was a fresh insult.

Fourth -- it stings Jamie's pride, by suggesting that he was bribed into agreement. Ouch

So just when they got close to agreement, Jason effectively kicked Jamie in the nuts, pissed in his face, poked him in the eye, and danced on his grave.

That's not a winning technique in negotiations.

Oh, I admit it -- I've made similar mistakes myself in the past. Recently, even. Sorry :-(

But is Jamie in the wrong? Of course he is. It's Microsoft's product -- if they say you can't work around limitations, then good for them. And they can pick and choose what limitations they mean. When you're using their product, you're a guest. You leave when you're asked.

But it's such a touchy topic, that Jamie deserved to be treated with respect the whole way.

One other big no-no from the Microsoft side of the fence is worth pointing out:

When Jamie disabled the express feature, how did Redmond respond? Read this:

Thank you for not registering your project extender during installation and turning off your hacks by default. It appears that by setting a registry key your hacks can still be enabled. When do you plan to remove the Visual Studio express hacks, including your addin activator, from your product.

This gives away that they reverse-engineered his product, to check that he'd really removed support. Ouch! Dirty dirty play! Bad Microsoft!

Oops, that was a tabloid ending, sorry.

How about this:

Test-Driven.Net in Drive-By Shooting!

 

ORM Smackdown!

In case you missed it, there was a very amusing DotNetRocks episode this week, billed as an 'ORM Smackdown' (listen here) between Ted Neward and Orein 'Ayende Rahein' Eini

Here's my summary of some of the points of contention [note that this is in my words, not theirs and i expect i've completely missed the point on most of these ;-) ]...

Ted SaysOren Says
ORMs require extra round tripsYou can always put the ORM layer in the same physical tier as the DB
Adding an ORM increases the Impedence Mismatch...but it's worth it cause it provides loose coupling.
Sprocs can act as loose coupling anyway!No, not really!
Yes really!!No, not really!!
Yes really!!!No, not really!!!
Yes really!!!!No, not really!!!!
Yes really!!!!!No, not really!!!!!
RDBMS neutrality is a premature optimisationNo, not really.
Sql Tuning is platform specificAn ORM can have platform specifics tuning
Maybe, but the ORM would be a lot of hard workNo it's easy! Try it!
I have and i hate it!I have and I like it!
When the ORM changes the schema, the DBA is gonna have a heart attackDB Schemaing Versioning is fundamentally hard: it's not ORM's fault
But ORMs make it worseNo no, they make it better.
ORMs put inheritance info into the DB schema. I hate that!I don't really mind...
The db schema is the master!The object model is the master!
An object-database, between the App and the real database might be the way to go!How about an intermediate ORM controlled database, in between the App and the real database
Object-databases -- they're not ready for 'enterprise' yet but when they're ready, they'll be greatMaybe Object Databases are the future.

Me, I don't get the whole object database thing, I just groan and think nah, I'm not going to start using nHibernate, nor am I going to look for object databases.

I'll use Linq, and I'll keep using CodeSmith. I'll keep using Stored Procedures, and I'll keep working hard and looking around. But ORM, not for me just yet.

 

MicroISV: Step 4 of 25 -- Basic Website Content

(This is Part 4 of 25 steps to Build a Micro ISV)

(A MicroISV, in case you were wondering, is a very small software company that turns a profit. The sort that any hard working software developer can run in their spare time. My MicroISV is called TimeSnapper)

In the previous step (Web design for MicroISVs) we dodged a big nasty bullet: we side-stepped the need to work hard on the graphic design of our website. Great move! We grabbed our beautiful, professional-looking web template straight from an online repository. Yoink! Thank you!

Unfortunately, this time around we don't get any such luxury.

There's no secret website where talented copywriters have put together pithy product descriptions, witty taglines, catchy headings, all yours for the taking. There's no pre-written FAQ for your product, no ready to use helpfile.

You have to fall back on your own damn meager skills for this one.

Lucky you're qualified! You create applications, so we know you're creative. You write and refactor code, so we know you can write and edit. You use an IDE, so you can master a word processor.

Most importantly, years of developing software have taught you that one lesson, more important than any other (a lesson for marriage, for marketing, for being a decent brother, father, son, employee, boss, president, counsellor, priest, doctor, ... you name it, the big lesson, which lies at the heart of both good software and good writing... drum roll please!)

You know how to:

Put Yourself In The Other Guy's Shoes.

And of course it's a deceptively hard skill. Looks easy, but isn't.

There are books you can buy on the topic, expensive courses you can attend, just to learn this lesson. Marketing weasels will go on about it until you want to stab them with a pen. But software development drove this message home to you a long time back. Understanding that the "customer's" point of view is different to your own. Big thing to keep in mind. Don't forget that. Let that be your all-weather compass, and so on. You get the picture.

Start With A List

Your MicroISV is in need of a website. So where do we start?

First, we need a general plan for how we're going to write this website. So, first up I think we want to know what pages you intend to include.

After reading millions of webpages from thousands of ISV's (possible exaggeration right there), here's a bunch of likely candidates.

  • Landing page / Front Page
  • FAQ
  • Help page
  • What's new (aka release notes)
  • screenshots
  • tour
  • Demonstration movies
  • Comparison between your free and professional versions
  • Comparison with competitors
  • Testimonials
  • Forums
  • Blog
  • Contact us
  • Support
  • Purchase
  • Thank you for purchasing
  • Sorry you quit purchasing half way through ;-)
  • So you'd like a Refund
  • Sign up for... something
  • Privacy Statement
  • About

Jaysus! That's a lot of pages! You'd better cut most of them out -- draw a line through every page you can.

Get it right down to just the pages you need for release day 1.

Maybe five pages.

Don't include any pages that are 'nice to haves' or pages that you can inlcude later.

And please, make this agreement with yourself: Your website will absolutely refuse to have any pages that say 'Coming Soon' -- or any synonyms of that phrase.

("Coming Soon" is just a lie. If only we, website authors, could admit it to ourselves.)

The List Is Small

It's a very small list. A minimum list of pages. Short. Nothing but the most urgent. Can we start writing yet? Not till we check our shoes...

Now's the time when we've got to put ourselves in the user's shoes.

This product isn't for us. It's for the user. It helps the user. It takes away their pain. It makes them happy. It does something that must be done.

And every page on your website is for the user too. It answers their question, guides them to the information they need, puts their mind at ease, entertains them, enthralls them -- whatever. It does something for them -- and if it doesn't, then don't write it. Cut that page out of your list right now.

The List Is Even Smaller

And it's time to write. We start of course with whatever page is most helpful to the user. Perhaps the landing page. And this is where you need courage.

It takes courage to write that first draft. You have to silence the nagging doubts. Appease the hyper-excessive rumination of your pre-frontal cortex.

The greatest advice out there is from someone called Anne Lamott who talks about the "Shitty First Draft".

"...the only way I can get anything written at all is to write really, really shitty first drafts.

"The first draft is the child's draft, where you let it all pour out and then let it romp all over the place, knowing that no one is going to see it and that you can shape it later...."

And the 'Shitty First Draft' school of writing is much more successful than the Gene Fowler approach:

"Writing is easy. All you do is stare at a blank sheet of paper until drops of blood form on your forehead."

So go away right now and crank out some awful Shitty First Draft of your most important page. No one has to see it. Maybe there's a good sentence or two in there -- you take the best and discard the rest, cutting and expanding from low quality material until you have a fairly coherent piece of raw copy.

So we started with Shitty and we've ended up at Raw.

In theory you can take your raw copy and have a friend review it -- but I don't recommend that idea (I used to, but no more).

Feedback is crucial -- but I've learnt that premature feedback is a waste of everybody's time.

My theory used to be: "why polish the bits that are going to be excluded anyway?" -- the old maxim:

"if a job's not worth doing then it's not worth doing properly."

But i no longer follow this belief.

Now I realise that if you get people to review your work when it's completely unpolished, then their feedback will focus on obvious things you already knew. (e.g. spelling mistakes, grammatical errors). This kind of feedback will get in the way of the more valuable, deeper feedback you're after: the sort of analysis that you can't do by yourself. So spend a little time polishing it up before handing it over.

Proofreading 101

The polish you can apply to your Raw draft is a form of "checklist" proof reading.

In the "checklist" technique you move through your text a number of times, looking for different things each time. Once you've used the 'checklist proof reading' technique on a few pieces of writing, you'll begin to perform it in less passes.

You may need to build up your own checklist. I'll provide one below -- but you could also consult the classics (for example, George Orwell wrote a very nice checklist).

Checklist proof reading:

  • Fix your spelling. -- Commonly Mispelled Misspelled Words
  • Don't use the wrong word:
    • Your, You're
    • Their, They're, There
    • To, Too
    • "a lot" (not "alot")
    • Its, It's
  • Use Active words -- remove inactive crap.
  • Remove excess verbiage
  • Remove "-ly" words.
  • If you're not certain of the grammar around a particular phrase, then switch the phrase out.
  • Remove potentially offensive content

Once all these little steps are done, your work is ready to be reviewed.

If however, you weren't happy with the results -- there is another proof reading technique that gives far better insight into your writing. And this technique has only one step:

Read It. OUT. LOUD.

Reading outloud is a great way to expose dodgy writing for what it is. (Note to self: read my own stuff out loud a lot more in future.)

Hand It Over

If English is not your main language, then I advise getting your work reviewed by someone who has mastered English grammar.

And on the other hand, if English is your main language, and you've been speaking it and using it all your life, I still advise getting your work reviewed by someone who has mastered English grammar ;-).

Who's the best person to use for this review? Why, your assistant sub-editor of course.

What do you mean you don't have an assistant sub-editor? What else is a wife/secretary/girlfriend/mother good for?

Find someone who is not your boss, someone who loves you unconditionally, who doesn't love your product like you do, and who is not as technical as you. Plead with them until they agree to read through it with you. They love you unconditionally, so they will agree. They won't hate what you've written, but they'll know which problems of style are the important ones. When you hear your words spoken through their mouth -- you'll know what's wrong.

Conclusion

Once you've jumped through all of the above hurdles, you will have a terrific piece of writing. And from the previous step you've got a nice looking website.

Now it's just a shame that no one visits it. Or do they? With out traffic monitoring, you won't have a clue. So in the next step, we'll investigate this wonder of the modern age.

 

The Yerkes-whatzy law of who now?

Yerkes-Dodson Law of Arousal

In psychology they have something called 'The Yerkes-Dodson Law of Arousal' which goes roughly like this:

'Arousal' doesn't mean sexual arousal, you dirty-minded buffoons, so stop sniggering. 'Arousal' means 'Cognitive Arousal' and could also be taken to mean 'alertness', or 'pressure'. A common synonym is 'stress'.

The YD-Law is demonstrated in the graph shown on the right.

Let's break the graph into three regions:

  1. When your stress is low, you won't perform well.
  2. With just the right amount of pressure you'll achieve your peak performance. This is sometimes referred to as being "In The Zone."
  3. With too much stress your performance will degrade.

We can term these three regions as "Low Stress", "Optimal Stress" (aka 'The Zone'), and "Over Stressed".

(Continues)


Now what can we surmise?

When you're in the "Low Stress" region, you need more stress to improve your performance. Telling yourself to relax will not improve your performance.

When you're in the "Over Stressed" region, you need less stress to improve your performance. Getting mad at yourself will not help. A manager emphasizing the deadlines will not help. A manager jumping up and down and screaming at you will not help.

If you've been slowly ramping up the stress on your employees, you may, just possibly have found some improved performance. This doesn't mean that further increases in stress will continue to cause improvements in performance. Instead you may find your employees beginning to turn into walking zombies.

And if you're suffering from procrastination -- take a moment to decide whether you're under-stressed or over-stressed.

For the over-stressed:

Go easy on yourself.

Don't try to push yourself harder. Your performance will only decrease.

Chill out a little, take a few long slow calm breaths.

Close your eyes and take a few more slow deep breaths.

Think relaxing thoughts.

For the under-stressed:

Don't try to chill out: Try to perk yourself up instead.

Go for a run, or a brisk walk, whack a shot of coffee down your throat.

Get active. Extra deep breaths, not so slow, not so calm.

But It Could Also Be...

One other point though: if you're exhausted, hungry, thirsty, intoxicated, or just busting to pee, then the YD-law isn't what's limiting your performance: deal with your bodily needs, dude. Sleep, Eat, Drink, Dry out, Pee: don't put it off any longer, your performance will only get worse.

Now: Let's Go 3D

Getting back to the YD-law, consider a range of tasks with different cognitive requirements: a game of sudoku, a fight to the death, a bout of furious making love, and a quick game of darts. (Your standard morning).

All of these tasks will have different optimal stress levels.

For simple tasks, a higher amount of stress will result in optimal performance.

Energetic But Not Thinky: Maximum Stress is Best For example, imagine you are performing in a short sprint. What sort of arousal will lead to your best performance? The YD-Law predicts that a simple task like sprinting is best achieved at a very high level of physical arousal (see the image at right). For example, having your track team pursued by a blood-thirsty man-eating lion would be a good way to encourage maximum performance. Soothing music would not help.


The Yerkes-Dodson Law of Arousal Another task, such as playing a game of Tennis, might combine mental flexibility with physical strength, and peak at a slightly lower stress-level. It's very possible to get psyched out, but it's also possible to be under-enthused. The blood-thirsty lion would be likely to put you off your game (you'd get "psyched out"). Soothing music might also be too calming. But an enthusiastic and energetic crowd will probably help spur you to your optimum level of stress.


The Yerkes-Dodson Law of Arousal Consider a purely logical task, such as solving a Sudoku square: too much stress will quickly cause decreased performance, and the peak is reached at a very low level of stress. The blood thirsty lion will definitely not spur you onto a faster performance. And the cheering crowd will probably put you off. In fact, just one person looking over your shoulder might be too much pressure. The soothing music is probably useful, provided you don't go to sleep.


Yerkes-Dodson in the Work Place

Now let's apply this new piece of information to the office setting.

A "high pressure" sales team, for example, will peak at a different level of excitement to a busy team of computer programmers. So if your open-plan office puts thinky-programmer types side by side with a talkative and intense sales team, the programmers will get over-stimulated, over-stressed and anxious.

Ditto for putting the marketing team next to the accounts payable team.

Forget Feng-Shui for the office -- this is "Yerkes-Dodson for the office". A far more valuable concept. (Note to self: write book on this and tour the globe giving expensive talks)

In our society i think we have more problems with the "right hand side" of the YD graph (over-stress) than we do with the left hand side.

This 'Right-hand' lifestyle is characterized by a sense of "desperate-Urgency" and ongoing exhaustion, through which you push yourself to achieve more.

When in this "urgent" frame of mind you never realise for a moment that slowing down, pushing yourself a little less, will actually increase your productivity. You're in a frame of mind that thinks the only solution is to push harder! Faster! Do More! Get More Things Done!

In our society we've removed real physical dangers from our environment. There is no lion hiding behind the water cooler, about to leap out at you. The threats we face are not physical. They're threats to our ego, our self-esteem, our work hours, our take home pay. Less physical, more abstract, more long-term. Such dangers are best faced with a cool head. Getting steamed up won't push you into achieving a better response -- it will push you past the optimum Zone.

So, think Yerkes-Dodson.

Chill out when you're stressed out. Stress up when you're too chilled.

Be good to each other. Pay for that free software you're using. Wear sunscreen. Go easy on your bus driver -- those guys have the most stressful job of all, forgive them their cranky temperament, just be glad that you don't drive the bus.

And don't hit people on the head when they're trying to learn asp.net. It won't help.


(The excellent illustration above is courtesy of The Manitoba Farm & Rural Stress Line)

 

Faster Than Light -- For Real This Time

Doekman has posted an example implementation of FTL.

"FTL" ("Functional Text Language" or "Faster Than Light"), is one of the "million dollar ideas" I posted about a little while ago.

It gives wikis the ability to use input controls and dataflow formulae (the same type of formulae you use in spreadsheets).

Hence, when fully implemented, it would be the fastest and most open way to develop a simple web application. We're talking blisteringly fast stuff.

It's one of my favourite ideas -- but I've never had time to take it further.

A few people contacted me about this idea when I re-blogged it -- and I'm really glad to see an implementation.

Doekman's demo has some nifty features too -- there's built in range operations for summing or averaging a group of controls in one go. (You can go "@Sum(t1..t10)" for example to sum up ten textboxes). He's done the tooltip text thing I'm after where the formula behind a textbox is visible as the tooltip for that textbox.

There's no comment facility at Doekman's blog -- so leave feedback here with me (as a comment) and I'll make sure it gets to him.

Also doekman: -- please email me! leonbambrick at gmail dot com.

 

Text Files -- What are they good for?

At TimeSnapper we use a text file for managing our todo items. Plain Old Text (P.O.T) -- are we potty?

Someone I know and respect tells me I'm crazy -- that we should use a bug tracking application, or a wiki, or, basically, anything at all would be an improvement.

Are they right? Am I crazy? No and Yes, respectively?

Our todo file is checked into the source repository (we use sourcegear vault), and included in the main TimeSnapper solution. Multiple people can work on the todo file at once, and can merge their changes together if needed.

The downside to using a text file: you can't include images. But you can include url's that point to images, and notes referring to other files as needed.

It's a semi-structured text file, in the sense that we have conventions we use for keeping it tidy, succinct and relevant. We archive portions off, once they're completed. We separate it with headings, we nest information with indenting.

So what's wrong with using a text file?

The complaint this dude made was that it's "not gonna scale".

Well, maybe it won't scale to a point where we have fifty developers working on TimeSnapper.

But we can safely wait to cross that bridge when we come to it. Text files hardly lock us in. The data is easy to export. ;-)

What do you say? Can a globally distributed two person ISV track their tasks more efficiently in some other way?