Mitch Wheat - Treat the cause, not the symptoms!

Scott Guthrie has posted what must be the ultimate guide to Url Rewriting with ASP.NET. If you code for ASP.NET, and you haven't visited Scott's blog, you will be amazed at the gems in his Tips/Tricks section.

David M. Kean posted a great tip for developers using Visual Studio 2005 Professional, on how to integrate FxCop into the post build process. As he points out, it is not a replacement for the Code Analysis features of the Team editions.

I was searching for a copy of Claude Shannon’s seminal paper on information theory, when I stumbled across this collection of links to Classic Texts in Computer Science.

It includes classics such as Teach Yourself Programming in Ten Years by Peter Norvig, Frederic P. Brooks’s No Silver Bullet: Essence and Accidents of Software Engineering, the ‘Google’ paper that founded an empire!: The Anatomy of a Large-Scale Hypertextual Web Search Engine by Sergey Brin and Lawrence Page and Computer Programming as an Art by Donald E. Knuth, to name just a few. Well worth a few hours browsing.

Over at Gretchen Rubin's Happiness Project, Wednesday is Tip Day. In this set of tips, a few words ("The days are long, but the years are short") caught my eye and reminded me of one of my favourite, short pieces of poetry:

And the days are not full enough
And the nights are not full enough
And life slips by like a field mouse
Not shaking the grass
- Ezra Pound

Fran Allen is the first woman to receive the prestigous Turing Award. It was awarded for her contributions to program optimisation and high speed computing.

On several occasions, when working with SMTP email in .NET, I’ve wasted a few hours for a variety of reasons relating to firewalls, virus scanners, relay only from domain addresses and plain stupidity (pointing at the wrong server for instance), to name just a few.

Recently, a colleague fell victim to one such annoying problem. We both went through the list of usual suspects, trying everything we could think of, until we reached the ‘this is crazy!” point.

The Solution: If you’re running a later version of Mcaffee virus protection, you might want to turn off the default behaviour of blocking any outbound traffic port 25!

I’m tempted to mention the maxim of Sherlock Holmes:

“How often have I said to you that when you have eliminated the impossible,
whatever remains, however improbable, must be the truth” – The Sign of The Four, Sir Arthur Conan Doyle.

There is a useful FAQ for the 2.0 .NET Framework’s System.Net.Mail namespace at System.Net.Mail covering a range of common and advanced scenarios (and a corresponding one for 1.1 here).

Lutz Roeder's Reflector 5.0 has been released:

• Reflector 5.0
• Reflector 5.0 Add-Ins
• Reflector 5.0 New Features

As has Virtual PC 2007.

It's probably old news by now; get it here.

Bob Walsh posted an entry on Information Overload and how he combats it with a technique he terms 'framing'. I like the 'mis en place' like process he describes (especially turning off email, messaging software, telephones etc.)

The Visual Studio Team System Technotes are:

"short, focused technical articles that explain a specific concept or walk through a particular scenario. TechNotes are intended to supplement the product documentation and technical articles. In addition, we have brought together some
of our very best blog postings in a central location."

A nice resource for Visual Studio Team System users.

As you are no doubt aware, Mark Russinovich and Bryce Cogswell joined Microsoft when MS acquired SysInternals, but I think I must have missed the announcement of the SysInternals site becoming part of TechNet. It’s great that Microsoft is continuing to make these tools freely available. FileMon, RegMon and Process Explorer are just a few of the essential debugging and sleuthing tools available in the arsenal.

The Sysinternals Video Library is still available (though it is a fairly expensive) and the “Tour of the Sysinternals Tools” video is free for download.

Frank Arrigo and Nick Randolph have blogged about a new site site: Hooked on LINQ maintained by Troy Magennis.

It’s not hype; LINQ will radically improve the way that data is abstracted and consumed in .NET, not to mention make it easier for developers to create high performance, logically tiered designs.

It’s early days yet, but Vista does not seem to be making many waves.

John Brand, a research director of Sydney-based IT analyst firm HYDRASIGHT, notes that “early analysis, by larger enterprises in Asia/Pacific has been underwhelming in regard to the likely business value from upgrading to Microsoft's Windows Vista operating system. We believe there is little or no compelling technical or feature/function reason for larger enterprises to upgrade.” He also said the biggest competitor to the adoption of Vista is "Microsoft and the status quo…Previous versions of its own operating systems, as far back as Windows 98 and 2000, dominate the majority of consumer and business PCs - and will continue to do so throughout 2007 and beyond.”

There has been talk that Vista is “more secure” and that alone is a compelling reason to upgrade. Wait a minute, I thought XP SP2 was supposed to be secure!

Dan Appleman as usual gives a lucid and balanced view here: A Developer’s View of Vista

I normally field the odd ‘computer’ question from friends and family, but no one has yet asked me “What is Vista?” let alone “…should I upgrade?”

I think it’s going to take more than a few gadgets to sell Vista. Come on Microsoft, give me something to shout about.

Nice article crunching those large numbers and a topical reminder of climate change (which if you haven’t heard of, you must have been sleeping next to Walt Disney for a while, and congratulations on the medical breakthrough that got you revived…)

I suspect YouTube will be even higher this time next year. Google is at no. 4 and could conceivably be even higher as they guard their data as the article mentions. On the subject of Google watching, there is an article on Sergey Brin here.

Several bloggers (James Manning, MikeZeff) have noted the release of the .NET Micro Framework 2.0, whose homepage is here with a wealth of information and resources. There is also an overview of the .NET Micro Framework 2.0 which is primarily targeted at low-power, small, embedded devices (such as the soon to be common Sideshow devices).

OK, I'm not really a conspiracy theorist but… apparently doing loads of .NET and SQL Server work has a strange transforming effect on those that practice these black arts:

Mark Dunn on DNRTV and Perth local MVP Brian Madsen (hopefully Brian has put his picture back up).

Nick Malik posted an interesting entry titled What are the top 100 patterns that every developer must know on his “Inside Architecture” blog. His question prompted a few replies including my own, which I’ve edited and reproduced here.

My own thoughts are in line with the comments made by JohnCJ. The common patterns in a particular domain maybe different from those in others, hence the drive behind creating Domain Specific Languages (DSLs). There might only be 10 - 20 truly common patterns, and even those may take different concrete forms depending on their context.

I would be surprised if an ‘average’ programmer (is there such a thing?) could name the ten most common patterns and adequately explain them to someone else, even though they may be familiar with the principles of good design. That is not a bad thing in itself, as developers encountering patterns for the first time are sometimes prone to over use them. Come to think of it can you name and accurately describe the 10 most common non-compound patterns? I struggled to remember these: Factory Method, Abstract Factory, Strategy, Observer, Decorator, Façade, Composite, Singleton, Adaptor, Command, Iterator, Proxy, State. I honestly don’t think I could remember 100 design patterns!

I think a better approach is to teach developers the Object Oriented design principles that underpin the creation of patterns and a few patterns not to use (anti-patterns).

The patterns themselves are not as important as the underlying principles:

1. Encapsulate what varies.
2. Program to an interface, rather than an implementation.
3. Favor composition over inheritance.
4. A Class should have only one reason to change (Single Responsibility Principle or SRP).
5. Sub-types MUST be substitutable for their base (Liskov Substitution Principle or LSP).
6. Classes should be open for extension, but closed for modification (Open Closed Principle or OCP).

The Portland pattern repository: http://c2.com/ppr/ is a good resource, although it can be a little hard to search. If you are interested in learning about Design Patterns you should read Head First Design Patterns by Elizabeth and Eric Freeman.

I've just noticed that I've hit the 250 posts mark. When I started this blog I wasn't sure if I'd keep it up, let alone post 250 entries in around 9 months! Can I make 300 in a year...?

Not a post about the joys of opera, but HDR digital photography! If you have not heard the term before and you have a digital SLR camera and a tripod, it’s worth spending 30 minutes learning about it because the results are nothing short of spectacular.

HDR has similarities to the analogue darkroom technique (zone system) pioneered and perfected by Ansel Adams, whose stunning Black & White photographs are well known (I’ve been tempted to buy one for a while...).

PhotoShop CS2 has a built-in HDR feature and this article describes its use. [Note: the link was up yesterday when I visited but was down at the time of writing. Hopefully back up soon…]

The Photomatix tool has a downloadable free trial version here. This site has discussion, tools, examples and great resources and links. Some of these examples remind me of 18th Century paintings.

The show’s not over till the fat lady sings, so here’s a parting flickr link to a gallery of really amazing photos that have nothing to do with HDR, but are still worth a visit: http://www.flickr.com/photos/sbprzd/

I really like this idea from J.D Meier: 4 questions to end your day.

I’m going to give this a try; I’ve written those 4 questions on a 3 x 5 index card. All I have to do now is remember to read it!

MSDN has a recent article on Reviewing Managed Code:

“Summary. This document will discuss best practices for reviewing managed code.
Some practices are universal to reviewing managed and unmanaged code. Others are unique to reviewing managed code...”

This brief article does not go into as much detail as The Elements of C# style but does contain a few excellent bits of advice, such as incorporating FxCop into the build process and checking for and reviewing warning suppression statements as part of the code review process.

I noticed in the comments section that the following advice was given: “Comments must be clear and accurately describe the associated code.” This should be stated as “Comments must be clear and accurately describe the intention of the associated code.”

One thing that we all come across from time to time (at least, I know I’ve been guilty a few times), is we quickly prototype an application with literal strings embedded (message boxes, exceptions etc). We know that these should be packaged into a string resource file, so that changes are localised and globalization is supported, but then the application grows and the amount of work to convert those literals seems daunting. Check out the Resource Refactoring Tool, mentioned in this article, which can be used to refactor string literals out of code into a resource file.

I was browsing Gretchen Rubin’s Happiness Project (highly recommended reading) when I came across this post. Like Gretchen, I had not heard the term mise en place before, even though I’ve always practiced this method when cooking.

mise en place (pronounced MEEZ ahn plahs) is a French culinary term which literally means “setting in place”, or more figuratively as “everything in its place”. Mise en place means you have everything ready before starting the actual cooking process. Recipes are completely read and reviewed to check for the necessary ingredients and equipment. Ingredients are fetched, measured out, washed, chopped and placed in individual bowls. Equipment and surfaces are cleaned and readied for use and ovens are preheated.

However, mise en place is more than just a culinary term for preparation; it is a concept or a state-of-mind that when applied, results in a smooth-flowing, efficient cooking process. It is especially beneficial when preparing multiple dishes. It is a clearing of the mind of all but the central task. It is preparing your environment for ‘flow’, that zen-like state of mind when all that is thought about is the task in hand and all that surrounds us melts into nothingness, whether it be returning a 200+ kph tennis serve, computing a definite integral, writing complex code or any procedure that requires pure concentration.

Mise en place involves several steps which will ensure a smooth and enjoyable cooking experience:

1. Read the entire recipe. Determine which ingredients and equipment you will need and have on hand.
2. Prepare the workspace. Start with a clean kitchen and remove unnecessary items from work surfaces. Preheat the oven, prepare pans, boil water, etc
3. Do the work: Peel, chop, slice, dice, grate; pre-measure ingredients and put into individual bowls.
4. Follow the recipe and create your dish.
5. Clean up as you go.

Mitch Denny recently posted an article where he compares software development to food, Food as a metaphor for the software development process. Not wishing to leave this topic under-cooked, I decided to fire up the deep fat fryers…

Can ‘mis en place’ be applied to designing and writing software? We often rush to start coding too soon, without sufficient requirements or enough design. To paraphrase an old proverb “Design Twice, Code Once”.

Taking one or two liberties and borrowing heavily from “Object-Oriented Analysis and Design”:

1. Gather requirements. Talk to customers/users. Produce a feature list. Talk to the development team and make sure they understand what you are trying to achieve.
2. Create use case diagrams. Create use cases. Verify your requirements against use cases. Perform a domain analysis.
3. Break up the problem. Look for places where you can apply OO design principles.
4. Determine your architecture. Focus on one feature at a time to reduce risk in your project. Start coding.
5. Write unit tests and refactor as you go (Look for places where you can apply OO design principles).

Working easily and well is satisfying. Mise en place can help to achieve that state of flow.

If you want an introduction to debugging ‘hard’ ASP.NET problems (with Windbg and Adplus), you should check out Johan’s blog. I noticed this via Tess’s blog (not updated that often but nonetheless a great debugging resource) which I mentioned last year. The debugging reading list that the article references has moved to here.

Head First Object-Oriented Analysis and Design by Brett D. McLaughlin, Gary Pollice and David West. Published by O’Reilly.

1. Make sure your software does what the customer wants
2. Apply basic OO principles to add flexibility
3. Strive for a maintainable, reusable design.

Labels: analysis, book review, design, head first

I came across this roundup page of bit manipulations several years ago, and then prompty lost it.

So what are they good for? You'd be surprised where they crop up. Many a novel solution relies on these techniques. Admittedly, if all you are writing is UI presentation code, these probably won't be of much use. On the other hand, if you ever take part in any 'speed' coding puzzles, there are deep low level techniques to be gleaned.

I'm posting a link so I can find it again!

(PS. Anyone recognise where my terrible title comes from?)

There are several tools that can assist with creating and testing regular expressions. The Regulator and Expresso are perhaps the most widely used.

The Regulator, written by Roy Osherove, features syntax highlighting and integrates with Regexlib.com's database of online regular expressions via a web-service.

Expresso, written by Jim Hollenhorst, is another great tool for building and testing regular expressions. Expresso has some very nice features such as generating ready-to-paste C# code snippets from your regular expression.

Regex Workbench, written by Eric Gunnerson, has a nice feature that shows Tooltips that decode the meaning of subexpressions within an expression.

RegexDesigner written by Chris Sells is another useful tool. It is not quite as fully featured as some of the others.

Resources

• Regexlib: Regular Expression library: Regexlib also has a good resources section.
• Regular-Expression.info : has very clear explanations of various regular expression constructs, and some good examples.
• Learning .NET Regular Expressions with Expresso
• Introduction to Regular Expressions in .NET
• Regular Expressions in .NET by Darren Neimke.
• 4GuysFromRolla Regular Expression Information Roundup: includes links to introductory articles.
• Common Applications of Regular Expressions by Richard Lowe

Regular Expression Cheat Sheets

It might be a strange name for a technical site but www.ilovejackdaniels.com has a few gems of ‘cheat’ sheets (memory aid would be more accurate). The excellent regular expression sheet is no exception. In addition to the downloadable and printable cheat sheet this page gives one of the most understandable descriptions of regular expression functionality you will find anywhere.
There is a slightly less comprehensive but useful crib sheet here.

UPDATED: Add Regular-Expression.info to the resources list.

On the whole, I’ve been fairly successful (or lucky) with interviews in my career. But I must admit that even though I’ve tended to be able to correctly answer most if not all of the interviewer’s questions, I don’t always ask them enough of the right questions. Asking the right questions is especially important if it’s your first developer position after finishing College/University, because the first few years could shape your career for the next ten. I mentioned the importance of this in a previous post, Software Development Must Haves.

The questions you forget to ask when you are interviewing for a job, but wish you had asked after taking the job by Bruce Eckel. It's worth reading the range of extra questions that were posted in the comments section.

Top 10 Questions to Ask in an Interview, by Robin Ryan: This is a more general guide than just IT. I liked this quote: “An HR Director for Microsoft added: ‘Frequently the candidate, ill-prepared, searches his mind for just anything to ask. That person appears dumb, or uninterested, causing me to question what kind of employee they'd be.’”

Microsoft used to be big on lateral thinking / puzzle type interview questions as described in the book “How would you move Mount Fuji” by William Poundstone. Many of these are example of the “back of the envelope” technique (estimating from imprecise or missing information) which seems to be less frequently taught and practiced, such as “How many Piano Tuners are there in the U.S”. I’m not sure that these types of questions have ever been particularly relevant as interview questions (since the answers can be rote learned) but they can be amusing and good one-off, lateral thinking exercises: http://www.softwareinterview.com/

The Guerrilla Guide to Interviewing (version 3.0) by Joel Spolsky. Joel admits that he is fairly hard nosed about the interviewing process, “It’s because it is much, much better to reject a good candidate than to accept a bad candidate.” Joel suggests that only 2 things matter in a candidate: “In principle, it’s simple. You’re looking for people who are (1) Smart, and (2) Get things done.” I like Joel’s reference to the ‘hard part’ where he asks questions about recursion and pointers: “Sadly, despite the fact that I think that all good programmers should be able to handle recursion and pointers, and that this is an excellent way to tell if someone is a good programmer, the truth is that these days, programming languages have almost completely made that specific art unnecessary.” Whilst tutoring first year University students, I remember this was the ‘plateau’ that they had to get over in order to progress to the next level.

Scott Hanselman (and his clone army, ahem!) originally posted this list of questions aimed at ASP.NET developers. After a barrage of comments, he followed up with What Great .NET Developers Ought to Know, which resulted in a wide spectrum of responses ranging from people saying it was just a list of trivia, to those who basically thought "Ya, those are good. I'd probably have to look a few up." If you can answer every single question correctly without looking anything up then you’re doing OK! Scott makes the point that he isn’t trying to reduce an interview to a set of trivia questions, and Joel Spolsky doen’t like these type of questions at all: “Remember, smart does not mean ‘knows the answer to trivia questions.’”

Interviewing Web Developers - 20 Good Questions to Ask: one of two of these questions are probably more useful than others.

To end this post, here is a little light programmer relief (or how to gather requirements): Stupid Interview Questions.

And how could I forget the Daily WTF (you have to read these!): Tales from the Interview, Security by Insanity (this is my all time favorite), Tales From The Interview: A Perfect Ten, The Abstract Candidate

Labels: book review, microsoft