A small, but useful, PowerShell function that I have in my PowerShell profile that reads the default repo path from .hg\hgrc and launches it in the default browser. This means after I've done hg push I can just ype kiln to quickly get to the repo page to raise code reviews, etc.

It's been a little while since my prediction, but I just got email notification of the "Native Git support" issue on Google Code being fixed!

http://code.google.com/p/support/issues/detail?id=2454

I've checked this, and you can indeed select Git for your new projects. See - I told you it was coming ;-)

Of course, we've all moved to Bitbucket and Github now, so it's unlikely anybody cares! :/

I was recently discussing the value of comments in code with some colleagues. After the discussion, one of them sent me a link to "Don't Waste Your Time Commenting Source Code" written by Riyad Mammadov.

I have to say I'm both shocked and disappointed that there are developers out there that have this opinion. And there seems to be quite a lot of them. I'm quite passionate about code comments because I spend the huge majority of my time maintaining/debugging/fixing code written by other people that has no comments (other than commented out code...). I waste an enormous amount of time stepping through code with a debugger, just trying to understand WTF it's trying to do.

I know some developers that always respond "The code is self-explanatory". This is a garbage excuse from a lazy programmer. There are a few reasons why this argument is not valid:

1. It might be self-explanatory to you, but there are other developers here that may need to maintain your code, some less skilled than others.
2. Unless you're a compiler, reading an English comment is far quicker than parsing code in your head.
3. It's rarely clear from code why it does what it does.
4. Reading code only helps you understand what it does, not what it was intended to do. This would be fine if you wrote flawless code. You don't.

In addition to this, we often have to write less-than-ideal code. You might find a bug, and to work around it, change some nice clean code to something a little bit hacky. If you don't comment why, there are good chances that someone will come along, think "WTF, this could be done better" and refactor your code, re-introducding the bug. A simple comment saying "Can't do this using X, because it causes Y to fail" could save a lot of time and effort.

Back to some of the points made in Riyad's article...

I strongly believe that 90% of source code comments are a waste of time

I think Riyad is a little confused between code with crap comments, and code that doesn't need commenting. I can't possible agree that only 10% of all code written is worth commenting. I might agree that only 10% of code comments are useful, but that just means the developers are failing at writing good comments, not that the idea of writing comments is bad. A huge portion of useless comments on code could be replaced with useful comments.

if you think about it, a well-designed program doesn't need comments to be maintainable

This really is tripe. Code does not convey the *reason* you are writing it. Here's an example from some real code:

// When the transition finishes, hide the screen. We don't remove it,
// because we want it to come back when the covering screen is dismissed
this.ScreenState = ScreenState.Hidden;

Without the comment, it might not be clear why the screen is being hidden, instead of being removed. Somebody that's not familiar with the code (which, six months after it being written, is everybody, including the author). The comment makes this pretty clear why the code does what it does.

If the choice is between a well-designed program without comments and a thoroughly commented but poorly architected one, I will choose the former any day of the week

I don't understand the logic here. There is some suggestion that writing comments comes with a penalty that somehow affects the architecture of your system. I think a more valid comparison whould be "Unfinished, but commented code" vs "Finished, but uncommented code", and I would absolutely take the commented code any day. It's unlikely that it'd take longer to finish a well written, well commented application than it would to try and understand thousands of lines of uncommented code.

Riyad shows some sample code to illustrate his point:

/**
 * Always returns true.
 */
public boolean isAvailable() {
    return false;
}

There's no argument here. This comment is pointless. However, there's some suggestion that because this comment is pointless, this code does not need commenting. That is absolutely not the case. The comment is crap. It should be replaced with one that is not crap.

Not writing code comments because some people write crap comments is like not writing code because some people write crap code.

Sadly the biggest loser in all this is not the developer that's not writing comments, but his colleagues. They'll struggle to maintain his uncommented code while he easily understands their well-commented code :(

Over the last few days, I noticed Google Wave Notifier complaining of login issues. I finally got around to looking at the problem today, and unfortunately, it's not good...

With no Google Wave API, when I wrote Google Wave Notifier, I had to scrape the pages and parse text out of some JSON to figure out what your new messages were. Knowing this was likely to change, GWN was written to alert the user if the parsing failed, explaining there had probably been an update to Google Wave, and GWN would be updated soon.

Unfortunately, Google changed the way Wave works recently, and I've been unable to figure out a way I can make GWN continue to function without significant changes. Since Google are ditching Wave soon anyway, I've decided not to invest the time required to make these changes.

It was great fun to work on an open source project that was downloaded by thousands of users across the many versions, but sadly that journey has come to an end. I'd like to give a huge thank you to all of the people that used GWN and reported bugs, spurring me on to continue developing. And let's not forget everyone that contributed a translation, allowing GWN, unlike other Wave notifiers, to be used all around the world.

I'm sure I'll find other little projects to work on with some of the spare time I have, and I'll be sure to post updates here. Subscribe to the RSS Feed or follow me on Twitter for updates!

Version 1.9 of Google Wave Notifier is now available. Unfortunately I didn't get around to adding Google Apps support, because it's turning out to be more complicated than expected, but I'm still hoping to have it done soon. The new features in v1.9 are:

• Changed source code over to Mercurial from SVN :)
• Added ability to customise the URL used to open Wave to support options like "minimized:nav,minimized:contact".
• Reduced minimum poll frequency to 1 minute.
• Added code to check for the presence of a network before checking for new waves in the background.

Fore more info, visit the Google Wave Notifier website or go direct to the Google Code project page for the download.

The source code for Google Wave Notifier is available (using Mercurial), so if you're got an idea for some new features, I'm open to acceptable patches!

For further updates on Google Wave Notifier, you can follow @WaveNotifier on Twitter!