Wednesday, December 31, 2008


So there's a leap second. So what?
There are people getting upset about how computers will cope with the extra second.
They are concerned that over time (hundreds of years) these seconds will add up and cause issues.
Their solution. Have a leap hour, once, and then forget about leap seconds for a few thousand years (forever?).

The only issue is that a leap hour will cause work (and problems) while a leap second can be ignored in almost all cases.

Monday, December 15, 2008

sales notes

  • need for a product vs power to buy
  • do they know what the need/mean
  • There is always an alternative
  • soutions to problems, not products
  • everyone sees things differently
  • buying is emotional
  • focus on the individual
  • perceived value vs perceived price
  • sales people: attitude over experience

Thursday, December 11, 2008

Calling clever peeps in Woking

Curious about IQ?
Mensa Supervised IQ Test
Woking College
Tuesday 20th January 2009 (18:30)
For £15 you can find out your IQ.  If you score in the top 2%, you will be invited to join Mensa.
More details about IQ can also be found at the website:
To reserve a place: 
email quoting ref: WOK09
call 01902 772771 
or I have a form you can fill in and post. (email me if interested)

Let me know if you take the test & how you get on also.

Friday, December 05, 2008

Monday, November 24, 2008

EDSK ... they will benefit from a breadth of experiences

"The ideal engineer is a composite … he is not a scientist, he is not a mathematician, he is not a sociologist, or a writer; but he may use the knowledge and techniques of any or all of these disciplines in solving engineering problems."
—N. W. Dougherty

Wednesday, November 19, 2008

Tuesday, November 18, 2008

The duality of programming languages that are easy to learn

Or. The duality of easy adoption.

I'm calling out programming languages here but it applies to other things also.

If a programming language is easy to learn, lots of people will use it.
Lots of people, with no formal training or idea about best practices or the consequences of the coding decisions they make (because they don't need it - as the language is easy to use) leads to lots of bad code.
However, if code wasn't easy to write, fewer programmes would be written and we wouldn't experience the benefits of those programs.
If code was harder to write, it would (arguably) be better code (due to the need to understand what you  are doing and why) but there would be less of it.

The challenge:
1. Make sure that you know best practices and the consequences of using one technique over another.
2. Pass on that knowledge to others.

Saturday, November 15, 2008

Indicators that a company will provide poor customer service

Found this list, I made earlier in the year, prompted by spending a day talking to companies at exhibition stands at a conference.

No collateral
If they haven't got anything you can take away to remind you about a product, it shows that you aren't doing everything you can to make it easy for me, a potential customer. Why should I think that you treat actual customers any better?

No info on website homepage
So I haven't got anything tangible to remind me of, or provide details about, you or your product.  If that information isn't on your website how am I supposed to learn anything about the product, in my own time, and at my own pace.  Again, you're not making it easy for me.

Poor/no documentation/user guides/ etc.

If you haven't got anything to help users help themselves, why should I think you've got any resources that you can use to help? And if you have, why keep them to yourself?

You have to give them your information to get anything out of them (info/samples/docs/tools)
If you're more interested in getting my contact details than telling me about your product, why would I think that you're interested in anything other than I money, such as providing support if I became a customer?

No published prices
Why are you not publishing your prices? Unless it's because you desperately want my contact details rather than let me determine if your product/service/etc. is in my price range?  Or am I going to see the price and not think it's appropriate unless one of your sales people explains to me why it's not overpriced.  So, why aren't you spending your time making a great product that I can use, understand and see the benefits of?

No support SLA or escalation detailsYou haven't thought how you're going to be able to deal with the issues or questions I may have? and ensure that I get appropriate resolutions in a timely manner?

My Presentation at DevEvening #5

The 14th of November saw my first presentation at DevEvening and it went down pretty well.

I presented on the topic of "What you 'really' need to know about developing for Windows Mobile."
It was my attempt at a 30 minute crash course introduction to developing for Windows Mobile and some key things you should know when you do.

In part it was a response to the idea that if you can develop for the desktop, you can develop for Windows Mobile.

I talked about:
  • Developing for Windows Mobile is not like developing for the desktop:
    • Aim for maximum responsiveness on a mobile device. - Users have higher expectations.
    • Design for occassional connectedness. -You could lose connection at any point.
    • Do as little as possible. - You have limited resources and everything eats battery life, which is precious!
  • Developing for one device is not, necessarily, the same as developing for another:
    • Different size screens
    • More and different methods of input - Make things big enough to touch with a finger.


I used a few, very simple demos.  The code was so trivial I'm not posting it here, but if you're interested, drop me a line and I'll hook you up.

Friday, October 31, 2008

Friday, October 24, 2008

Picking a programming language

You can't pick a language to develop a project in, if you don't know:
  • anything about the languages you are picking from.
  • the pros and cons of using each of those languages.
  • what will be required of the project.
  • the libraries/resources you will be required to interface with.
  • how the languages relate to other languages that are known by the developers of the project. (If any of  the languages will be new.)

Tuesday, October 21, 2008

Getting Real with Jason Fried

Maintain momentum

don't make roadmaps / projections

Red flag words: need, can't easy, everyone, nobody

Interruption is the enemy of productivity

Give things away - educating as marketing

  • why are we doing this?
  • what problem are we solving?
  • Is this actually useful?
  • Are we adding value?
  • Will this change behaviour?
  • Is there an easier way?

Give up on hard problems

Curate your product

persona = abstraction ? - get to the real people

customer experience defines the project

cashflow will follow integrity?

keep track of what is important today

give away enough  for free to get a good feel of a product and encourage them to want to pay

Thursday, October 09, 2008

Controlling your life on-line

There's an argument that you should publish to the web (via blogging, etc.) to control what information is available about you.
However. You can't control everything.
You can just put the things you want to be there there.
You can't get rid of (some? most?) of the things you don't want to be there.
If you spend enough time and create enough content you may be able to influence what people find first.
But that's probably enough.  Unless there are some very bad things about you on the web, the fact you can control the first impression people will get of you, from the web should be enough.

Saturday, October 04, 2008

Dev Evening 13 Nov - What to expect (+registration now open)

On the 13th of November I will be giving my first user group presentation. If you know me you've probably guessed that it will be about Windows Mobile.
Here's a synopsis:
It won't be a case of me showing how to develop for the Windows Mobile platform. (Microsoft already have already created enough resources like that.)
Rather, I'll point out the key things you need to know to develop applications which will be better received by users.

Along the way I'll show some of the tools available for mobile development. (For those who may be have not done it before.) Plus, I'll also point out some key lessons for those not developing for mobile devices, but are also relevant for those developing for the desktop or the web.

If you would like to come, you can register here.
There will also be a talk by Ian Pettman on SQL Server 2008.

The Adventures of Johnny Bunko : Daniel H. Pink & Rob Ten Pas

America’s first business book in manga and the last career guide you’ll ever need. 

I highly recommend this book.  It's amazing to read and has great lessons.
  1. There is no Plan.
  2. Think Strengths, not weaknesses.
  3. It's not about you.
  4. Persistence trumps talent.
  5. Make excellent mistakes.
  6. Leave an imprint.
A few fave quotes:
  • Life: it's like an algebra problem painted by Salvador Dali. 
  • X might lead to W, and W might lead to the color Blue. And the color blue might lead to a chicken quesadilla.
  • Is this mind-numbingly repetitive? Or repetitively mind-numbing?
  • That's why intrinsic motivation is so important. Doing things not to get an external reward like money or a promotion but because you simply like doing it. The more intrinsic motivation you have, the more likely you are to persist. The more you persist, the more likely you are to succeed.

Wednesday, October 01, 2008

Monday, September 29, 2008

Mister God This is Anna : Fynn

Everybody has got a point of view, but Mister God hasn't. Mister God only has points to view.

God made man in his own image, not in shape, not in intelligence, not in eyes or ears, not in hands or feet, but in this total inwardness.

Questions were a sort of inner itch, an urge to go forward. Questions, that is real questions, had this about them, they were exciting. You never quite knew where you were going to land.

She made no effort to help me catch her, no effort towards her own safety. Being safe meant not doing these things at all, being safe meant trust in another.

The daylight schooled the senses and the night-time developed the wits, stretched the imagination, sharpened fantasy, hammered home the memory and altered the scale of values.

'love' meant the recognition of perfectibility in another.

Installshield: Change product name, but not MSI file name

Want to change the product name of an installer but not change the MSI file name?
BTW. If you change the MSI file name you may break upgrades!
Simply change the product name and then under release, specify the 'MSI Package file name' to be the old product name. (the MSI file name defaults to the product name, if not explicitly specified.)

EDSK ... being a developer is not the same as being a designer

Every developer should know that being a developer is not the same as being a designer.

Just because you can program the server side of a website doesn't mean that you are the best person to design the graphics, layout, colour scheme or logos.

Just because you are an expert at optimising data retrieval from relational databases doesn't mean that you should be designing the layout of the forms used to display that data.

Or, if you're a design whizz, it doesn't mean that you should be writing the code of an application that uses your designs.

 Why is this important?

Be honest with yourself. Know your limits.  Focus on what you are best at. Let the people who are best at different tasks work on those tasks.
I know I'm not a great designer. Just look at this site. (One day I'll get a designer to make it better.)
I'm not saying you can't be both, just that most people aren't.

What do you do once you know this?

Don't be afraid to defer a task to someone better skilled.
It'll allow you more time to focus on what you're best at.
Would you rather be the developer of some amazing software that someone else designed? Or the developer and designer of some software that is only OK?

Keywords in different version of SQL Server

(Added: MERGE)

Newer versions actually have fewer keywords.

Friday, September 26, 2008

EDSK: Some unofficial research

I sometimes feel like I never post on In reality I know I've got over 100 drafts that I've yet to finish. Why do I find finishing writing so hard?

Anyway, before I force myself to finish what I've started, I thought it was worth checking that other people agreed with my assumptions on what I thought was important.

I decided to do a bit of research and see what other people thought that other developers should know.
I only hope that the post I put on stackoverflow doesn't come more comprehensive than what I put on my site.

Wednesday, September 24, 2008

Poor ASP.NET error handling now slightly better

The highlighted part stops the javascript erroring if the erorr message contains CRLF. (Which most of the custom error messages in the system I'm working with do.)
catch (Exception ex)
    bdyDetail.Attributes.Add("onload", "javascript:alert('" + ex.Message.Replace("\r\n", "\\n")  + "')");

Tuesday, September 23, 2008

Monday, September 22, 2008

Saturday, September 13, 2008

Thursday, September 11, 2008

Tuesday, September 09, 2008

Not using a system properly?

Can a user not use a system properly?

I can see how they might not use it as it was intended or designed, but properly?

Assuming that properly means the same a correctly. (
If a system can be used in a way other than a correct one, doesn't that mean that the program is at best flawed or, at worst, contains errors?

I suspect that this phrase ("not using it properly") is typically used when they mean not as intended.  If that is the case it means that the program is unnecessarily complicated. Doesn't it?

Incorrect shortcut icon in start menu

Had an issue with an InstallShield 11 created installer.

One of the installed shortcuts was displaying a `default` exe icon, rather than the one specified.

Digging in the MSI, with Orca, showed that the shortcut incorrectly had an IconIndex of 1.

The Installshield IDE displayed an icon index of 0.

Something was obviously wrong.

The "Icon" table, in XML mode, showed the problem:
It was:
<row><td>NewShortcut2_B78C30FEFEEC4393B73638863E86FFA5.exe</td><td/><td>&lt;PATH_TO_PROGRAM FILES_FILES&gt;\StatMon.exe</td><td/></row>

Instead of:

<row><td>NewShortcut2_B78C30FEFEEC4393B73638863E86FFA5.exe</td><td/> <td> &lt;PATH_TO_PROGRAM FILES_FILES&gt;\StatMon.exe</td><td>0</td></row>

The IDE was showing a different value, if none was specified, than was put into the MSI.

Hope this helps save someone a headache in the future. ;)

Friday, September 05, 2008

My First Ubiquity command

It redirects the current tab to the root of the current domain.  - I find this helpful when there isn't a home link on a website.

 parseUri 1.2.1
 (c) 2007 Steven Levithan 
 MIT License
function parseUri (str) {
 var o   = parseUri.options,
  m   = o.parser[o.strictMode ? "strict" : "loose"].exec(str),
  uri = {},
  i   = 14;

 while (i--) uri[o.key[i]] = m[i] || "";

 uri[] = {};
 uri[o.key[12]].replace(o.q.parser, function ($0, $1, $2) {
  if ($1) uri[][$1] = $2;

 return uri;

parseUri.options = {
 strictMode: false,
 key: ["source","protocol","authority","userInfo","user","password","host","port","relative","path","directory","file","query","anchor"],
 q:   {
  name:   "queryKey",
  parser: /(?:^|&)([^&=]*)=?([^&]*)/g
 parser: {
  strict: /^(?:([^:\/?#]+):)?(?:\/\/((?:(([^:@]*):?([^:@]*))?@)?([^:\/?#]*)(?::(\d*))?))?((((?:[^?#\/]*\/)*)([^?#]*))(?:\?([^#]*))?(?:#(.*))?)/,
  loose:  /^(?:(?![^:@]+:[^:@\/]*@)([^:\/?#.]+):)?(?:\/\/)?((?:(([^:@]*):?([^:@]*))?@)?([^:\/?#]*)(?::(\d*))?)(((\/(?:[^?#](?![^?#\/]*\.[^?#\/.]+(?:[?#]|$)))*\/?)?([^?#\/]*))(?:\?([^#]*))?(?:#(.*))?)/

function cmd_domain_home() {
// heavily ripped from Utils.openUrlInBrowser

 var windowManager = Components.classes[";1"].getService(Components.interfaces.nsIWindowMediator);

  var browserWindow = windowManager.getMostRecentWindow("navigator:browser");

  var browser = browserWindow.getBrowser();

  var uriParts = parseUri(browser.mCurrentBrowser.currentURI.spec);

  browserWindow.loadURI(uriParts.protocol + "://" + + "/", null, null, false);


Defrag chaos

This is after I managed to delete unneeded files from the C drive, which had run out of space.

Lesson for the day: If someone is responsible for admin of a key (read business critical) server, don't let them go on holiday if you'll have to pick up the pieces and sort out any problems, when it hasn't been proactively managed, while that person is away.

Tuesday, September 02, 2008

Example of poor usability

It's definitely a good idea to be consistent within software.  This is especially true when indicating special behaviour or requirements.

For example. It's not a good idea to highlight a textbox in one part of a program to indicte that it is a required field and then highlight a textbox in another part of the program, in the same way, to indicate that the text box is read only.

Thursday, August 28, 2008

The duality of easy adoption

If it's easy to do something, that's good as it makes life simpler and avoids unnecessary complexity.

If it's easy to do something it normally means it's easy to do something badly.

It's better that some people do things badly because it's easy than everyone had to do something a more complicated way.

The challenge is to know how to do something 'the right way' and also to educate those who don't know.

Tuesday, August 19, 2008

Wednesday, August 13, 2008

There are 2 responses to a problem. Not 3.

If you have a problem there are 2 things you can do.
  1. Accept it and move on.
  2. Do something about it
There are no other options!

Sometimes you may have a problem and you just want to talk to someone about it.
In which case the problem you want to talk about isn't the actual problem.  The problem is really that you want someone to talk to and feel as though your opinions are worth listening to. In this case you are doing something about it.

Don't just moan and complain about a problem and do nothing about it.

Attachments are bad. Avoid!

Don't send attachments. If you can possibly avoid it.

If you put content which could be in the body of the email in an attachment you are saying:
  • you don't care about the extra time and effort involved in viewing the message.
  • your time is more important than that of the person receiveing the message.
  • you don't consider people who view emails through a browser. (Not every web based email client can display attahcments, even PDFs)
  • you don't care about the users bandwidth or the time it takes to download the message. (Not everyone has broadband)

Friday, August 08, 2008

Notes: Sharing code between compact & full framework

- shared code means less code - save time, money & effort
- Use PC tools against your code to improve device development

Don't share the UI.

Some device code can run on the desktop - not the other way round

Detect if running on device via:

If Pinvoking, DLLs will be different across platforms.

Use conditional compilation to create multiple outputs from one project.

Wednesday, July 30, 2008

Friday, July 25, 2008

Friday, July 18, 2008

Don't catch NullReferenceException

Consider the function:

private string GetObjectValue(object param)
                    return param.value.ToString();
                catch (NullReferenceException)
                    return "";

It would be much better to do this:

private string GetObjectValue(object param)
                if (param != null)
                    return param.ToString();
                    return "";

Exceptions are expensive. 
Handling the error adds an average of 16 ticks to the execution in my testing. This will add up.

Thursday, July 17, 2008

Installshield conditions

The condition for a first time install is:
Not Installed

For a complete uninstall:

For any maintenance operation (repair, modify, uninstall, anything except first time install):

The above came in handy when I ended up wrting this to not display a messagebox on a silent install:

function WarnUserIfNotSilent(hMSI)
  STRING szProperty;
  NUMBER iSize;
  iSize = 256;
  if (MsiGetProperty (ISMSI_HANDLE, "UILevel", szProperty, iSize) = ERROR_SUCCESS) then
    if (StrCompare(szProperty, "2") != 0) then
      MessageBox("A message.", WARNING);    

Wednesday, July 16, 2008

Why do I work in IT?

Because it affords me the opportunity to make things simpler and easier for people. Improving lives through technology.

It's also a relatively new industry and while this can sometimes be frustrating, it's also exciting and there's always something new to learn.

Monday, July 14, 2008

Friday, July 04, 2008

Tuesday, June 24, 2008

Friday, June 20, 2008

Tuesday, June 17, 2008

Problems escalated from helpdesk

I don't want to be awkward or unreasonable, but if a problem is being escalated from a help desk there is a certain amount of information that I would expect to have been gathered. I'm not just being picky. It saves time in the long run and means that the customer/user gets a better experience.

Information about the caller/customer/user:
  • Their name
  • The company they work for (possibly)
  • How to contact them (phone no, email, etc.)

About the issue:
  • Which program?
  • Which version?
  • What is happening?
  • How can it be recreated?
  • What were they expecting?
  • What steps need to be taken to recreate the issue?
  • What has been tried already to address the issue?
  • What has changed?
  • When did the issue start?
  • Does it occur on one, some or all machines?
  • Is it a consistent or occasional issue?
  • What impact does the issue have on the user(s)?
And probably more besides...

Splash screens

Don't have a timer on a splash screen!
They should only be used to indicate something is happeneing in the background and the application has actually started. Displaying for any longer than is absolutely necessary is a waste of the users time and shows that you think it is more important for the user to have to stare at a logo than actually use a program to do some work.
It may only be a few seconds, but it adds up.

Monday, June 16, 2008

Tuesday, June 03, 2008

Tuesday, May 27, 2008

Writing for the computer screen

Notes from article in Digital Matrix 131

  1. Less reading time
  2. On-screen text is tougher for the reader - to read
  3. The computer or reader can alter the format
  4. On-screen text competes with other distractions
  5. The screen can hide errors - things can look finished, even when they aren't

  • Use the inverted pyramid style of writing
  • Provide an overview and signposts
  • Use hyperlinks effectively
  • Use smaller chunks of text
  • Write succinctly
  • Use bullet points and lists
  • Leave plenty of white space
  • Avoid using italics
  • Choose your font carefully
  • Use a sufficiently large font
  • Use simple colour contrasts

Friday, May 23, 2008

Everyone should have business cards

Companies should provide business cards for all members of staff.
OK, so maybe not everyone, but almost all office based staff and plenty of others as well.

If you don't have them and you meet a customer and can't offer them your card, what does that say to the customer?
Does it say you are not very important in/to the company?
Does it say that customers shouldn't be able to contact you? Why would that be?

If you can't give something to a potential customer, how will they remember you?

It's not just in a sales environment that you may meet with people who you may benefit from being able to give a card too. You could meet them anywhere: pub, shops, gym, convention, playground, church, etc...

If everyone has them, there is no segregation of staff - No feelings of being 'important enough' to have them.

having a business card says you're important enough to a company, to spend a small amount of money on you, for you to be able to identify yourself as being part of that company.

They're so cheap it should be no decision at all anyway. You'll probably spend longer thinking about who should have them than the cost they are to manufacture any way.

Thursday, May 22, 2008

How to make Windows better

If another program/window couldn't take focus from the one you are working in, while you are typing.

At some (highly superficial) level, I guess all that it would take would be some kind of time out from when you last presses a key. Say a second or so. This way you wouldn't have focus stolen part way through typing a sentence, or as more often happens with me, a password.

Ironically, it happened to me twice during that last sentence.

At the moment it seems like Windows (just happened again) has no respect for what I'm doing.

(Happened again) Maybe it's me, and I try and do to many things at once. Like start lots of apps and begin using the one that loads first. This kind of thing would sure help me though.

Maybe I just need a faster computer, which can load apps quicker.

Wednesday, May 21, 2008

Designing the obvious

From SitePoint Design View #45

Robert had some wonderful insights and, perhaps most importantly, some excellent principles you can apply to your work every day. The three principles that resonated with me were:

  • Understand users — but ignore them. More precisely, watch and learn for what users do, but don't take what they say as gospel. Users often don't know (or can't explain) what they want or why they want it, so asking them directly isn't useful.
  • Build only what's absolutely necessary. Simple things are the most functionally flexible — whether it's the Google search box or a paper clip.
  • Turn beginners in intermediates immediately. In other words, find a way to give your newest, most anxious users some really easy wins and some warm feelings right from the start.

But there was one of Robert's principles that caused me to raise an eyebrow:

  • Design to support activity, not user groups.

In other words, in Robert's view, you should focus on designing for the activities that link all your users — whether that be reading sports content, managing calendar events or organizing photos.

He believes that if you start crafting your sites in response to specific user groups, you will end up designing overly complex, multi-personality applications that don't really work properly for anyone.

Sunday, May 18, 2008

EDSK ... that they must be involved in implementation

"The designer of a new kind of system must participate fully in the implementation."
"… the designer of a new system must not only be the implementor and the first large-scale user; the designer should also write the first user manual. … If I had not participated fully in all these activities, literally hundreds of improvements would never have been made, because I would never have thought of them or perceived why they were important."

Friday, May 16, 2008

Pre-testing checklist

Testing steps to perform before passing code to 'official' testing.
The intention is to prevent avoidable testing failures. It's frustrating when code fails testing and just makes more work for myself in the long run.

  • Does it do what it's supposed to - basic functionality check against spec.
  • Check code against standards.
  • Check missing, min and max length values.
  • Check for memory and resource leaks.
  • Create unit/automated test cases for all scenarios
  • Check execution against large and small data volumes
  • Check repeated execution in quick succession
  • Check for multi instance issues
  • Check in multiple target environments (DB, OS, etc.)
  • Write test plan

Obviously, some of the above can be performed by tools.

My own personal check-list. subject to change and recorded for reference. Feel free to make additional suggestions.

UI notes

Notes from listening to .NET Rocks! #338 - Mark Miller on the Science of Good UI

UI Metrics
  • No. of click or button presses required
  • Amount of brain power required

Goals of UI design should be efficiency & discover-ability - These can be mutually exclusive

Information can be in serial and parallel - adv & dis of both, based on context


contrast should match relevance

use shadonws when stacking items

Setting up a PC - for me

After coming close to having to format a machine today, I thought I should make a list of what I'd want to reinstall in that situation.

General Stuff
  • Activewords
  • Enso launcher
  • Rescue Time
  • TimeSnapper
  • GoogleDesktop
  • UnixUtils
  • Copy as Link
  • Notepad2
  • MS Office
  • Skype
  • filezilla
  • FireFox
  • IE Search Addin
  • IE spell checker addin
  • IE delicious toolbar

Developer Stuff

  • Version control client
  • IDEs
  • SDKs
  • emulator images
  • frameworks (testing, etc.)
  • xml notepad
  • Orca
  • SoapUI
  • FxCop
  • MSIDiff
  • SqlPrompt

Web Dev Stuff
  • Opera
  • Safari
  • Xenu link sleuth

And probably lots more, I've forgotten

broken hal.dll with XPSP3 - will not boot

After spending about 7 hours getting my work machine to boot, I thought I'd make a few notes, in case it help anyone else.

- Installed SP3 on Tuesday - no problems.
- An auto update installed last night (Thursday)
- This morning, wouldn't boot:
Windows could not start because the following file is missing or corrupt:
Please re-install a copy of the above file.
Managed to get everything back by following the excellent instructions at:

Really needed the restore disk and the dell resource CD. (Note to self, must check where the one for my laptop is.)

Ended up with a machine which has everything SP3, apart from hal.dll, which is SP2 version. But, everything seems to be ok.

Also had to reinstall IE7 as was on originally, but reinstall of OS rolled back to IE6. This was clever as SP3 is supposed to stop moving back to IE6.

This in turn has fixed a broken IE7, which couldn't save settings, after upgrading to IE8 beta and then downgrading.

Had issues reconnecting to domain, but solved these by disconnecting from and reconnecting to the domain.

Leaving my machine dual boot though. just in case.

Wednesday, May 14, 2008

Reading & Writing other application config files

I recently had to write a configuration tool to manage the configuration settings of a bunch of other programs. 
Here's a little snippet, which also shows using XPath to read XML.

using System.Xml.XPath;

private string ReadOtherAppConfigSetting(string fileName, string setting)
string result = "";

XmlDocument exeConfig = new XmlDocument();
XPathNavigator xNav = exeConfig.CreateNavigator();
XPathExpression dsExpr = xNav.Compile("//configuration/appsettings/add[@key='"+setting+"']");
XPathNodeIterator iterator = xNav.Select(dsExpr);

if (iterator.Count == 1)
if (iterator.CurrentPosition == 0)

result = iterator.Current.GetAttribute("value", "");
catch {} //Don't care if can't find or doesn't exist as can default to empty string

return result;

private bool WriteOtherAppConfigSetting(string fileName, string setting, string newValue)
bool result = false;

XmlDocument exeConfig = new XmlDocument();
XmlNode oldNode = null;

if (File.Exists(fileName))

oldNode = exeConfig.DocumentElement.SelectSingleNode("//configuration/appsettings/add[@key='"+setting+"']");
catch {} //old child or file may not exist

//Delete existing entry (if exists)
if (oldNode != null)
//If file doesn't exist, create a basic structure
exeConfig.LoadXml("<?xml version=\"1.0\" encoding=\"utf-8\"?><configuration><appsettings></appsettings></configuration>");

//add the new setting
XmlElement newNode = exeConfig.CreateElement("add");
newNode.SetAttribute("key", setting);
newNode.SetAttribute("value", newValue);

exeConfig.LastChild.FirstChild. AppendChild(newNode);
result = true;
throw new IOException("Unable to save configuration settings. Manually edit config file or delete it and then try resaving settings.");

return result;

Tuesday, May 13, 2008

Wednesday, May 07, 2008

Creating links between databases on different machines

Last year I worked on an interface between two systems to synchronize the data. It was specked out so that it was restricted to work with databases on the same machine or on different machines within a LAN, by specifying the machine name.

As it's been sold to a customer trying to connect two machines over the Internet by specifying an IP address. I've got to do a quick change to enable this.

Here's a quick list of situations to test in such a situation:
  • server specified by machine name
  • server specified by IP address
  • databases on the same machine
  • databases on different machines in the same domain in the same LAN
  • databases on different machines in the same domain in the same WAN
  • databases on different machines in different domains, but in the same LAN
  • databases on different machines, connected over a VPN
  • database on different machines, connected over the Internet
  • connections using network/user authentication
  • connections using specified a user name and password

Why does this matter?
Because connection strings may need to be different.

Friday, May 02, 2008

Checking for default constraints on SQL Server 2000 AND 2005 - CORRECTION!

Unfortunately there isn't a simple way to check for default constraints on a column which works on both SQL Server 2000 and 2005. To get around this problem, I created the following function:

CREATE FUNCTION DefaultConstraintExists(@SchemaAndTableName sysname, @Column sysname)
RETURNS varchar(1) AS
DECLARE @Result varchar(1);
--Try and get the columnID - only works on SQL Server 2000
SELECT @columnId = [info] FROM sysobjects
WHERE [xtype] = 'D'
AND [parent_obj] = OBJECT_ID(@SchemaAndTableName)
AND COL_NAME([parent_obj], [info]) = @Column
--If that failed, try and get it in a way that works on SQL Server 2005 (There is no way that works on both)
IF @columnId IS NULL
SELECT @columnId = COLUMNPROPERTY(OBJECT_ID(@SchemaAndTableName), @Column, 'ColumnId')
--Now see if the default constraint exists
IF EXISTS (Select * From sysobjects where xtype = 'D' and parent_obj = object_id(@SchemaAndTableName)
and col_name(parent_obj, @columnId) = @Column)
SET @Result = 'T'
SET @Result = 'F'
RETURN @Result;

The above doesn't work properly on SQL Server 2005, it returns true if there are any constraints on the table, not just the desired field.
The following is simpler AND IT WORKS!

CREATE FUNCTION FDS.DefaultExists(@Schema varchar(10), @TableName varchar(100), @Column varchar(100))
RETURNS varchar(1) AS
DECLARE @Result varchar(1);
DECLARE @default varchar(255)


IF @default IS NULL
SET @Result = 'F'
SET @Result = 'T'
RETURN @Result;

Thursday, May 01, 2008

Friday, April 25, 2008

EDSK ... you won't get rid of all bugs, add all the features or write all the programs

Every developer should know that you won't get rid of all bugs, add all the features or write all the programs you might want to.

Why is this important?

You need to set limits and prioritise.

There isn't enough time to do everything. So you need to focus on what's important and do that!

There isnt' the time to fix every bug. So fix the ones that cause the biggest problems or affect the most people (or whatever criteria you use to prioritse bugs) first.  By the time you've made those changes, circumstances may be different.

Make sure you're adding the feature which will bring the most benefit.  Not just the one that is easiest to code, or most fun.

Make sure you're creating a new program that is of use, doesn't already exist and will actually benefit others.

What do you do once you know this?
Make sure you're doing something that is worth doing.
Don't do one thing if there's another that is more important.
Understand the costs and benefits of fixing the bug, adding the feature or creating a new program, before you write the code.

rethinking EDSK

I think it's a suitably big understatement to admit that I'm not meeting my posting deadline on Every Developer Should Know.... In an attempt to address this and help me fit in a bunch of other stuff I'm trying to do, a bit of a restructure and reprioritisation is in order.
From an EDSK point of view I'm gonna start thinking more short term. I had long term plans to extend beyond tips that are generic to all developers and also include content more targeted to developers using specific technologies or targeting specific environments/platforms.
I had starting collecting references to relevant pieces on the web, but to help me focus on what I'm working on right now I'd stop. I also thought I'd post up the link so they don't go to waste.

Linux Developers should know:
Ten Commands Every Linux Developer Should Know

.NET Developers should know:
What Great .NET Developers Ought To Know
MSDN Webcast: What Every Developer Should Know About the .NET Framework, But May Have Missed Along the Way (Session 5) - Level 200
What Every Developer Should Know About the .NET Framework, but May Have Missed Along the Way
Visual Studio Add-Ins Every Developer Should Download Now
Ten Must-Have Tools Every Developer Should Download Now
.NET Framework General Reference - Design Guidelines for Class Library Developers
Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries
Database Developers should know:
... about normalisation. Not just how to do it but why.

Java Developer should know:
Ten Things Every Java Developer Should Know About Unix
Best Java book available
I've been using Java since 1995 and have owned this book since 2001 and it's the only Java text I still turn to. I recommend every Java developer, no matter what level you're at, read this book and read it again every year for the remainder of your career.

Ten Things Every Java Developer Should Know About Unix

PHP Developers should know:
10 Tips That Every PHP Newbie Should Know
10 Tips That Every PHP Developer Should Know, Part 2
make life as a PHP developer a whole lot easier

Web Developers should know:
8 Firefox Add-ons every Web Developer should know about!
Speed up your web pages with YSlow
Color Oracle takes the guesswork out of designing for color blindness by showing you in real time what people with common color vision impairments will see.
Advanced JavaScript Debugging Techniques
What Every Web Developer Should Know
... the differences between REST and SOAP.

Windows Developers should know:
... to avoid using the clipboard programmatically
Eight resources every developer should know about
... about COM
... about User Account Control (UAC)

Tuesday, April 15, 2008

Displaying data in a better way

Here's an example of improving the usability of data displayed in a grid.

Here's a part of the original grid:

The data relates to these categories:

Immediately there is a duplication of data which could be reduced. The colour and description can be combined as they are show the same thing. That would lead to a grid which looks like:

It can still be better though.

The category name is supperflous information. The colour indicates the category. This is something that the user will either know or can look up when necessary.

A roll over tooltip could also be added to display the category description for each field. This will be a more practical solution for any user who does not know what the colour means and will save them having to look it up.

Thursday, April 10, 2008

Tuesday, April 08, 2008

Mobile UI Tips

--Size, orientation, resolution, layout
--SIP, keyboard, dedicated buttons, stylus
-User Interaction
--Standing up on a moving bus
-Understand System.Windows.Forms
--Form and Control classes

Do not try to create non-full screen forms

On the screen:
-Top strip
--Don’t hide the title bar
--Use the same title in owned forms
-Bottom strip
--Don’t use a toolbar control
--Don’t use more than two menus
--Don’t hide the bottom strip
-Main Area
--Place tappable controls near the bottom
--TextBoxes or anything requiring the SIP, near the top

Screen aware:

  • Size
  • Orientation
  • Resolution
  • Touch enabled?

-Dedicated Buttons
-Stylus or Finger
--Tap and Hold (Avoid)

Aim for single handed operation (ideally stylus free: Designing Pocket PC Application for Stylus-Free Usage (one-handed))

Object Thinking : David West

Book based on assumptions:

  • Agility/XP essential for profession/industry to improve
  • XP offers way to create better developers
  • Can't do XP without understanding object thinking
  • Won't appreciate the benefits of XP if don't fully understand 'object thinking'


  • OT based on problem domain, not potential program
  • OT leads to smallest number of things (classes) possible
  • Objects doing the least amount of work, in the most direct and simplest way
  • Focus on coordination of autonomous objects - not mgmt of unruly modules and passive data structures

Simple design:

  • Fewest no. of classes
  • Fewest number of methods per class
  • Simplest coding of methods
  • Avoidance of control, centralization & mgmt classes
  • Simple scripts to simulate simple stories


  • Allow 'lazy' objects to give work to other objects

The true differences between programming languages are those that reflect philosophical ideals and values

If you think about design using a language - your design will be enhanced or severely restricted by that language

Object culture:

  • Collaboration rather than mgmt
  • Coordination and cooperation, rather than control
  • Rapid prototyping instead of structured development

Prerequisites to OT:

  • Everything is an object
  • Simulation of problem drives object discovery and definition
  • Objects must be composable
  • Distributed coordination and communication must replace hierarchical centralized control as an organizational paradigm

Programs may be thought of as data and functions - but the real world isn't

Assuming data and functions:

  • Programs are more complicated than need be
  • Complex code is difficult to understand and test
  • Complex code is brittle and difficult to modify when requirements change
  • Resultant code lacks composability - not reusable outside original context

Object principals - software principles:

  • Solve complex problems by solving a series of intermediate, simpler problems
  • Appreciate human cognitive limitations
  • Correctness is unaffected by movement between equivalent contexts
  • Correctness is unaffected by replacement with equivalent components
  • Modular design
  • Portable design
  • Provides compositional flexibility
  • Appropriate use of abstractions
  • Limited set of conceptual forms

Brooks' 4 essential difficulties of software development

  • Complexity
  • Conformity (to the world, rather than the other way round)
  • Changeability (to the world, which changes frequently)
  • Invisibility


  • Help discovery
  • Help make design decisions
  • Provide handy ways to remember principles of object thinking
  • Help avoid non object thinking

It is convenient to build something large from smaller (but not the smallest possible) components

The complexity of object-oriented programs is in the scripting, not the objects themselves

Hierarchical and centralized control is anathema in the object paradigm.

Ants, not autocrats: - do your thing and react to messages from those around you.

Behaviour is the abstraction to use to differentiate between objects and is the criteria to base taxonomy on.

Creating taxonomies based on internal structure leads to numerous problems

The programming language used does not mean that doing object programming

Object vocabulary is first and foremost a technique to help developers avoid the mistake of thinking about solutions using old mental habits

Essential terms:

  • Object
  • Responsibility (task)
  • Message
  • Protocol

Computations must be by an object on itself: (e.g. number adds another to itself. rather than an object and two other number objects together)

  • Helps enforce simplicity

Multiple inheritance:

  • Is unnecessary
  • There are alternative
  • Adds needless complication

Methods and model must:

  • Support natural decomposition
  • Recognize 2 complementary processes: domain modeling; application assembly
  • Aid discovery and evaluation
  • Enable measuring progress and 'goodness'

Formal methods do have their value

Blending methods and approaches is hard

Using ideas from both approaches is equally difficult

Need criteria to evaluate:

  • Self
  • Progress
  • Products

Need to understand the domain - how computers work is not part of the domain

Starting a journey with one step in the wrong direction can have an enormous impact on the end result

Mistakes at the beginning of a process are more costly:

  • Have less knowledge, so more likely to make mistakes
  • More tempted to think about what do know (the computer) rather than the domain

Never: think about what the code will look like and then create objects to support that code.

Set aside your own culture when attempting to understand users and user domains

To understand users: (their domain and their tasks)

  • Go and spend time with them
  • Observe them
  • Talk to them

Can't define everything up front - do one thing (story) at a time

Object definition:

  • Most critical aspect of discovery
  • Define in terms of actual or intended use
  • Define within domain, not just application space
  • Not the same as object specification
  • Specification will involve making design decisions

OT suggests you should generalize responsibilities so that they can be used in any context

Let objects assume responsibility for tasks that are wholly or completely delegated to other objects in cases in which responsibility reflects natural communication patterns in the domain.

Delegate responsibilities to get a better distribution and increase reusability.

Delegation can lead to the temptation of management. - If you delegate, delegate:

  • Don't try and control
  • Don't guess what the result will be
  • Don't do own error checking or evaluation

Responsibilities should be distributed among the community of objects in a balanced manner

Avoid responsibilities that are characteristic specific, that focus on providing a potential user with the value of a single characteristic of the object.

Beware the dangers of GUI-in design!

The two kinds of relationship of interest between objects:

  • is a kind of
  • collaborates with

Single line of descent based only on the behavior of the object

Collaborations are almost always hard coded - due to complexity of relationship between objects

OT: data is information or knowledge that objects need to complete a task

Traditional data modeling: all the data that a system must remember about objects

Model: - comprises objects engaged in the objectives of the application

View: - hierarchically organized collection of objects

Coordinator: - tasks involved in sending messages to other objects, and notifying subscribed objects of a state change

Objects are not and should not be aware of their clients, even when their clients are not other software objects

Scripts as first class objects:

  • Ordered collection of messages

Events as cues to object interaction

Constraints and rules are objects themselves

Rules should not be complex (coz they're objects)

Objects will often have a collection of 'self evaluating rules'


  • Evaluate
  • Error handling/recovery

XP maturity levels:

  • Out of the box
  • Adaptation
  • Transcendence

Objects are not something you do - objects are something you think

There are circumstances in which it is difficult, if not impossible to apply object thinking

  • e.g. RDBMS, GUI

Database philosophy is almost totally inconsistent with the philosophy behind object thinking

Need to remember the functional advantage of databases as well as their persistence services

XP created users who don’t want large monolithic software but a collection of small, targeted applications which do specific tasks.

  • In contrast to 80/20 law

Object cube:

Side 1: Responsibilities

Side 2: Description and stereotype

Side 4: Knowledge required

Side 5: Message protocol (methods)

Side 3: Contracts (public or private methods)

Side 6: Events

objectionary ?