Don’t be fooled into paying these invoice-like documents…

This is old hat now, but it has raised its head once more…ILSCorp are sending out official looking requests for money.

I’m not saying this is a scam per say, but a quick Google reveals this, this and this, so I’ll let you make your own minds up.

There are a few giveaways: cheque is spelt check for example. Whilst it does state “this is not a bill”, it does have that official look’n’feel about it.

If you’ve received documents that look like those below, my advice to you is to shred it and ignore it.

ils1ils2
ils3

XP Home vs XP Pro

A lot of folk (mainly friends and relatives) have been asking for my IT advice recently. I’ve been asked about the differences between XP Home and XP Pro – the question usually arises when the conversation reaches the point of discussing costs. Whether you agree with me or not, I’ve been sending them to Dell’s web-site: I’ve not had a problem with Dell so far. I have used an Inspiron 7000, 7500 and now have an 8600 – apart from the screen resolution on the 8600, it’s a great laptop. The screen resolution is 1280 * 800, which is totally useless for a developer – I didn’t order this screen, but the person who did, well, she goofed up big time, and now I have to live with it. In fact, if it’s a laptop you’re buying, forget the 1280 * 800 and get the best screen resolution you can afford – it’ll save you hours of “scrolling down” over the course of the laptop. Anyway, I disgress…so far I’ve been recommending Dell 5100 towers (not the half-sized silver ones) and have no problems with them at all. However, I’m prepared to accept that your mileage may vary.

For a typical (and real) home user, there’s not much benefit to be had from XP Pro. Unless, of course, you’re expecting yours truly or a.n.other to provide you with support via the Remote Desktop. You might save a few pounds on the operating system, but if you then go and break it such that you ask me to come and have a look at it, I won’t be able connect to it from the comfort of my own home. Of course, there are alternatives to the remote desktop, such as LogMeIn and GoToMyPC, however there’s no guarantee that these services are free or will remain free (even though I’m hearing good things about them).

However, if you’re a business, of any size, remote desktop might not be your key driver. XP Home doesn’t support the concept of groups, all users that are created belong to an “Owners” group…which is pretty much the same as giving them an Administrator account. For most home users, this isn’t a problem, but for business users, giving employees admin rights can be a major problem. That said, even for home users, a lot of support issues surrounding spyware, etc. could be solved if the users were using a lower privilege account.

For more XP Home vs Pro comparisons, take a look at Paul Thurrott’s site.

In search of haggis

You may recall that I was reading the French version of hackin9 magazine…well, it was Alex’s copy (he’s French). Before his return to France, he wanted to try haggis. So I obliged and found a suitable outlet: Bad Ass Bistro (yes, rather oddly named, however the food is excellent and it’s not “one of those” pubs you find elsewhere in the same street)

Alex attended a number of Scottish Developers events, which led to me offering to proof his dissertation (for which he got a distinction).

Here’s Alex:

haggis1

And here’s yours truly:

haggis2

Quote: Jeremy Clarkson

During my recent travels, amongst other things, I was reading Jeremy Clarkson’s book The World According to Clarkson – it’s an excellent and humorous read, I can strongly recommend it. It had me laughing out loud…on board a fairly full easyJet 737-700 en route from Bristol to Edinburgh.

The book is a collection of his columns from The Sunday Times; I found his take on “facts” rather amusing:

The More We’re Told the Less We Know
…if you have all the facts to hand, you will see that there are two sides to every argument and that both sides are right. So, you can only have an opinion if you do not have all the facts to hand.

This would explain why we find ourselves listening to a lot of opinion. Very few people have all the facts, even if they are under the impression that they do – they are most likely confusing inadequate or inappropriate information as being correct and factual.

Blogging personality

From here, via here.

***Your Blogging Type is Kind and Harmonious***

You’re an approachable blogger who tends to have many online friends.
People new to your blogging circle know they can count on you for support.
You tend to mediate fighting and drama. You set a cooperative tone.
You have a great eye for design – and your blog tends to be the best looking on the block!

Uncannily accurate, except for the latter half of the last line 🙂

Microsoft Office Advert

Two things spring to mind:

1. I seem to see a lot of Microsoft Office adverts…what’s that telling me? I’ve posted two here, I have seen many more.

2. There’s probably some copyright issue here. However since this posting is essentially a free advert, I can’t imagine there being a problem…

Microsoft Office advert

Actually, there’s a third thing that comes to mind, and this is a rhetorical question: how could something like the scenario depicted in this advert ever possibly occur? You’d have to be mad, insane and stupid to accidentally forward everyone’s salary information to the whole company! Hang on, that’s why the characters are dinosaurs, now I get it!

Hakin9 Magazine

I was introduced to Hakin9 last week. Here’s how the hakin9 web-site describes itself:

hakin9 is a magazine about hacking and IT security, covering techniques of breaking into computer systems, defence and protection methods. Our magazine is useful for all those interested in hacking – both professionals (system administrators, security specialists) and hobbyists.

Granted I was reading the French edition, however the quality of the articles was amazing. Some of the articles and tips’n’tricks were scary to say the least.

There’s an English language version available, I think I’ll be taking out a subscription to this magazine in the near future.

Quote: Boris Johnson

Boris Johnson’s column on page 22 of The Daily Telegraph, 24/11/2005, the subject matter of which is not something I wish to discuss on this blog (but here’s a clue), carried an excellent quote:

If we suppress the truth, we forget what we are fighting for, and in an important respect we become as sick and as bad as our enemies.

In some respects this can be applied in the work-place too. It’s important not to suppress the truth at work, otherwise employees become disillusioned, communication becomes garbled and some folks end up joining the “if you can’t beat them, join them” camp – something that is wrong on so many counts.

Related Posting: #10 – The truth is best…admit it…

TDD, Visual Studio 2005, Scott Bellware’s blog post

In response to the MSDN Test-Driven Development Guidelines, Scott Bellware has an interesting rant over here.

Update: before I could post this entry, the MSDN posting had been removed, luckily I saved a copy elsewhere. Since I’ve just spent the last few minutes writing this, I’m posting it anyway. Here’s what’s there now:

Guidelines for Test-Driven Development
This topic is obsolete and has been removed from the MSDN documentation.

It would appear that the MSDN posting has hit a nerve in the TDD community, and on first impressions, rightly so. I’m about to embark on a couple of days travel, I’ll be taking some of the material surrounding this posting and rant with me to read, expect to see me follow it up later this month.

To pick on a few posting (on the off chance you’re not following this rant elsewhere): Scott Dockendorf steps up and denounces any involvement in the article over here. Agile guru Roy Osherove is very vocal about the article in his Microsoft fails miserably to explain or promote Test Driven Development in Team System posting. And Julian M Bucknall is all depressed about it over here.

On a separate note, and it’s perhaps why I associated this posting with my “Opinion” category (not that this counts for much, but I feel as if that category lets me write what I like and not get sued! That’ll be right!), as an MVP should I be seen to be criticising Microsoft? Ignoring the relationship that exists, if an organisation did something that was wrong (in the eyes of the majority), I would feel professionally obliged to point out the error in their ways. Even after nearly a decade in the same organisation where such an attitude is pretty much frowned upon, I still maintain this professional desire to see things done properly. However, again on first impressions, I see that the MSDN posting is rapidly becoming MSTDD, so at least the differentiation is there. Hopefully all the TDD newbies will catch up on TDD postings prior to embarking on what amounts to a shoe-horned flavour of TDD.

More when I return from my travels.

Here’s the original MSDN posting:

Visual Studio Team System
Guidelines for Test-Driven Development
If your software-development project uses test-driven development, or TDD, you can benefit from features of Visual Studio 2005, and in particular, features of Visual Studio 2005 Team System. These features include the unit test type of Team Edition for Testers, and especially the ability to generate unit tests automatically; automatic refactoring capabilities that are introduced in Visual Studio 2005, and the Class Designer tool.

The unit test support of Team Edition for Testers is particularly suited to TDD because these Team System testing tools can generate tests from a minimum of production code.

Process Example
In your TDD project, you might want to follow these steps:

  1. Define the requirements of your application.
  2. Familiarize yourself with the feature areas of your application, and decide on a single feature, or the requirements of a feature, to work on.
  3. Make a list of tests that will verify the requirements. A complete list of tests for a particular feature area describes the requirements of that feature area unambiguously and completely.
  4. File work items for feature requirements and for the tests that need to be written.
  5. In Visual Studio, create a project of the type you want. Visual Studio supplies the initial production code in the form of files such as Class1.cs, Program.cs, and Form1.cs, depending on the project type.
  6. Define the interfaces and classes for your feature or requirement. You can add a minimum of code, just enough to compile. Consider using the Class Designer to follow this step. For more information, see Designing Classes and Types.
  7. Note
    The traditional TDD process does not contain this step. Instead, it advises that you create tests first. This step is included here so that, while creating tests, you can take advantage of two features in Visual Studio 2005 Team System: the GUI design capabilities of the Class Designer, and the automatic test-generation capabilities of Team Edition for Testers.

  8. Generate tests from your interfaces and classes. For more information, see How to: Generate a Unit Test.
  9. Compare the tests that have been generated with the list of tests you prepared in step 3. Create any tests that are missing from the list you wrote in step 3. For more information, see How to: Author a Unit Test.
  10. Organize your tests into test lists. You can, for example, base your lists on test use, such as check-in tests, BVTs, and tests for a full-test pass; or on area, such as UI tests, business-logic tests, and data-tier tests. For more information, see How to: Organize Tests into Test Lists.
  11. Update the generated tests to make sure they exercise the code in ways that cover the requirements that you have defined.
  12. Run your tests. For more information, see How to: Run Selected Tests.

    Verify that all your tests fail. If any test produces a result of Inconclusive, it means that you did not update the generated code to add the appropriate verification logic for that test. If any test produces a result of Passed, it means that you did not implement the test correctly; this is because you have not implemented your production code, so no tests should pass.

  13. Implement the interfaces and classes of your production code.
  14. Run your tests again. If a test still fails, update your production code to respond. Repeat until all the tests pass.
  15. Pick the next feature or requirement to work on and repeat these steps.