Joe Developer has been fired. Sacked. Terminated. Dismissed. Booted. "Dis-employed", if you will.
Before Joe left, he started to write one last piece of code. He was asked to write an HTTP Module in ASP.NET that will log some information, and will include the date and time when the application last started running. He learned his lesson in last week's misadventure (too little, too late), and made his DateTime field static, like so:
Joe's replacement, Estelle Hertz, has to finish the module Joe started. Estelle thinks Joe was off to a pretty good start and adds some event handlers, some logging code, and checks in her changes.
The testers are finding that the "start time" recorded by her module is drifting, but the event logs show the application is definitely not restarting.
Did Joe leave a bug behind?
The items in the "Add New Item" dialog box of Visual Studio appear in an arbitrary order. After a bit of sleuthing, I put together a brute force Powershell script to sort my items alphabetically. Now "Code File" appears near "Class", and I can always find "XML File" near the bottom of the dialog.
SortOrder, and my sanity, is restored.
What follows is the script. Download sort-vsItems.ps1. Let me caveat this script by saying it has only been tested on two machines. If you have any problems, do let me know.
Powershell is beauty!
Whenever Joe needs to display the application start date, he accesses this public field.
Joe doesn't know what is wrong, but he is sure of one thing – the date that is displaying on his pages is not the date when the application started. Can you help out Joe one more time?
I’ve been working on an article that will show how to use a Windows Workflow state machine to drive logic behind an ASP.NET web form. Generally, my approach in articles is to use just enough code to reveal a specific concept. I don’t use heavy abstractions or include the safeguards and proven practices we need for production applications.
There is delicate balance to strike when devising sample code, and you can never please everyone. Simple code will find itself cut and pasted into situations where it shouldn’t exist, and the person who has to fix the situation will curse you for being a fool. On the other hand, complex code is frustrating to the person who doesn’t want to tear apart three software layers just to see how to kick start a workflow in ASP.NET.
For the article I’m working on, I could cram 15-20 lines of code into a Page_Load event. I started down this road, in fact, but I began to feel dirty. So dirty, I took a hot shower and came up with something like this:
Now the ASP.NET web form doesn't know anything about Windows Workflow - it only sees a service that interacts with domain objects. Between this service and the WF runtime is a mediator that uses knows how to run workflows and harvest workflow results. A second service - a transaction service, commits units of work inside the same transaction as the WF persistence and tracking services. The end result is a unit-testable architecture, and relatively clean event handlers in ASP.NET code.
The result is a more advanced article where the reader will need to understand some of the WF basics before digging through the sample application. I might be leaving out beginners, but I feel the complexity is justified. Now I just need to finish the article, as it is one week behind schedule. It's easy to push back deadlines since I set the schedule!