Mike Nichols - Son Of Nun Technology : featured

Solo A Pensoso

Michael Nichols — Thu, 24 Apr 2008 06:52:53 GMT

Jimmy Bogard has a post that hits the nail on the head with being a lonely programmer yet still applying TDD. I have been asked by two separate people recently what resources they should consider looking into for starting out in programming. Even though I am hardly an authority, I inevitably encourage folks just now getting into it to start learning how to apply TDD. Here are a few other benefits which I see TDD bringing to the solo developer.

Refactoring is encouraged instead of rewriting . Having the freedom to do with the code what I want would usually leave the door of rewriting open to me. This not only stunts my growth as a developer who needs to learn to write code that is malleable, but also costs lots of money. But without tests in place, the paranoia would sometimes drive me to do a rewrite since the old code just didn't look perfect.
BUFD (Big Up Front Design) has a greater chance to be suppressed. One of the problems with working alone is the freedom to think big about all the neat things I could do rather than solving how to execute the project requirements. Since there isn't someone sitting their making a face because you are off-topic on a requirement, the humble [Test] acts as that face that isn't impressed by my gold-plated code.
Programming remains fun because it is doing stuff. Since there aren't the interesting discussions with peers or a sense of teamwork, the neat feeling we get when we see the computer doing our bidding serves to maintain some inspiration for the task-at-hand. If you are having to run the debugger and fight your way through a million NullRef exceptions or other misteaks to get to the point where you see something happening it is easy to get sidetracked or stop having fun. The feedback loop is more important for my sanity than the projects' success.
I am still learning. Working in small chunks seems to promote experimentation in me more than a big empty project template. If there are things I need to play around with I feel like it is easier and okay to do that within a test fixture...I realize this isn't 'TDD' in the sense of driving out my design using tests, but it nonetheless gives me the impression that I am free play around with something before I head the design that way.
Parameters are liberating. Stravinsky once said 'The more constraints one imposes, the more one frees one's self. And the arbitrariness of the constraint serves only to obtain precision of execution.' I have found the simple constraint of getting a test to pass drives me to improvise more in making it do so, usually making me think more creatively.

All I know is that I wasn't delivering features to my clients with as much confidence or timeliness before I started applying the principles the people who advocate TDD do. It isn't simply a matter of being disciplined, because I was quite disciplined, but I needed to focus that discipline into an paradigm that fed me as much as I feed it. For this solo pilot, TDD has scratched that itch.

Notification Services Distinguished From Logging Services

Michael Nichols — Mon, 11 Feb 2008 09:23:44 GMT

Freely admitting my naïveté and rookie/booter/redshirt status , I ask a simple question:

Why are messaging services such as logging often implemented via a pattern employing some kind of globally accessible object, yet similar services for passing messages from a domain model (perhaps using a Notification pattern) up to a client typically shown with handling inside of a controller/presenter try...catch statement?

I realize this is one of those error-prone 'one-size-fits-all' questions. It just seems like logging is messaging and so is notification, so why do we pass strings to calling clients for notifying them of the results of their actions while we have frameworks and static objects writing our log messages?

I experimented with an Notification-like object which was bound to my Unit of Work so that events/messages that needed to get communicated to the user would get aggregated and flushed after the unit of work was complete. This 'worked' by letting me simplify and standardize but I himmed-n-hawwed (redneck design technique) about the wisdom of that and in my current app haven't implemented it again.

Consider something like this, where we are using a globally accessibly Log object and have a 'Client' method that writes the message not to a log file, but is aggregated for consumption later depending on the client type:

Log.For(MyObject.GetType()).Client('The biz rule prevents this from happening.');

The objections I can come up with are:

Doing something like this in your Domain Model violates keeping a clean separation between Domain and Client.
If something can't happen as expected it IS an exception and so should be handled in traditional try..catch block

But then my answers are

I am logging things that happen in my domain, so how is that different than sending client messages out? Obviously I won't be passing stack traces to this 'Client' and the messages would be 'prettier' but I'd want to notify things like specification constraint violations, side-effects which were intended and noteworthy, and so on, so why is throwing and exception for that (so that my client will catch it) better?
I know the common view of exceptions is that things that can't be executed as expected are exceptional and so should be in a try..catch and handled appropriately. Ok, but I expect users to attempt some operations that due to some rule are not valid. I am not talking about invalid or missing data, but rather rules which perhaps due to the results of other data make the current request invalid. Or perform some operation that changes state in many objects which is not invalid or exceptional.

I use DTOs to pass from my Tasks layer (application services in DDD-speak I believe) up to my controller and its not overwhelming to just standardize and implement these common message carriers on up the chain, but there are many times when I'd like to notify the client of many changes that occurred due to the action they just took . For example, we have Materials Tests that can have retests, creating a parent-child relationship. Assigning a retest automatically removes it from one parent to another parent. This all happens and the new DTO is passed to the controller, but I want to let them know all the side-effects this action caused. Something like 'Test# 32 removed from Test#45. Sample Numbers have been regenerated for this project. '

I commonly am writing repetitive code to place messages into some kind of hash that is parsed and displayed to the user, and page design changes can make a lack of common practice painful when there is much repetition like this. Even though I keep actions as atomic as possible, there are still bound to be many state changes that are worth reporting to the user, no?

There are a ton of things I am sure I am not considering and I really don't want a slough of staticy global "Manager"-type objects doing infrastructure stuff invading my domain, but I'd love to hear how other folks implement client messages up the chain while promoting code-reuse in the controller/client layers or point out considerations I am no doubt missing.

Developer's Vista Setup

Michael Nichols — Thu, 06 Dec 2007 07:19:00 GMT

Moving to a new machine can be like moving from a house you've lived in a long time...you just take things for granted after a while that you have set up.

I got a new machine with Vista on it and decided to just start all over again installing only those things I really USE. Along the way, I had to search some resources to help me do a better job installing tools I have to have to do my job. So here's a list of some quick tips that have gotten me (mostly) up to speed on the new OS. Some are tool-related and some are just Vista oddities I had to learn. This all assumes UAC is turned on (if you like pain and suffering).

NAnt - nothing too different here, except be sure to run your command-line as an administrator. Here's the standard way of installing NAnt and here's how to always run your command-line as an administrator.
Subversion - want to just type 'svn' from the command-line? The best installer I have found is CollabNet's. I used other installers but this installs Apache and sets up repository directory for you too, doing some of the steps here, including installing Subversion as a service for you. Nice. After you have installed it, you'll want to go into the firewall and open up the tcp port (3690 default) and also go into the admin MMC services list and start the service. Once done, you should be able to run 'svn' from the command line.
VisualSVN - This is more of an VS 2008 issue, but be sure you are current on VisualSVN's latest version, per this post.
Total Commander - Windows explorer still sucks and Total Cmd works on Vista.
NVIDIA driver - Have an NVidia card and the driver sucks (computer won't sleep, etc.)? There are tips here to improve Vista performance, including using a modified driver .inf to fix the lame laptop drivers for these cards. The site to get them has been down so you can try here to get the .zip. I installed 163.75 and my computer sleeps now. Also ,this seemed to fix sluggish wireless keyboard action I was having.
TortoiseSVN - works fine on Vista, though I read about some problems in the past. I haven't had any issues yet.
Unlocker - installed just fine and works.
IIS 7- Really nice and the UI is sweet. Just be sure to enable Windows Authentication on your site if you are debugging from VS.
Notepad++ - The replacement for notepad.exe on the site works in Vista, but you'll need to run as administrator in all the usual places.

These are the primary tools I am using through the day that took a little work and investigation to get back to where I like things.

Vista hasn't been as lame or difficult as I have read so often, but it also isn't a step up either I think. It's hard to tell sometimes if the shutdown hangs, sleep failures, etc. are due to Vista or driver compatibility but I can say that things don't feel as stable as they did on XP. Still I haven't had any showstoppers related to development so that's good.

I'll post more of these as I discover things I had to figure out. The only real gripe has been the silent failure of services that haven't been given administrative permission explicitly. Sometimes a service you expect to run doesn't because it isn't running as administrator...DaemonTools did that to me when I was trying to mount VS 2008 install.

Hope this helps some one...

Page Lifecycle Study : Part One- The Project

Michael Nichols — Thu, 04 Oct 2007 08:04:53 GMT

This is one of those posts that pains me to write. I blame Monorail for the pain that I am now acutely aware of in working with the Web Forms model in ASP.NET. But that's a whole other post...

Dealing with the events that take place in the lifetime of a Page in WebForms is tricky once you get beyond the demo samples. Dynamic loading of controls based on state, collection control (ie, Repeater) value persistence between postbacks, and event timing of web controls immediately reveal to the excited "look I can drag a GridView and see my employees table" developer that he has just stepped in a big pile of over-architecture and got bizarre form behavior all over him.

And that is with ViewState ON.

A wise blogger once wrote ViewState is the devil and shortly after that I was checking out Scott Watermasysk's ASP.NET tips and dealing with bloated pages in my own application...I was encouraged to turn ViewState OFF and deal with the consequences. I really HAD to since my ViewState had gotten out of control.

As if that didn't complicate matters enough, I was using the Model-View-Presenter pattern and wrestled with how to implement this with a stateless view (more or less) that has a complex strategy for restoring values from the Request.Form collection while making the view the entry point for requests, thus seemingly forcing my Presenter/Controller into submission to the famed ASP.NET Page Lifecycle...something I was hoping to avoid.

I decided it was time to just isolate all this and create a test bed where I could discover exactly what is happening when with actual controls and get feedback from this monster to tell me what it demands for me to simply pass data back and forth in a text stream. So I created this simple project that has quite a bit of sample data and different ways to see events firing during the postbacks. Controls like the Repeater and DropDownList are absolutely non-intuitive once ViewState is OFF and so are worth a close look on how to persist values. Also, the event handling of simple controls like the TextBox require some deeper understanding once you turn ViewState off.

I simply had quite a bit of difficulty finding actual code that showed things happening at different times when I was first swimming in the sea of events ASP.NET offers...all I could find were pretty diagrams and lots of code jammed in Page_Load with the occasional exotic mention of the 'catch-up' performed by controls upon Controls.Add to the control hierarchy.

So for this first post, here is the project .

DISCLAIMER: It's not pretty, but rather could maybe be useful for people who are confused about what is happening in their pages or to teach others.

I have since settled down quite a bit regarding how I prefer to implement MVP since I created this. I'll post more on what I do with MVP in the future.