Are you storing passwords in any of your applications? If you are, reconsider. Passwords are very sensitive, because people have so many accounts that they are forced to reuse passwords. Read about what (eventually) will happen: http://www.codinghorror.com/blog/archives/001263.html

Wrox has posted a video of a presentation by Scott Hanselman at a .NET user group. Scott is very passionate about productivity. How many times a day do you type 'otepad'? Watch the video and learn how you don't really have to.

As a developer you spend a lot of time typing documents and code. If you just spend a small amount of time, you'll be able to get a significant improvement in the speed with which you can type. Check out http://www.egbertbeuker.nl for online typing lessons.

Very little effort to protect your users: http://blogs.tamtam.nl/paulb/TurningOffAutoCompleteForTextBoxesInIEAndFireFox.aspx

 

With the arrival of my new laptop I have decided to give running (and developing) as a non-admin a try. This is one of those things that everybody agrees on as being important, but very few people actually do.

I've discovered that there are quite a lot of things that you would do on a daily basis require elevated privileges. These include: updating virus-definitions, changing the type of paper in the printer settings and renewing the IP Address. There are situations where selections that I've made didn't stick. One of the most annoying cases was the MS AntiSpyware tool: every time I logged on I was required redo all of the selections I had made. Although this particular product is still in beta, it does show that more people need to start running their systems as non-admin. (Or - at the very least - start testing their applications as one)

Most of the times it is very easy to circumvent the lack of privileges by using “runas”. The biggest problem I encountered was trying debug an ASP.NET-application; because the process that you are trying to debug runs under a different account, access is denied. The way I ended up solving the problem, was configuring the worker process to run under my own user account. This isn't a really elegant solution, but at least I can now debug again. I read somewhere that with Whidbey this would be solved by not using IIS to debug applications. VS would start its own webserver when trying to debug an application. One more reason to look forward to VS2005.

How to remove the sensitive nature of production-data from your database.

I just spent some time to find a list that contained the Sid-strings for the well known Sids (WKS) that the Microsoft.Win32.Security-dll provides via the Sids-class. Because the WKS are implemented as static methods, it wasn't as easy to generate a list. To prevent me (or anybody else) spending more time on finding the list: 

AccountOps	S-1-5-32-548
Admins	S-1-5-32-544
AnonymousLogon	S-1-5-7
AuthenticatedUser	S-1-5-11
BackupOps	S-1-5-32-551
Batch	S-1-5-3
CreatorGroup	S-1-3-1
CreatorGroupServer	S-1-3-3
CreatorOwner	S-1-3-0
CreatorOwnerServer	S-1-3-2
Dialup	S-1-5-1
Guests	S-1-5-32-546
Interactive	S-1-5-4
Local	S-1-2-0
Network	S-1-5-2
Null	S-1-0-0
PowerUsers	S-1-5-32-547
PreW2KAccess	S-1-5-32-554
PrintOps	S-1-5-32-550
Proxy	S-1-5-8
RasServers	S-1-5-32-553
Replicator	S-1-5-32-552
RestrictedCode	S-1-5-12
Self	S-1-5-10
ServerLogon	S-1-5-9
Service	S-1-5-6
System	S-1-5-18
SystemOps	S-1-5-32-549
TerminalServer	S-1-5-13
Users	S-1-5-32-545
World	S-1-1-0

 

Last Friday I had a short discussion with a colleague on what the 'best' way was to get data out of the DataReader