admin

You can download from here (need a Microsoft passport to login). The good news is that it supports running Windows Vista in a virtual machine and running virtual machines with Windows Vista as the host OS, as well as improved performance.

I am often surprised (actually horrified!) to find programmers/developers that have not even heard of Code Complete (by Steve McConnell), let alone read it. If you are a programmer who has not read Code Complete then you should. It should be a required book for all university computer science courses, purchased on day one and lovingly cherished during the course of your studies! Recently, a programmer surprised me even more by belittling it without even having read it (you know who you are). Shame on you!

Every time I pick up ‘Code Complete’ I learn something from it. I am not exaggerating. I’ve owned a copy of this book for a little over 10 years (now in its second edition), and I learn something useful every time I pick it up. I could perhaps say that of only a handful of books. It might be something I’ve forgotten to pay sufficient attention to rather than something earth shatteringly new, but nonetheless I learn something. Don’t take my word for it, do a few searches yourself and look at the accolades, praise and comments by respected practioners.

Actually, now I think about it, I’m not really a Code Complete zealot, just someone who hates reinventing the wheel, especially square shaped ones…

The term SARG (or search argument) is used to describe whether a Transact SQL WHERE clause will be able to take advantage of any indexes present on columns in a table.

For example, this can use an index:

SELECT SomeColumn FROM MyTable
WHERE SomeColumn LIKE ‘Whea%’

But this can not:

SELECT SomeColumn FROM MyTable
WHERE SomeColumn LIKE ‘%eat’

This important topic is covered in some detail in the following references:

pgs 351 – 368, Guru’s Guide to Transact-SQL, Ken Henderson
pgs 318 – 326, SQL Server Performance Tuning Distilled, Sajal Dam

SARGs are also mentioned in this more general performance tuning article.

CodeRush is truly a marvel. It’s an add-in to Visual Studio that makes coding more productive. It really is a superb tool; after you use it for a few days, you’ll wonder how you managed to code without it. In my opinion, there is only one thing wrong with it: the price tag of US400) for a single license. If it cost US$149.00, I would have purchased it without giving it a second thought (I think developers that are buying their own tools or operate as one-man shops will not be able to justify the current price tag. I’m not suggesting they should give it away; I realise how much it costs to create something like this, but they may need to re-think their licensing scale.

CodeRush is well worth checking out. To receive an evalution copy you will need to send an email to the address on this page. There are several training videos here. Scott Hanselman covers CodeRush in part 4 of his Productivity Tools for Developers webcast that I linked to.

I’ve just noticed that Jeff Atwood has posted comments on Steve Yegge’s most recent post. I think he puts it much more eloquently than I did:

“In order for programmers to be effective, they have to believe in what they’re doing. Whether that belief is scientifically and empirically provable or not is completely irrelevant”

A colleague, Vaughan De Vos, emailed me to ask if I knew about Google’s Code Search site. I saw this briefly last week, and thinking it was just Google with a few query modifiers, I didn’t pay it enough attention. I’ve tried a few searches and the results are interesting.

EDITED TO ADD (11th Oct 2006): Static Code Analysis Using Google Code Search

Steve Yegge caused such a stir with his original post on Agile methodology that he’s written a follow up, Egomania Itself (in case you’re wondering, it’s an anagram of Agile Manifesto!). He covers a lot of ground with references to some very important concepts such as “selective reinforcement” and advocates commonsense when he observes ‘Whenever you hear Agile people asking around for “success stories”, remind them politely that only looking at the positives is pseudoscience.’

Using Agile will not guarantee a project’s success. People will. But the central tenet of Agile is “People First”. Rather than talking about whether Agile works or not, we should be extracting those things that do and applying them where appropriate. Test driven development to me seems a no-brainer (despite the fact I still struggle to write code this way). Steve Yegge writes well, and I believe he makes several excellent points, but I don’t agree with every point.

“Most great software developers around the world don’t use Agile. They just work hard, they stay lightweight,…” but wait, isn’t lightweight exactly what the Agile camp say is the second most important thing you should take care of (after people)?

Steve references a superb ACMQueue article by Jef Raskin titled “When we don’t understand a process, we fall into magical thinking about results.” I believe that every developer should read that article. I have long believed that one of the personally traits that benefits programmers greatly, namely seeing patterns quickly, can also become a drawback if we make connections where none are present. Seriously, if you read just one article this week, read Jef’s.

This article on how to spot bad security/cryptography by Bruce Schneier dates back to 1999, but is still relevant today. I have several of Bruce’s books; he’s always a good read.

Rob Farley just pointed me to Crucible’s blog where he has a write up on the sessions held at SQL Code Camp in Wagga over the weekend. Sounds like it was well worth attending. Some of the material is available online from the various presenters blogs. We were lucky to have Greg Linwood here in Perth a few days earlier where he presented two SQL Server indexing talks, so I didn’t miss out entirely!

Planning the Meeting

• Whenever possible do not meet!
  – Meetings are time consuming, so decide whether a meeting is the best way to handle the issues/topics?
• Define the purpose of the meeting
  – Write down a clear goal and desired outcomes
  – Decide who should attend based on the desired outcomes
• Keep meetings short
  – Do not allow meetings to overrun
  – If there is unfinished business, schedule for another time
• Always issue a meeting notification
  – Give attendees sufficient notice to enable them to prepare any relevant material
  – State the place and time for meeting
  – State the duration of the meeting
  – Confirm attendees acceptance
• Always distribute an agenda to attendees before the meeting takes place
  Include:
  – Meeting objectives
  – List of discussion topics
  – Place highest priority items first on agenda
  – Provide attendees with any required background information
• Make sure that speakers are prepared for the meeting
  – Unprepared speakers will contribute little
• A meeting should have an owner or chairperson
  – The chairperson should open the meeting by describing the meeting objectives and expected outcome of the meeting
  – The chairperson should ensure speakers adhere to the agenda and time allocated
• Make sure that speakers are prepared for the meeting
  – Unprepared speakers will contribute little
• Make sure the facilities are prepared for the meeting
  – Arrange any audio-visual equipment or materials in advance. Arrive early to set up and make sure everything is ready to use

Running the Meeting

• Start the meeting on time
  – Do not wait for latecomers
• Start the meeting by reviewing the meeting agenda and objectives
  – Begin by introducing anyone who is not known to the other attendees
• Appoint someone reliable to take minutes
  – Ensure that the minutes are accurate
  – If it is not recorded it probably will not happen
• Stick to the agenda
  – Maintain focus, keep the discussion on track
  – Summarise conclusions or decisions as each agenda item is completed
  – Non-agenda issues/topics should be noted and discussed in the last 5 minutes of the meeting, and if unresolved, tabled for another meeting.
• Assign action items
  – Identify and assign any action items to specific people with completion dates
• Explicitly close the meeting
  – Before closing the meeting determine if the objectives were met
  – Request comment from all attendees, and enter into the minutes
  – Chairperson should provide a concise summary of the meeting’s outcome
  – Issues/topics requiring further discussion should be noted
• End the meeting on time
  – Often people will have other scheduled work to go to
• Minutes should be published and made available to all attendees

Meeting Follow up

• Communicate the meeting’s decisions to those who are affected by them
• Make sure copies of the minutes are distributed
• Remind people what they agreed to do