KeyTraino

KeyTraino is a tiny and super useful utility.

KeyTraino knows all the keystrokes for all the applications you use.

KeyTraino knows all about the office suite, many business applications, many development tools (even query analyser!)

When you're using an application and you hold down the control key, the alt key, or the WinKey... KeyTraino provides a friendly semi-transparent popup window (don't worry -- no animated paperclips) that gives you all the options available to you for the current application.

When you hold down a function key -- KeyTraino tells you what that key will give you, and what it *can* do if you combine it with other keys...

(continues...)

When you use the toolbar, the menus or the context-menus of an application, KeyTraino shows the alternative keystroke you could've used.

If you let it, KeyTraino will record your behaviour inside an application (microsoft word, or visual studio for example). Using this information keytrain is then able to provide you with a neat little summary of what keystrokes could be helping you the most. Not unlike TimeSnapper, you can leave KeyTraino recording all the time, and it won't noticeably impact the performance of your machine.

KeyTraino is something that Jon Galloway could use to help him achieve Mouseless Computing. Keyboard junkies like Scott Hanselman should be all over KeyTraino. Jeff Atwood, from Coding Horror, would love KeyTraino, if he ever tried it.

What does KeyTraino do for developers?

As a developer you can build a KeyTraino file that will tell KeyTraino what keystrokes your application uses, and what features are on your toolbars, menus etc. Send this file to the KeyTraino website and it will be available for slurping into people's copies of KeyTraino, is they use your application.

Why is KeyTraino so much less annoying than Clippy?

There's three things that stop it from having the annoyance factor of old clippy.

Firstly, because you deliberately installed it, you are not alarmed by its sudden appearance.

Secondly, it doesn't combine its advice with a pushy personality.

Third, when you tell it to go away, it goes away completely, and doesn't return until you tell it to. It goes away immediately, not stopping to show off some clever 'exeunt' animation.

But what do I like about it best? My favourite feature is that this is another purely fictional piece of software. This means that in my imagination it behaves seamlessly. It's fast, bug-free, and reliable. It never gives you information you don't need and its information is never out of date.

Ah, dreaming of software.

 

You Will Set Goals!

You Will Set Goals!

You Will Set Goals!

You Will Do Your Best!

You Will Set Goals!

Continues...!

You Will Trim Those Big Bushy Eyebrows!

You Will Set Goals!

You Will Point A Lot With Your Index Finger!

You Will Set Goals!

You Will Pretend You're Holding A Pistol In The Other Hand!

You Will Set Goals!

You Will Focus The Reader's Attention To A Long Narrow Strip In The Centre Of The Page!

You Will Set Goals!

You Will Dress Up In A Suit And Get Photographed In Front Of A Purple Sheet!

You Will Set Goals!

YOU WILL SET GOALS!

You Will Set Goals!

YOU WILL BE THE KING ONE DAY AND EVERYONE WILL BE SORRY!

You Will Set Goals!

(apologies to Brian Leaning-Mizen from 15 minute goal setting)

And here's a genuine innovative little goal-setting tool: joesgoals.

 

Very detailed and serious comparison of functional and imperative programming styles

Very detailed and serious comparison of functional and imperative programming styles

Alright, it's not a detailed and serious comparison of functional and imperative programming styles.

It's just a modification of a picture that accompanied an article in american scientist magazine, written by Brian Hayes.

I've been thinking about functional programming since i read 'functional programming for the rest of us', last week. fascinating topic for your geeky-minded kid like me.

'Currying' and 'Pattern-Matching' look like two pieces of syntactic cleverness that could be baked straight into any .net language.


Very detailed and serious comparison of functional and imperative programming styles
 

How the 'ref' keyword affects the use of objects

This is something that doesn't make any sense until you've stepped through it carefully. And it's something that i didn't understand correctly (or hardly think about) when I was programming in VB.net.

What exact difference does a ref keyword make, when applied to a class-type parameter, anyway?

[VB Note: substitute the keyword ref for ByRef, and know that a C# parameter without a ref keyword is considered ByVal by default. So the sentence above could read: "What exact difference does a ByRef keyword make, when applied to a parameter that is a class-type?"]

First up, a re-cap of how 'ref' affects simpler variable types....

(continues...lots of code examples!)

Imagine we have a little function like this:

    private void TryAndChangeTheValue(string name)

    {

        name = "Ziggy Stardust";           

    }

And we call it with some code like this:

    string Name = "Jimi Hendrix";

    TryAndChangeTheValue(Name);

    MessageBox.Show(Name);

What happens? Does it return 'Jimi Hendrix' or 'Ziggy Stardust'?

It shows 'Jimi Hendrix'. Because the parameter does not have the 'ref' keyword, a copy of the value 'Name' is created, altered and then not returned from the stack. So the initial value of 'Name' is displayed in the messagebox.

If you want the function to affect the displayed message, you need to use the ref keyword, as follows:

    private void TryAndChangeTheValue(ref string name)

    {

        name = "Ziggy Stardust";           

    }

And you need to add the keyword ref to your calling code:

Now when the above code is run, the value 'Ziggy Stardust' will be displayed.

Okay, recap over. Time to think about classes.

But what happens when you do (or don't) use the ref keyword on an object parameter?

Imagine we have a simple little class like this:

    private class NameClass

    {

        public string Value = "Jimi Hendrix";

    }

It has one public field, 'Value' which defaults to 'Jimi Hendrix'.

And now imagine we have a function that looks like this:

    private void TryAndChangeTheValue(NameClass name)

    {

        name.Value = "Ziggy Stardust";           

    }

It accepts a 'NameClass' object, and changes the name property to 'Ziggy Stardust'.

Now what happens when we call the method, and then check the value...

    NameClass name = new NameClass();           

    TryAndChangeTheValue(name);

    MessageBox.Show(name.Value);

Will the messagebox show 'Jimi Hendrix' or 'Ziggy Stardust'?

Before you answer, consider this case:

What if we changed the function to look like this:

    private void TryAndChangeTheValue(ref NameClass name)

    {

        name.Value = "Ziggy Stardust";           

    }

So that now the parameter is of type reference. (We'll also need to add the 'ref' keyword to our calling code)

    NameClass name = new NameClass();           

    TryAndChangeTheValue(ref name);

    MessageBox.Show(name.Value);

Will the 'ref' keyword make any difference to our test? If so, why? If not, why not?

For both these tests, the result will be 'Ziggy Stardust'. The ref keyword won't make a difference to the results.

Does that mean that the ref keyword was ignored? Not at all.

The important thing is that the ref keyword applies to the parameter (name), not to its properties (name.Value).

So let's look at a case where the function doesn't just change a property of the parameters, but tries to change the parameter itself. In that cases the ref parameter will make an important difference.

Here's an example where our function gets sloppy and drops the object.

    private void TryAndChangeTheValue(NameClass name)

    {

        name.Value = "Ziggy Stardust";           

        name = null;           

    }

What will happen now?

Will this code:

    NameClass name = new NameClass();           

    TryAndChangeTheValue(name);

    MessageBox.Show(name.Value);

Still return 'Ziggy Stardust?' Or will we get a null reference exception?

We will still get 'Ziggy Stardust' out. There won't be a null reference exception, because the thing that was set to null was a value copy of the object reference, not a direct reference to the object.

The object itself wasn't affected by the 'name = null' line. That merely stopped a value on the stack from pointing to the object.

And then consider the same code, but with the 'ref' keyword:

    private void TryAndChangeTheValue(ref NameClass name)

    {

        name.Value = "Ziggy Stardust";           

        name = null;           

    }

What will happen when this code is used to call it?

    NameClass name = new NameClass();           

    TryAndChangeTheValue(ref name);

    MessageBox.Show(name.Value);

Will we get a 'ziggy stardust'? Or a null reference exception?

In this case we get a null reference exception. Because now when the name = null line was executed, it was the reference itself that was set to null, not just a copy of it on the stack.

Okay that's all i want to say about that.

Mistakes A-Plenty

Please feel free to point out any mistakes in this article, i'm sure there are plenty. ;-)

(Miss Takesa Plenty sounds like a femme fatale from a James Bond novel... just thought i'd mention it...)


 

What does 'yep' mean, exactly?

Q:

  What does 'yep' really mean?

Does it mean "Yes, thank you for telling me, i understand?"

Does it mean "I don't understand a single thing you just said, but I'm polite and you seem to like the sound of your own voice, so please keep going?"

Or does it mean "I already knew that. You've just wasted your breath talking to me. Shut up in future, big nose."

A:

  Yep

 

The Top 0 Things You Should Know About Nothing

Overwhelmed by all the top n articles I've seen about obscure, yet fascinating topics, i've decided to give you something simpler, more digestable, and far more easy to scan.

Yes, it's the Top 0 Things You Should Know About Nothing.

Nothing is a big topic, and many people have contributed their ideas to our perception of it. To cover nothing in its entirety would take an unseemly long amount of time.

So we'll begin and end witha very short summary of nothing, covering only 0 topics. Here we go.

That was quick. For further reading here's a list of no links about nothing. Here they are:

And finally I'd like to thank the following 0 people, who contributed nothing to this article:

Okay, I hope I haven't left anybody out.

Thanks for nothing.

 

A friend is getting into .Net -- what's the best thing to read??

The best thing to read, the absolute most essential thing, is the error messages.

When an exception gets raised, don't just call a friend and ask "hey .net is broken can you fix it for me?" -- instead, read the message. google the message, investigate and learn...

best readin' there is those exceptions! full o good learnins.

(this post inspired by K.A.Evans, .NET: The Gospels)

(n.b. the phrase 'full o good learnins' was specifically designed to annoy mike pope;-).

 

6 Tools for Documentation++

class designer

There's at least 6 tools we use at advantech for automating our documentation. That's a lot of tools. They are:

  1. Ghost Doc from Roland Weigelt

    for quickly adding descriptive comments to code.

  2. NDoc

    For turning XML comments into HTML. Generics not yet supported. And to get it to work with .Net 2.0 you have to jump through a flaming hoop while juggling knives between your teeth. (There's also a powertoy for VB)

  3. Class Diagram feature in Visual Studio 2005

    For reverse-engineering pretty pictures of classes. (Example at right)

  4. Visio

    For ER-Diagrams [and tracking schema changes]

  5. XDK

    Tool for building help files from inside MS Word.

  6. Copy Source As HTML

    For when code needs to be pasted as HTML. Installer for vs2005 version here, with instructions on using it.

Any favourites of yer own?