Wednesday, December 31, 2008
24:00:01
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
Friday, December 05, 2008
Mobile Information Architecture
Everything Mobile 2.0
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."
Wednesday, November 19, 2008
podcastarama
.NET rocks
Alt .NET
Deep Fried Bytes
Hanselminutes
Herding Code
NxtGenUG
Radio 1 Mini Mix
RunAs Radio
stackoverflow
The Moth
Startup Success
The Thirsty Developer
this WEEK in TECH
WMExperts
spot the odd two out!
Tuesday, November 18, 2008
The duality of programming languages that are easy to learn
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
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?
What's stopping you presenting?
But, most people want it/you to be good and go in with that expectation.
I'm pretty sure, psychologically, that means they'll think it better that it was/is anyway.
My Presentation at DevEvening #5
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.
Slides:
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
Windows Mobile 6.5 - I'm overly excited
http://msmobiles.com/news.php/7759.html
http://www.pcmag.com/article2/0,2817,2333601,00.asp
Friday, October 24, 2008
Picking a programming language
- 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
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
Saturday, October 04, 2008
Dev Evening 13 Nov - What to expect (+registration now open)
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.
The Adventures of Johnny Bunko : Daniel H. Pink & Rob Ten Pas
https://youtu.be/WtRNiMZsTro?si=Bk1WJV05BoYpzfTv
America’s first business book in manga and the last career guide you’ll ever need.
- There is no Plan.
- Think Strengths, not weaknesses.
- It's not about you.
- Persistence trumps talent.
- Make excellent mistakes.
- Leave an imprint.
- 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
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
EDSK ... 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.
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
Newer versions actually have fewer keywords.
disappointing prediction
;(
Friday, September 26, 2008
I'm speaking at Dev Evening
Put the date in your diary, November 13th. My first user group presentation, on Windows Mobile.
Details here: http://www.devevening.co.uk/nextEvent.aspx
EDSK: Some unofficial research
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.
Last nights Dev Evening
Another great presentation, this time from Craig Hogan on SEO.
Wednesday, September 24, 2008
Poor ASP.NET error handling now slightly better
}
catch (Exception ex)
{
DBUtils.RollbackTrans();
bdyDetail.Attributes.Add("onload", "javascript:alert('" + ex.Message.Replace("\r\n", "\\n") + "')");
}
Tuesday, September 23, 2008
Getting feedback
- Forum / get satisfaction / user voice
- Direct emails (contact us)
- Feedback option built into program
- Monitor the web (Google alerts) twitter?
- Ask for feedback on uninstall ???
- Crash reporting
Release plan
Each release should contain:
- 1 new feature
- slight visual improvements (prettier)
- fewer bugs
SMS déjà vu - v0.2
In this new version:
- Number lookup from contact list.
More details and a public version to follow...
Monday, September 22, 2008
DropBox is cool
Saturday, September 13, 2008
EDSK ... that if debugging is the process of removing bugs... ;)
"If debugging is the process of removing bugs, then programming must be the process of putting them in."
Friday, September 12, 2008
Thursday, September 11, 2008
Tuesday, September 09, 2008
Not using 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. (http://www.google.co.uk/search?q=define%3A+properly)
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
<row><td>NewShortcut2_B78C30FEFEEC4393B73638863E86FFA5.exe</td><td/><td><PATH_TO_PROGRAM FILES_FILES>\StatMon.exe</td><td/></row>
Instead of:
<row><td>NewShortcut2_B78C30FEFEEC4393B73638863E86FFA5.exe</td><td/> <td> <PATH_TO_PROGRAM FILES_FILES>\StatMon.exe</td><td>0</td></row>
The IDE was showing a different value, if none was specified, than was put into the MSI.
Friday, September 05, 2008
My First Ubiquity command
/// http://blog.stevenlevithan.com/archives/parseuri /* parseUri 1.2.1 (c) 2007 Steven LevithanMIT 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[o.q.name] = {}; uri[o.key[12]].replace(o.q.parser, function ($0, $1, $2) { if ($1) uri[o.q.name][$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["@mozilla.org/appshell/window-mediator;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 + "://" + uriParts.host + "/", 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.
Wednesday, September 03, 2008
Tuesday, September 02, 2008
Example of poor usability
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 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
Representative comment
//Can't be in a transaction here...not sure why....can't be arsed to check. Hack Hack Hack......
Wednesday, August 13, 2008
There are 2 responses to a problem. Not 3.
- Accept it and move on.
- Do something about it
Empathy.
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!
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:
System.Environment.OSVersion.Platform
If Pinvoking, DLLs will be different across platforms.
Use conditional compilation to create multiple outputs from one project.
Wednesday, July 30, 2008
... some standard design patterns
“Design patterns do not lead to good design. Good design leads to design patterns."
Friday, July 25, 2008
Intuitive is subjective
You can tell me that you think something is intuitive. Or 8 out of 10 people that used it thought it was intuitive.
Only I can say if I think something is intuitive.
Friday, July 18, 2008
Don't catch NullReferenceException
private string GetObjectValue(object param)
{
try
{
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();
}
else
{
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
Make applications understandable
"One of the jobs of the appliaction is to make it easier for you [the user] to understand how to use the application"
Installshield conditions
Not Installed
For a complete uninstall:
REMOVE~="ALL"
For any maintenance operation (repair, modify, uninstall, anything except first time install):
Installed
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;
begin
iSize = 256;
if (MsiGetProperty (ISMSI_HANDLE, "UILevel", szProperty, iSize) = ERROR_SUCCESS) then
if (StrCompare(szProperty, "2") != 0) then
MessageBox("A message.", WARNING);
endif;
endif;
end;
Wednesday, July 16, 2008
Why do I work in IT?
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
Xobni Setup
Friday, July 04, 2008
why write unit tests before fixing bugs?
Tuesday, June 24, 2008
Customer service
"In the business world it's called 'customer service', but really it's just doing Jesus' ministry."
Friday, June 20, 2008
Tuesday, June 17, 2008
Problems escalated from helpdesk
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)?
Splash screens
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
Date Entry
Saturday, June 14, 2008
Tuesday, June 03, 2008
EDSK ... you can't fully estimate from just a description of what is wanted
"You cannot write a description of software you want and then have someone develop it on a fixed schedule for a fixed price."
Tuesday, May 27, 2008
EDSK ... that complexity hides deficiencies
"There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies."
Writing for the computer screen
Gotchas:
- Less reading time
- On-screen text is tougher for the reader - to read
- The computer or reader can alter the format
- On-screen text competes with other distractions
- The screen can hide errors - things can look finished, even when they aren't
Tips:
Structure
- 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
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.
meeting expectations
"Here's what someone expects if they come to see you on an in-person sales call: that you'll be prepared, focused, enthusiastic and willing to engage honestly about the next steps. If you can't do that, don't have the meeting."
Thursday, May 22, 2008
How to make Windows better
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
Debugging is hard
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
Designing the obvious
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
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
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
Noise!
contrast should match relevance
use shadonws when stacking items
Setting up a PC - for me
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
Background:
- 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:Managed to get everything back by following the excellent instructions at:\system32\hal.dll.
Please re-install a copy of the above file.
http://forums.legitreviews.com/about6705.html
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 = "";
try
{
XmlDocument exeConfig = new XmlDocument();
exeConfig.Load(fileName);
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)
{
iterator.MoveNext();
}
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))
{
exeConfig.Load(fileName);
try
{
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)
{
exeConfig.LastChild.FirstChild.RemoveChild(oldNode);
}
}
else
{
//If file doesn't exist, create a basic structure
exeConfig.LoadXml("<?xml version=\"1.0\" encoding=\"utf-8\"?><configuration><appsettings></appsettings></configuration>");
}
try
{
//add the new setting
XmlElement newNode = exeConfig.CreateElement("add");
newNode.SetAttribute("key", setting);
newNode.SetAttribute("value", newValue);
exeConfig.LastChild.FirstChild. AppendChild(newNode);
exeConfig.Save(fileName);
result = true;
}
catch
{
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
Skateboard chair!
Wednesday, May 07, 2008
Creating links between databases on different machines
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!
CREATE FUNCTION DefaultConstraintExists(@SchemaAndTableName sysname, @Column sysname)
RETURNS varchar(1) AS
BEGIN
DECLARE @Result varchar(1);
DECLARE @columnId INT
--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
BEGIN
SELECT @columnId = COLUMNPROPERTY(OBJECT_ID(@SchemaAndTableName), @Column, 'ColumnId')
END
--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)
BEGIN
SET @Result = 'T'
END
ELSE
BEGIN
SET @Result = 'F'
END
RETURN @Result;
END
go
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
BEGIN
DECLARE @Result varchar(1);
DECLARE @default varchar(255)
SELECT @default = COLUMN_DEFAULT
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = @Schema
AND TABLE_NAME = @TableName
AND COLUMN_NAME = @Column
IF @default IS NULL
BEGIN
SET @Result = 'F'
END
ELSE
BEGIN
SET @Result = 'T'
END
RETURN @Result;
END
go
Thursday, May 01, 2008
Excel & SQL Server date epochs
On Excel 2003
1 formatted as date = 1900-01-01
On SQL Server 2000
SELECT CONVERT(CHAR(8), CAST(1 AS DATETIME), 112) = 1900-01-02
Yes, the dates are out by a day.
Yes, this was very frustrating to discover.
Friday, April 25, 2008
EDSK ... you won't get rid of all bugs, add all the features or write all the programs
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?
Prioritise!
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.
EDSK ... that design and programming are human activities
"Design and programming are human activities; forget that and all is lost."
rethinking EDSK
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 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:
Thursday, April 10, 2008
The greatest inefficiencies...
"The greatest inefficiencies come from solving problems you will never have."
-Rasmus Lerdorf
Tuesday, April 08, 2008
Mobile UI Tips
-Screen
--Size, orientation, resolution, layout
-Input
--SIP, keyboard, dedicated buttons, stylus
-User Interaction
--Standing up on a moving bus
-Understand System.Windows.Forms
--Compactness
--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?
Input:
-Keyboard
-SIP
-Dedicated Buttons
-HardwareButton
-Stylus or Finger
--Tap
--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'
Simplicity:
- 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
Refactoring:
- 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
Metaphors:
- 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'
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 ?