Mitch Wheat - Treat the cause, not the symptoms!

A colleague asked me yesterday about SQL Express 2005 and what restrictions it has. I mentioned in a previous post that SQL Express does not limit user connections.

SQL Express 2005 is Microsoft’s SQL Server 2005 lightweight edition, which is free to use and redistribute. This new edition is the upgrade to Microsoft's SQL Server 2000 Desktop Edition MSDE). SQL Express is limited to a single CPU, 1GB RAM, and a maximum database size of 4GB. There is NO workload governor which means SQL will not limit or reduce the speed of queries. SQL Server Express can be installed on multiple CPU machines with more than 1GB of RAM, but the database engine will limit itself to a single processor and only utilise 1GB. Apart from these restrictions, the SQL Server Express database engine is the same one found in the other SQL Server products.

SQL Express does not include Analysis Services, Integration Services, Reporting Services, and Notification Services. Views, stored procedures, triggers, cursors, CLR, XML, and T-SQL all work the same way as in the full SQL Server versions.

Download SQL Server 2005 Express Edition Service Pack 1 from this link. Visit the SQL Express home page for links to useful resources and information on registering for redistribution.

One thing you should be aware of, if you plan to build an application and redistribute a database with it, you should be using SQL Server Express as Windows Vista will not support MSDE.

Randall Hyde published a paper on The Fallacy of Premature Optimisation back in July 2006, which discusses the mindset required to create efficient code, and how it has been misconstrued:

Observation #1: "Premature optimization is the root of all evil" has become "Optimization is the root of all evil." Therefore, optimization should be avoided.

This is similar to an often misquoted biblical quote, “The love of money is the root of all evil” (which is misquoted as “Money is the root of all evil”).

What Hoare and Knuth are really saying is that software engineers should worry about other issues (such as good algorithm design and good implementations of those algorithms) before they worry about micro-optimizations such as how many CPU cycles a particular statement consumes.

This is something I try to explain to all junior programmers, and why it is important to have at least a basic understanding of algorithm order complexity, e.g. O(N ²) versus O(NlogN)

I saw this article via Rico Marini’s blog.

Did you know there is Microsoft site containing Regional Director Code Samples? I'm assuming this is a public site, only I'd just logged in with my Passport via the partner site.

Microsoft Regional Directors specialize in creating crafty shortcuts and ingenious innovations for developing with the .NET Framework. Check out some recent tricks of the trade here-and contact an RD if you want to learn more.

Rockford Lhotka (the creator of CSLA, and author of Expert Business Objects) has posted another follow-up to Steve Yegge’s post from yesterday:

See that’s the thing. Formalize a set of practices into a Methodology and the practices lose their meaning. Each practice in Agile really is good – in a specific place and for a specific purpose. But when wrapped in a Methodology they become “good at all times and in all places” – at least to most practitioners.

Rocky puts it into words so much better than I could.

Au Contraire! Piglet Squid!

Rick Strahl has posted a great, must-read article on Compilation and Deployment in ASP.NET 2.0:

Compilation and deployment in ASP.NET 2.0 has brought some of the biggest changes to the ASP.NET development model. As developers we use page compilation all day long and deployment is something we all have to worry about sooner or later. A lot has changed in both areas and they can affect how you build and deploy your applications so understanding how the model works is crucial.

It's an in-depth look at the pros and cons of out-the-box stock projects and the newer Web Application Projects (available as a free download for Visual Studio 2005, but does not work with Visual Web Developer).

I seem to be spending quite a lot of time at Jeff Atwood’s blog of late; this post is one I like to revisit from time to time, The Pragmatic Programmers Checklist.

As a counterweight to the change diary post here’s one I saw via Joel Spolsky’s blog, Steve Yegge’s post on agile: Good Agile, Bad Agile, which among other things gives an idea of the work environment at Google. It’s an interesting read, whether you agree with it or not.

Once in a while you come across something that is really excellent; an article that strikes a chord and captures your imagination. James Shore’s Change Diary is a candid and well-balanced account of how he tried to bring agile methodologies and processes to a company where he had been taken on as a developer. It is well written, in an engaging, flash-back style. You can empathise with James’s ups and downs as he describes his 19 week journey. Thanks to Jeff Atwood for the heads up.

The really scary thing is not that the company he describes had problems (most do), but they are by no means the worst out there. I’ve worked in a ‘service based’ environment not dissimilar to the one described, and I’ve actually had senior management tell me “What’s the point of doing it faster? We bill the client for all the time we expend.” Go figure...

Being a great fan of all things SQL Server, I had hoped to remain an Oracle virgin but alas it was not to be! I couldn’t begin to call myself an Oracle expert but here are a few simple tips I picked up.

When writing stored procedures in Oracle 10g, you can reduce possible maintenance time by declaring the type of stored procedure parameters like so:

‘COLUMN_NAME’ IN ‘COLUMN_NAME’.%type

rather than explicitly declaring a data type.

Oracle have released the Oracle Developer Tools for Visual Studio .NET which includes a schema browser, integrated context sensitive help and a PL/SQL debugger integrated into Visual Studio 2005.

There is a basic article describing how to Build a .NET Application on the Oracle Database, although you would almost certainly be better off using a code generation tool such as MyGeneration or the CodeSmith NetTiers 2 templates (with the CodeSmith Oracle provider) to generate your Data Access Layer (or any one of the others available).

As an aside, this looks interesting but I haven’t actually used it: Convert SQL Stored Procedures to ORACLE.

Here is a question for any Oracle experts out there. I spent some time looking through 2 well known and respected Oracle books, and googling to see whether the 30 character identifier limit in Oracle is configurable, as I reasoned that it surely must be, right. Right? Well, I could not find a way. A 30 character limit is a real pain when you are using code generation. Is it possible to increase this limit?

I’ve recently been building quite a few VPC images for betas, testing, sandboxing etc and have made use of the techniques that Jeff Atwood posted about and I linked to in a previous post. It’s staggering how small you can make them, and how much faster they load. Jeff’s article is essential reading if you are making use or intending to make use of VPC’s. I managed to get a full Windows XP Sevice Pack 2 image down to 584MB !

I was doing a spot of late night browsing (in fact I was in the middle of reading a very interesting article on Agile development experiences when the server went down!), and came across a totally unconnected MSDN article from July 2001, which is a beauty. Creating Windows XP Icons describes in step-by-step detail how to create icons just like the guys at Microsoft. It describes the palette, perspective, common icons for toolbars, adding drop shadows, creating correct transparency maps etc.

If you are a designer or a programmer in a designer's shoes, this is a must read. The article has been rated over 7500 times and it has an average rating of 8 out of 9 (who's the person that seems to visit every MSDN article and give a rating of 1 ?!?)

If you use the Visual Studio IDE frequently there are a number of shortcuts that can make you more productive. None of these tips are new, but there might be one or two shortcuts you were not aware of. The majority of these tips come directly from the Tech-Ed 2005 and 2006 presentations given by Anson Horton and Karen Liu respectively. I’ve condensed the gist of these 1 hour sessions into what you see here. [Note: these are the C# key bindings; other languages may differ]. One thing certainly worth remembering is that adding the Shift key to most key combinations causes the opposite sense of whatever the action is.

These useful shortcuts come under the following headings:

• Understanding code
• Navigating code
• Modifying code
• Debugging code

Understanding Code: Exploring the .NET framework’s Class Relationships

The dynamic class diagram is a great way of exploring class relationships in ­­the .NET framework. Now I’m sure most people will already be using the class diagram for their own class hierarchies (Add a class diagram, go to class view [Ctrl-W, Ctrl-C], and drag a class to the diagram), but did you know that you can also use a class diagram as a great way of getting familiar with the .NET framework in VS2005? In class view, open the “Project References” tree and drag a namespace to the class diagram (e.g. System.IO). Also, don’t forget you can “Show Derived classes” by right-clicking on a class.


Navigating Code

You are probably aware of the right-click ‘Go to Definition” navigation (with your cursor placed in a symbol). It is also bound to F12. What you might not be aware of is its counterpart, Shift-F12 which shows all references to the symbol defined at the current cursor location.

F12 - Go to symbol definition
Shift-F12 - Show all references to a symbol

The F8 key is a great shortcut key to remember. It can cycle through all references found with F12, and in addition it can cycle through any ‘List’ output window, such as the task list, error list, etc.

F8 - Cycle through list of items in the currently active output window
Shift-F8 - Same as F8 but in the opposite direction

The next two key ‘chords’ are very useful when you are dealing with unfamiliar code, as they provide a high level view of a class’s methods:

Ctrl-M, Ctrl-O - Collapses all methods to outline view
Ctrl-M, Ctrl-M - Collapses/expands the method the cursor is currently in.

Most people are aware of the “IE style navigation” using Ctrl-minus and Ctrl-Shift-minus to move backwards and forwards through visited code:

Ctrl-‘-‘ - Move backwards to previous cursor location
Ctrl-Shift-‘-‘ - Move forwards to last cursor location

But the following two are less well known (and in many instances, more useful). If you are navigating a sequence of method calls, and you move around in the surrounding code, the IE style navigation will cycle through every location the cursor was placed. The following two commands move up and down the “Definition Navigation Stack”, so just those methods that you delved into using F12:

Ctrl-Shift-8 - Move up the definition navigation stack (stack pop)
Ctrl-Shift-7 - Move down the definition navigation stack (stack push)

Another less known shortcut is Ctrl-I which activates incremental search. Open a source file, hit Ctrl-I and start typing the first few letters of your search text. Visual Studio will go to the first occurrence and continuing searching as you enter more characters. Hit Ctrl-I to go to the next occurrence (and of course, Ctrl-Shift-I to go to the previous). Pressing Escape will turn off incremental search.

Ctrl-Shift-I - Incremental search
Ctrl-Shift-F - Find in all files (more useful than Ctrl-F)
Ctrl-H - Replace

Another tip involves finding files. You can download a free add-in called VS File Finder from the following link: http://www.zero-one-zero.com/vs. It’s easy to use and good for navigating in large solutions. File Finder shows up as a new window after you install it from the .msi file. I docked mine with the output and list panels at the bottom of the IDE window. Any text you enter in the textbox will filter the list of files displayed by partial file name matches. [From Visual Studio Hacks, by James Avery.]

For some reason, I always seem to forget these two shortcuts:

F7 - Switch to code view
Shift-F7 - Switch to design view


Modifying Code

Ctrl-K, Ctrl-C - Comment out currently selected code
Ctrl-K, Ctrl-U - Uncomment currently selected code
Ctrl-K, Ctrl-F - Auto format selected code

FxCop is a Static Analysis tool that can not only help you come to terms with an unfamiliar code base (see previous post) but also to improve existing code. FxCop runs over the IL generated from your source code and performs a set of rule based comparisons on it. There are 2 rule sets that can help with refactoring: naming and maintainability. One of the rules that can generate warnings relates to something called ‘cyclomatic complexity’. Cyclomatic complexity is just the number of branches in a method. The higher the value, the greater the likelihood that a method could be reduced by having sections of code extracted into new methods (refactored).

Visual Studio 2005 contains a number of refactoring commands to help you reorganise code:

Ctrl-R, Ctrl-M - Extract method
Ctrl-R, Ctrl-E - Encapsulate field
Ctrl-R, Ctrl-I - Extract Interface
F2 - Rename

[Ctrl-R is the first ‘note’ in most refactoring key combinations, and there are other refactoring commands in addition to those I've listed above]


Debugging Code

These are essential debugging shortcuts:

F10 – Step over
Ctrl-F10 – Run to cursor
F11 – Step into
Shift-F11 – Step out
F9 – Toggle a breakpoint
F5 – Run with debugging
Shift-F5 – Stop debugging
Control-F5 – Run without debugging

Attributes can make your debugging more effective by declaratively altering the behaviour of the debugger:

[DebuggerStepThrough()] is used to decorate a method or property to prevent the debugger stepping into it whilst debugging.

[DebuggerDisplay(“{propertyname}”)] allows you to define the value which is displayed by default in debugger visualisers.

[DebuggerBrowsable(DebuggerBrowsableState.Never)] can be used to prevent the display of data, such as private fields, in visualisers.

In order to use the debugger attributes you will need to import the System.Diagnostics namespace. You can find out more about debugger attributes here: Enhancing Debugging with the Debugger Display Attributes.

One final debugging tip: you can hold down control key when drilling into a visualiser to make it transparent while you inspect the code beneath it.

If you’ve been a VB6 programmer at some point in your career, it’s pretty good odds that you would have heard of Dan Appleman (Visual Basic Programmer's Guide to the Win32 API, Desaware). But did you know about one of his other interests? It’s probably one of yours also…His site thinkingaboutmoney is an excellent place to visit to pick up some of Dan’s common-sense advice.

Dan has recently published a 25 page e-book “The Graduating Geek’s Guide to High Finance” aimed primarily at recent graduates but it also contains advice for the rest of us. It costs US$3.99 and is well worth those few dollars.

It’s not a get rich quick scheme, but talks about the financial practicalities you should consider, even as soon as graduating and taking your first job. Some of the information is US specific (such as the super fund information), but the majority is applicable in any country. Dan discusses the importance of saving (and starting to save sooner, rather than later), trade offs with different types of investments and a worked example of why you should completely avoid credit card debt.

I think this is one of those areas that programmers often neglect. It is all too easy to get wrapped up in the technology side of things, and forget to take care of your finances.

Disclaimer: Dan provided me with a free review copy of the e-book, but my comments were not biased because of this.

Here are just a few of the principles espoused in the “Elements of Style” (see my previous post) which I have taken liberty with and made a few OO analogies:

Choose a suitable design and adhere to it. This pretty much stands alone as good advice in the context of writing or coding. Spend time on the design before you start coding. Don’t hastily start coding to one design, then change it, and then change it again.

Make the paragraph the unit of composition. As a general rule, start each paragraph either with a sentence that suggests the topic or with a sentence that provides a transition. This is similar to grouping like behavior into classes. A class should contain a well-defined set of related methods, not just a random collection of unrelated functionality.

Keep related words together. The principle means of showing the relationship of words to one another is their position. The intent is to give clear meaning, and not to confuse the reader by making sentences ambiguous. The analogy I tenuously liken this to is name your methods accurately, preferably with verb-noun pairing.

Use the active voice. The analogy here is objects being asked to perform a particular behaviour rather than being used in functional coordinated approach.

Put statements in positive form. This is akin to avoiding the double negative in poorly named methods.

Use definite, specific, concrete language. Put truly common behaviour into abstract base classes, place specific behaviour in concrete classes.

Omit needless words. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences. This could be restated as: A class should contain no unnecessary methods, a method no unnecessary lines of code.

Avoid a succession of loose sentences. Do not place inappropriate behaviour in classes. If things get too complicated, make more types.

Jeff Atwood has posted a 'food for thought', historical perspective of the evolution of programming languages, Fifty Years of Software Development, over at his Coding Horror site (yes, that is the actual coding horror graphic from Code Complete! If you're a developer and you haven't read Code Complete, drop what you're doing and go order it from Amazon).

The Visual Basic 2005 PowerPack people have just released a PrintForm component to add back the functionality that was present in VB6. You can download it here: PrintForm Component 1.0. It will also work with C#.

A second edition of Steve Krug’s, “Don’t make me think” has been released. I’ve just added it to my burgeoning Amazon booklist. Steve has website here. It’s not exactly loaded with extra content but does have some interesting videos.

On the topic of one of my favourite subjects, usability, the headrush site is a gold mine of information. The latest post, Why they don't upgrade (and what to do about it), contains this pearl, “People don't upgrade because they don't want to move back into the "[I] Suck Zone."” I’m sure this is something Microsoft is spending considerable effort on with the approaching release of Vista.

Q: Have PC users queued up in the cold to buy a Microsoft OS since Windows 95? Kathy Sierra writes:

“By the time Apple releases a new version of Mac OSX, the Faithful are so
excited that they line up by the thousands outside Apple stores at midnight,
braving the cold, just to get the new OS a full 24 hours ahead of their friends.
How do I know? I've done it, twice. Once when it was snowing.”

Maybe Vista will get them queuing?

A few weeks ago, I posted a list of design principles for software development. Here’s a list of guidelines centered on the development process:

Development Principles

• #1: All change must be trackable. All development must be done utilising a Source Code Control system. SCC should be backed up at least as often as every night and should be the primary repository for all development.
  
• #2: Use an issue tracking system, preferably one that integrates with your Source Code Control system. Get developers to associate an issue ‘ticket’ when checking in source code.
  
• #3: Builds must be automated and your deployments should be buildable in a single step. Run nightly automated builds as a minimum. Consider using continuous integration. Anything that can be automated should be.
  
• #4: Run all tests automatically. Do not use manual procedures; that’s what computers are for! Create unit tests, preferably before writing any code (Test Driven Development). Run unit tests as part of the build process. Employ a code coverage tool alongside your unit tests.
  
• #5: Run automated user acceptance tests. Test early and often. Tests that run with every build are much more effective than manual test plans that sit gathering dust on a shelf somewhere.
  
• #6: Use code generation to increase your productivity and help avoid duplication. Do not use wizard code you do not fully understand. Look for repeated code patterns (such as Data Access Layers) and create templates to generate code from.
  
• #7: Keep a decisions document. It should be under source control. Record all design, architectural and development decisions, along with the reason for each decision, the date and where appropriate the participants involved.
  
• #8: When providing time schedule estimates, break tasks down to be less than 4 hours in total duration. Do not cave in to pressure from management to reduce schedule estimates when you believe they are accurate.
  
• #9: Make things easy to reuse. If things are easy to reuse, then it’s likely they will be. Strive for an environment that promotes reuse.
  
• #10: Perfect your use of debugging and diagnostic tools. Find the tools that suit your needs best, and get to know them well. Do not develop or debug by coincidence. Bugs do not go away by themselves!
  
• #11: Make your documentation part of the code; that way it is less likely to be out of date.
  
• #12: Use virtual development environments. VMWare and Virtual PC are both free. There are times when having a throwaway PC (or server) is essential: simulating a client site, creating a test environment, installing beta or trial versions of software, sandboxing dangerous code. Once a luxury, now a staple.
  
• #13: Strive for simplicity and consistency in your designs and in everything you do.
  
• #14: Understand your users' expectations and then deliver just a little bit more. If your users become project champions, you know you are succeeding where others often fail.

I’d like to leave you with this parting thought from The Pragmatic Programmer:

Sign your work: In previous generations, master craftsmen were proud and eager to sign their work. You should be, too.

A while back, Jeff Atwood posted an article on managed code analysis tools and more recently on the benefits and the dangers of misusing code metrics. Static code analysis can help you to come to terms with an unfamiliar code base. Here are a few free useful tools:

• Reflector (there is a list of add-ins here and Peli’s code metrics add-ins): the essential tool for .NET developers. I do not think it is an exaggeration to say that every .Net developer should be familiar with this tool.
• FxCop (1.35): although it requires version 2.0 of the .Net framework, this version will still interrogate .NET 1.1 assemblies. It’s a valuable tool and now integrates directly with VS2005. Make it part of your automated build process.
• NDepend (2.0): analyses .NET assemblies and source code and generates quality metrics reports. There is a quickstart tutorial here.

If you want to perform tracing on a web service or site that you’re developing, there are several tools out there. SoapScope is great for debugging web service calls on the wire but it costs US$299.00 for a one year license. The good news is there is a free option; namely TCPTrace and it does not require an installer. TCPTrace acts as a tunnel between a client and a server and displays requests and responses received.

If you can’t do port forwarding then there is also ProxyTrace and YATT (at the same site). Other tools like Ethereal are great but they alter your network stack, so if you want a non-invasive approach TCPTrace is a simple and free solution. [I saw this quick tip via Scott Hanselman’s developer productivity tools talks.]

A non-programmer recently asked me what refactoring is. Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the system, but improves the internal structure of its code, making it easier to understand and maintain, and thereby reducing the cost of making subsequent changes to the system. Refactoring goes hand-in-hand with unit testing. Each unit test, should test a single method for a single set of inputs against an expected result.

• BEFORE you start refactoring, check that you have a comprehensive set of tests. If there are no tests for the method you are about to change, first write ‘enough’ tests to cover the existing functionality. Tests should have as few external dependencies as possible. The greater the code coverage of the tests, the less the risk of introducing errors.
• When refactoring, make changes in small steps. If you make a mistake, it is then easier to find the bug (provided you have a comprehensive test suite!).
• When you need to add a feature to an application, and the application’s code is not structured in a convenient way to add the feature, first refactor the application to make it easy to add the feature, and then (and only then) add it.
• I cannot over stress the importance of good naming. Never be afraid to change the names of things to improve clarity. If you find yourself unsure of how to name a class, it is probably an indication that you should try and split it into several, smaller classes.

I’m sure everyone has seen code at some point and thought “I should really change that, but I’ll have no way of knowing if my changes will break something else”? I know I have. Unit tests with ‘sufficient’ code coverage give you the courage to make radical code changes.

The unit testing tools you should take a look at are NUnit and NMock as a starting point, and then MbUnit and RhinoMocks. TestDriven.Net is a Visual Studio add-in that enables unit tests to be run from within the IDE. Automating your unit testing can be done using NAnt and
CruiseControl.NET (as well as several other tools including MSBuild). What are you waiting for? Write some tests and get refactoring!

The unstoppable developer machine they call Scott Hanselman posted a very watchable, short series of video webcasts back in August (I just got around to watching them!), on the subject of developer productivity tools. You can download all four parts for online viewing from here Developer Productivity Tools Video Part 4 (download links are towards the bottom of the page).

• Part 1 talks about Notepad2 (which is great for non-ansi character sets), some command line features you may not know about (or have forgotten), Process Explorer from SysInternals, Reflector from Lutz Roeder, and some .Net basics.
• Part 2 looks at some aspects of Serialization (includes a great tip on how to debug into a .NET XmlSerializer generated assembly), SlickRun, xplorer2, Far (Norton Commander rides again!), Google Desktop, junctions.
• Part 3 is a great introduction to PowerShell.
• Part 4 covers CodeRush, TCPTrace for tracing web service traffic, XmlDocViewer.

If you can’t express yourself well in words, how can you expect to write clear, concise code? Joel Spolsky makes this point many times over. In fact, he goes as far as saying: hire programmers that can write well. And I agree. Given the choice between two programmers of similar skills and experience, I would pick the one with the best writing skills. Joel makes some excellent points here Painless Functional Specifications - Part 4: Tips. Paul Graham makes excellent sense in Writing Briefly; I’ve been trying to follow a similar methodology for some time.

If you want to improve your ability to write clear code you need to improve your English writing skills. If you want to improve your writing skills (apologies in advance, to everyone for who English is not their first language), a good starting point is buying and reading the book “Elements of Style” 4th Edition by William Strunk and E.B. White. Incidentally, this was the book that provided the title inspiration for Brian W. Kernighan and PJ Plauger’s “The Elements of Programming Style”.

The “Elements of Style” is a tiny book; you could add it to your rucksack or briefcase without extending your arms that bit more! In fact, it’s small enough to carry in your pocket. The fourth edition is a little gem. I highly recommended you buy and read it, and then keep it close, so you can flick through it from time to time.

Several people left comments when I posted a few of my favourite quotes, so here's a few more.
The first quote in this list is from possibly one of the most brilliant men to have every lived, and one of my heros. I would have dearly loved to have met him.

I'm smart enough to know that I'm dumb.
- Richard Feynman

A little knowledge is a dangerous thing.
- Alexander Pope
[From an Essay on Criticism, 1709:
"A little learning is a dangerous thing; drink deep, or taste not the Pierian spring:
there shallow draughts intoxicate the brain, and drinking largely sobers us again."]

Success is the ability to go from one failure to another with no loss of enthusiasm.
- Sir Winston Churchill
He has all the virtues I dislike and none of the vices I admire.
- Sir Winston Churchill

Any fool can write code that a computer can understand.
Good programmers write code that humans can understand.
– Martin Fowler

All you need is ignorance and confidence; then success is sure.
- Mark Twain

If you tell the truth you don't have to remember anything.
- Mark Twain

It was on fire when I found it!
- Anon

Yes, you guessed it. It’s squid time!

Live giant squid caught on camera

You have to feel sorry for the squid, when the ‘researchers’ are getting excited at ripping off one of its tentacles! Doesn’t bode well for its continuing existence…

Super squid surfaces in Antarctic

I love coding! I can still remember when I first discovered programming at the age of eleven. At that age it filled me with a sense of wonder and it had the feel of a black art! But there’s one thing I like more than writing code…and that’s deleting it! That’s right, I just love deleting code.

Less code can mean less errors and less ‘cognitive friction’ when reading it, and therefore easier to maintain. I’m not talking about code that’s a candidate for the next obfuscated C competition! I’m talking about lean, simple, concise and precise code with no duplication.

The work days I like the most, are those when I leave work having refactored a large chunk of code (be it mine or someone else’s).

Liberate yourself, delete some code today!

OK, this is not a technical post, but I do like succinct, pithy quotes. They seem to sum up what we often do as developers, that is, reduce things to simple, but information rich forms, meme's if you will. Here are just a few of my favourite quotes:

In the land of the blind, the one-eyed man is king.
- Erasmus

Any society that would give up a little liberty to gain a little security will deserve neither and lose both.
- Benjamin Franklin

Those who cannot remember the past are condemned to repeat it.
- George Santayana
(often paraphased as: Those that ignore history, are doomed to repeat it.)

Those who can make you believe absurdities can make you commit atrocities.
- Voltaire

Never hold discussions with the monkey when the organ grinder is in the room.
- Sir Winston Churchill
History will be kind to me for I intend to write it.
- Sir Winston Churchill

Everything should be made as simple as possible, but no simpler.
- Albert Einstein

Any fool can defend his or her mistakes … and most fools do.
- Dale Carnegie

Every so often (actually quite often!), I come across something and I think “I really should have known that!” (bit like the F7 key in a command window…). Some time ago, pre-.NET in fact, I was playing around with some VB/Win32 API code written by L.J. Johnson, and put together a simple app. to display (among other things) domain group membership. I’m sure I’m the last person to know this but Microsoft have a freely downloadable set of Windows XP Service Pack 2 Support Tools that includes whoami.exe that can display your SID and group membership:

C:\> whoami /USER /SID

[User] = "HOMEDOMAIN\mitch" S-1-5-21-1935655697-117609710-839522115-1003

C:\> whoami /GROUPS
[Group 1] = "HOMEDOMAIN \None"
[Group 2] = "Everyone"
[Group 3] = "HOMEDOMAIN \Debugger Users"
[Group 4] = "BUILTIN\Administrators"
[Group 5] = "BUILTIN\Users"
[Group 6] = "NT AUTHORITY\INTERACTIVE"
[Group 7] = "NT AUTHORITY\Authenticated Users"
[Group 8] = "LOCAL"

Saw this via Bart De Smet’s blog.

So I'm watching yet another great Hanselman webcast, and he casually mentions that if you hit 'F7' in a command prompt window (cmd.exe), you get a history list of all your commands...wait a minute rewind that! I knew about the history list and the up/down cursor keys (as I’m assuming everyone does right?), but ‘F7’? And what do you know, the folks responsible for PowerShell have also included it!

Bart Duncan has posted a really useful article showing a step by step procedure on how to troubleshoot SQL Server locking problems: Deadlock Troubleshooting, Part 1

A recent on-going trend in web page design is for page layout to use pure CSS based layout instead of TABLE elements. [See References Zen Garden, Free CSS layouts for just a few examples.]

What are Control Adaptors? ASP.NET 2.0 has a new extensibility model built into it called Control Adapters. Control adapters allow you to plug into any ASP.NET server control through this model and override, alter or tweak how that control is rendered.

The great thing about control adaptors is they do not require developers to change the way they program against existing controls or to use new controls on a page. In fact, the developer can be completely unaware that a control adaptor is being used, because the control adaptor encapsulates all the functionality required. The ASP.NET 2.0 CSS control adaptor white paper can be found here.

A new Beta2 of the control adaptor toolkit is available and you can download it from here.

Scott Guthrie’s original article is here: CSS Control Adapter Toolkit for ASP.NET 2.0. His update article CSS Control Adapter Toolkit Update contains a Quick Start walkthrough. Excellent stuff!

• Unless you are writing framework code, do not consume non-specific errors by catching System.Exception or System.SystemException.
• There are occasional circumstances when swallowing errors in applications are justified, but these are few and far between.
• Do NOT over catch. Over-catching can hide bugs. Let exceptions propagate up the call stack.
• Catch specific exceptions only when you know you can recover from them. Do NOT catch exceptions you can do nothing about.
• If you can avoid throwing an exception, by using a TryParse, Exists or some other method, do so.
• Use try-finally rather than try-catch for cleanup code.
• For objects that implement IDisposable consider the using statement:

• Try to avoid catching and rethrowing: it can decrease the effectiveness of debugging.
• If you do catch and rethrow an exception, use an empty throw rather than throw ex, otherwise you will lose the original exception’s call stack:

• In web applications, create a global unhandled error handler that logs everything. There are several tools available to assist with this:
  SmartAssembly
  Jeff Attwood’s CodeProject article
  ELMAH

The links to the previous posts on this topic are here: part 1, part 2, part 3.

• Derive custom exceptions from System.Exception or one of the other base exception types (but not System.ApplicationException).
• Suffix custom exception type names with “Exception”
• Make exceptions serialisable, so they can cross remoting and application domain boundaries.
• Provide the following constructors on all custom exceptions, and use the same parameter names and types:

Exceptions are aptly named! Throw them in exceptional circumstances. A public method represents a contract with consumers. A method should raise an exception whenever it cannot successfully complete the task that its name implies it was designed to accomplish.

• Report execution failures by throwing exceptions; do NOT return error codes.
• Do NOT use exceptions for the normal flow of execution, if at all possible.

Don’t do this!:

• Create exceptions sparingly. Wherever possible, throw existing exceptions (from the System namespaces), rather than creating new ones.
• Create and throw custom exceptions in situations where an error condition can be handled in a more specific way than existing exceptions.
• Always throw the most specific exception that is applicable.
• When throwing an exception, provide a descriptive and useful message, explaining the cause of the exception. Since exception messages are only relevant when an exception is unhandled, the message text should be aimed at helping developers fix the bug.
• Check for bad arguments supplied to methods and throw ArgumentException, ArgumentNullException and ArgumentOutOfRangeException exceptions where appropriate. Set the ParamName property when throwing one of these. Code should almost never need to catch any of the Argument exceptions.
• Do NOT throw System.Exception or System.SystemException
• Do NOT throw OR derive from System.ApplicationException
• Do NOT throw CLR exceptions.

part 1, part 3 and part 4 are here

As a developer, some of the books I have on hand get read and re-read (partly due to low retention!). One such book is the Framework Design Guidelines by Brad Abrams and Krzysztof Cwalina; every .NET developer should have a copy of this within arms reach! After a discussion about exception handling best practices with another developer, I went back to this book for a re-read…and coincidently the same day, Scott Hanselman had made a post about the same topic. (I’m going to post this in 4 parts rather than one large post…)

The benefits of using exception handling over error return value based reporting are:

• Exceptions promote API consistency, because they are designed for the sole purpose of error reporting. In contrast, error return codes can be easily ignored or overlooked.
• Exceptions integrate well with object-oriented languages. When you have no control over error return values (in operator overloads, for example), an out of band mechanism is required.
• With exception based error reporting, error handling code does not have to be close to the point of failure. In fact, developers have a choice of where to site the error handling code.
• Exceptions can make your production code more robust than equivalent code that ignores error return values, because more problems will be caught during testing.
• Exceptions can have rich textual error information describing the cause of the failure rather than some obscure error number.

Although you should not use return codes to indicate failures, you can still return status information for successful operations (such as returning the number of records inserted).

part 2, part 3 and part 4 are here.

All you Star Wars fans may be a little disappointed by this post’s content! Jeff Attwood went there but came back. Scott Hanselman went there lured by John Lam, then Brad Wilson decided he liked it there. If you can’t beat ‘em… I’m going to try this out for a while...

OK, Bruce Schneier has got me at it! Every Friday for a while, Bruce has posted a tidbit about squid. Must resist….must …. resist….

Weird sex: Giant squid do it deeper
"Weird" New Squid Species Discovered in Deep Sea

As this happened 2 days ago now, it's probably old news! IronPython v1.0 for .NET has been released. You can download the binaries, source code, and tutorials from CodePlex here.

This latest release utilises some of the new dynamic language features added to the CLR in version 2.0 of the .NET framework.

I discovered Tess’s blog fairly recently. She has some great material on low-level debugging and internals. Her blog led me to this blog post with an excellent reading list of books and articles on the topic of .NET debugging.

David Lemphers has had a great idea that I think we should all try to support and contribute to. It's a Wiki for developers, but not for the technical nuts-and-bolts stuff. It's for all the other stuff that developers often give little priority to (and I don't mean washing!): things like career development and life skills, people skills and presumably chatting up the opposite sex for a spot of pair programming! But seriously, I think its a great idea.

It's almost live: Daily Developers...coming soon Drop David an email and let him know you're interested.

The only thing I don't like (and I realise I run the risk of being excommunicated) is that it's hosted on Sharepoint and it just doesn't look as calm and soothing as the standard Wiki look and feel. Does it have a standard Wiki skin?

The whole reason that the term ‘master craftsman’ exists, is to distinguish those people who take their craft beyond that of others. If everyone could build software to the same standards at the same speed, then we would all be machines!

Large projects are (and always have been) about managing large numbers of people with greatly differing skill levels, personalities and idiosyncracies.

It’s unreasonable to assume that what you can achieve with a small team of highly skilled, highly self-motivated individuals can necessarily be scaled up to larger teams, even with a in-house framework of standards, guidelines, tools and best practices.

Programming is knowledge work, it just doesn’t scale like manufacturing.

I came across a very nice collection of VSTS videos and webcasts compiled by Jeff Bramwell here.

Over at the Microsoft MSDN site there is an excellent set of ASP.NET 2.0 tutorials written by Scott Mitchell (of 4GuysFromRolla fame). These very useful and up-to-date (June 2006) tutorials walk you through creating a Data Access Layer (DAL), a Business Logic Layer (BLL), using Master pages (one of the great new features in ASP.NET 2.0) and wiring up UI elements to business objects. Each includes downloadable source code.

The series consists of:
Tutorial 1: Creating a Data Access Layer
Tutorial 2: Creating a Business Logic Layer
Tutorial 3: Master Pages and Site Navigation

Tutorial 4: Displaying Data with the ObjectDataSource
Tutorial 5: Declarative Parameters
Tutorial 6: Programmatically Setting the ObjectDataSource's Parameter Values

Tutorial 7: Master/Detail Filtering With a DropDownList
Tutorial 8: Master/Detail Filtering With Two DropDownLists
Tutorial 9: Master/Detail Filtering Across Two Pages.
Tutorial 10: Master/Detail Using a Selectable Master GridView with a Details DetailView

The .NET Framework 3.0 RC1 has been released:

.NET Framework 3.0 RC1 (containing Workflow Foundation RC5) http://www.microsoft.com/downloads/details.aspx?FamilyId=19E21845-F5E3-4387-95FF-66788825C1AF&displaylang=en

VS Extensions for Workflow Foundation RC5 http://www.microsoft.com/downloads/details.aspx?FamilyId=117ECFD3-98AD-4D67-87D2-E95A8407FA86&displaylang=en

Windows Vista RC1 SDK (optional: provides SDK samples and help) http://www.microsoft.com/downloads/details.aspx?FamilyId=117ECFD3-98AD-4D67-87D2-E95A8407FA86&displaylang=en

I found this great idea while ago in Bob Walsh’s book “Micro ISV: From Vision To Reality”: keep a summary of all decisions you make in a “Decisions Document”. Bob was talking about it from the point of view of a one person start up (or micro ISV), but it can apply equally well to a software department. This should be done for each project individually as well as another document for the department as a whole.

The Decisions Document should include a short description of the decision, the reasons for making it, the date, references to any documents or research material, and where appropriate the people involved in making the decision. It allows you to re-visit decisions at a later date and re-assess whether they still apply.

Design is not just about what you put into an application or product; it is also about what you decide to omit. An excellent place to keep your decisions document is in a Wiki (along with your other development artifacts).