Been trying to get the .NET 2005 GridView to "remember" the sorting and paging settings, and apply them next time a visitor returns to the site. The LoadControlState and SaveControlState methods are protected, so I derived a class from GridView, and added public methods to expose them. These are called on Page_Load and from a button event handler.

I used a BinaryFormatter to serialize and deserialize the control state Object to a file, which works quite well. Clearly this wouldn't be appropriate for real life, as it should go in the database, but it does prove the concept, which is all I need at the moment.

I've booked the restaurant for 8pm, and I've got some definites already. Here's a link to the map. Let me know if you'll be there.

*Uckfield is in East Sussex, England. Not far from Brighton. A little further from London.

I've spent a couple of hours trying to find out about <browsercaps> in Whidbey, and there isn't a lot of info. Sherkles the Coding Clown (yes, really) has given me the best starting point so far:

BrowserCaps in ASP.NET 2.0: look in "\windows\microsoft.net\framework\v2.0.40607\CONFIG\Browsers"

I've just tried it again at work with XP SP2, and it is enabled by default on my machine.

The difference between this and security holes, such as buffer overruns, is that this is actually a feature. Someone has taken the time to write the clipboardData.getData function into JavaScript, and the IE team spent time implementing it. I can only conclude that this was added when the browser war was full on, and any new feature that could be added was seen as an advantage. Security wasn't such a big deal to Microsoft back then.

I'd love to know when this was introduced, and what conversations were going round at the time. If anyone knows of anyone who knows, or knows of anyone who may know anyone who knows, please let me know.

Having done a quick Google search, it seems that the implications of this feature have already been noticed, and even promoted.

Spent some time today trying to get NUnit testing working with Whidbey. I found out that in the tag in the config file needs changing. I used notepad for changing the XML, which doesn't have syntax colouring. Had it had it, I would have noticed that the whole section was commented out. It took me an hour to spot it.

I installed TestDriven.NET, as TestRunner didn't appear to work with NUnit 2.2.2.0. I'm not sure whether TestDriven.NET is a website or a product, or both. Hopefully I haven't just installed a website.

The new lodger wanted to get her laptop on the internet, and she has an existing dial-up account, but I thought this wouldn't work. On my PC, I setup a Tiscali pay-as-you-go account, and copied the settings onto the laptop. The only complication was that both the lodger and her Windows XP are Greek.

I learned two new Greek works (but I can't type them on my PC) - "nay" means "yes" and "ochi" means "no". I can sort of recognise Cancel as well.

I had to go through the motions on my PC, and copy the button clicks on the laptop. It took ages. Very interesting though. I was surprised at just how many things were in English on her desktop.

There's trouble brewing: there were two different virus warnings on the laptop, and her subscription is months out of date. When disconnecting, I noticed that over 1MB had been sent, and 2MB had been received. All we did is visit msn.co.uk to see if we could browse. I suspect some evilness is going on.

I suspect that I will have some more encounters with Windows XP Greek. A whole new level of challenge to everyday maintenance tasks.

At what point does someone cross the line from being computer-illiterate to computer-literate? I don't think it's about qualifications, or training courses or having used n different programs. It's more to do with attitude. People who are computer illiterate admit as much. They write down a list of instructions which they follow every time they (for example) write an email. If they realise they've missed out a step, they won't know what to do. They won't attempt anything new without being shown.

Computer literate people may not be able to do much, but they get better. They may have an idea that they want to do something, and try things out on the menus and toolbars until they get close enough. They start to understand concepts, and apply them to different programs.

The problem when writing software is catering for both groups.

4th Feb, in Uckfield, East Sussex, England. Let me know if you want to come - simon at harriyott dot com.

I've been a software developer for nine years and four companies. I'm starting to look back at my career to see what I've learnt. I've learnt from making mistakes, doing something well, reading, listening to what people say, and watching what people do.

I'm going to list them for my own benefit, firstly to remember what they are, secondly to make me think about them some more, and thirdly because the process of listing them may unearth more. They could all be preceded "Note to self: ". Each item could be expanded upon, and I might well do so later. Some of them I have got the hang of, some I really need to work on. If you've ever worked with me, you can probably spot which is which.

They are in three categories, one for software (1-10), one for work in general (11-20), and one for people (21-30).

1. Don't over-engineer a solution.
2. There's a whole game of Chinese whispers between what the customer asks for, and what is delivered.
3. Don't forget to check files into source control.
4. Over-estimate how long something will take.
5. Code simply, so the next person can read it.
6. Comment what the code is for, not how it does it.
7. Frequently check with the customer that what you are writing is what they think they want.
8. Learn how to use Google for samples and bug fixes.
9. Whilst writing software, you need to picture the people who will use it.
10. Keep up to date with technology.
11. You can only work with what you have, so make the best of it.
    
12. Being genuinely enthusiastic is good.
13. Find out exactly what criteria you will be assessed against, and make sure you do those well.
14. Training courses aren't all they're cracked up to be.
15. See what mistakes other people make, and learn from them.
    
16. Each company I have worked for has been better than the previous one.
17. Don't write an email while you are angry. Don't even make any decisions while you are angry. Calm down first. Leave it a day or two.
18. Don't say "yes" to everything.
    
19. You will make more difference getting better at things you are rubbish at than the things you are quite good at.
    
20. Keep learning.
21. At least one of your colleagues will think they are better than you. Hopefully they won't tell your other colleagues.
22. You spend loads of time with your colleagues. Much more than with your family and friends.
23. People keep cropping up when you think you won't see them again.
    
24. Be helpful.
25. Be careful with first impressions. They are often wrong, so don't trust yours. Other people may judge you on their first impression of you.
26. Don't be smug, arrogant or lead people to believe you know more than you do.
27. Being a gossip is bad.
28. Don't belittle yourself or your colleagues in front of your customer or boss.
29. If you're not very good at one aspect of your job, find someone who is good at it, and ask them to help you.
30. Everyone has good points and bad points. You will be happier if you focus on people's good points.

n.b. I have learned some other things as well, but I'm not going to put them in the list.

The worst thing about being really good at something is being really good at it. Consider a DEPSCART expert. Years ago, when DEPSCART (ok, I made that one up) was common, lots of people could do it to a basic level. Over time, some people became much better at DEPSCART, and others switched to the next big thing, for example, AutoMiracle for Windows (AM4W - also fictional). Expert DEPSCART programmers can now charge extra, and AM4W programmers are competing against cheap graduates with the same experience.

Recently, more people switch to the next big thing, e.g. Mantra, and those still with DEPSCART are getting really quite good at DEPSCART; expert even. Really expensive. The DEPSCART-to-AM4W people switch to Mantra, competing with the graduates.

The DEPSCART-to-AM4W-to-Mantra people are good at all three, but not expert. They may be better programmers, as they have more ways of looking at things, but they are not as expert as someone staying with DEPSCART. DEPSCART consultants are rich and in charge.

The problem is, companies are not using DEPSCART so much anymore. There are no big exciting projects being started in DEPSCART, so work is maintenance based. Projects to rewrite legacy DEPSCART programs in Mantra are being created. Suddenly DEPSCART isn't needed so much, and the experts have to travel further to get less interesting, less lucrative work. Not having done AM4W, the jump to Mantra seems enormous.

The sell-outs who hop on each bandwagon are suddenly quite useful. "Yes, I used to do DEPSCART a few years ago, and I'm pretty handy at Mantra". Hired.

Clearly I'm generalising; there must be DEPSCART programmers who have got stuck in a rut, and don't get a whole lot better. Also, a DEPSCART expert is going to be bright (it's a tough language to master), so learning a new one won't be too taxing.

As with most things, the extremes are undesirable, and the compromise is usually best. The key here is to keep up-to-date, but not flit about too much, or get stuck with one thing. It's about being the most useful, not the expert.

Seems that Waterstones made a tactical error in firing an employee for blogging. The general feeling seems to be that at best, the dismissal was unnecessary, and at worst, "they'll get no more of my business". I heard about it on Radio 1 news (BBC). Being the first company to fire a British employee for blogging is bound to get serious bad press; much more than saying you don't like your boss.

I'm really not sure I like what I've just found. I noticed in the Visual Studio help that there is a "copy code" link, which eventually calls:

window.clipboardData.setData("Text", "some text for the clipboard");

That's fine from a clearly labelled link, but it also works from a <script> block, and in the IE address bar. I'm almost tempted to add it to this page, so you can try it, but I wouldn't want to replace whatever's in your clipboard without warning. There's plenty of people that would though.

Guess what the getData function does? It grabs what is already in the clipboard. Again, this can be run in a script block, which will happen when the page loads. This can then easily be posted to a server. I wonder how many times that has happened to me. You can see it in action by copying some text, and clicking the link. I won't post it anywhere.

Show clipboard contents

Scary huh?

[Update: more details on my later post]

Yesterday I was struggling to write an automatic JavaScript generation thing in .NET. I spent most of the afternoon looking at it, and got it nearly working, but had to go home before it was finished. This morning, it took less than five minutes to get it fully sorted out.

This sort of thing happens to me almost monthly. I am good at "switching off" when I leave work, so I don't think about work much when I'm at home. When I have lingering problem, I find that if I start to think about it when I go to bed, when I get to work, my brain has done a whole load of OnIdle() processing while I was asleep and I already know how to solve it.

I've been reading Steve Krug's excellent book, "Don't Make Me Think". This explains that people looking for something on a website click on the first link that looks like it might be what they want. They don't read everything on the page, and consider carefully which of the similar items it might be.

I realised that I write code in a similar way. I don't initially spend time reading about (let's use a really simple C# example) all the ways of concatenating strings; how they work, what the performance is like, how much code is required, best practice etc. I would start to read about strings, and may first come across the + operator, which sticks one string onto another. I'd try it out, and if it works, I would use it and move on to the next task, which might be adding some integers together.

In this example, I would completely miss the StringBuilder class, and I wouldn't know if it is faster, when it is more appropriate than +, or even how it works.

Refactoring (at least, using the refactoring menu in Whidbey) only provides "move stuff about" options, not "do this a better way" options, so if the project allowed time for extensive refactoring, I'd still miss the StringBuilder class.

How do I get round this? By general reading as well as specific reading. I currently have 102 feeds in my news aggregator, mostly .NET and development related. I read paper books about .NET and general programming issues, and articles on other websites. If I didn't, I wouldn't have heard of the StringBuilder class. As I have read it somewhere, when I come to tackle concatenation, I have some ideas before I even start.

My "new" boss started back today after being on maternity leave. She had already left by the time I joined, so today is the first day I've worked with her. I didn't even meet her at the interviews. So far, she seems smart, friendly and willing to listen.

It was a gamble taking a job when I hadn't met the boss, but I generally get on with most people. She had chatted with her boss, who interviewed me, read my personality profile, and thought I would fit the team. As she said, people can learn technology, but they can't learn personality.

I've just read the phrase "comparatively unique", in the first paragraph of the introduction of a reeaally expensive confidential market research report. I wonder what "comparatively unique" means.

I've been using a third-party control, and I've just found the following comment:

// This is a hacky fix for the case where ...
// must do this properly later

At least I didn't pay for it.