Caffeinated Coder

It could be because I’m still suffering from upgrade fatigue due to a massive migration to .NET 3.5 that we recently completed at work.

Then again, it might just be because C# 4.0 has received little fanfare compared to the LINQ and lambda magic unveiled in C# 3.0.

Whatever the reason, I didn’t get around to installing Visual Studio 2010 and experimenting with the new C# 4.0 features until just a few days ago.

Optional and Named Parameters, the first feature that I’m excited about, appears like a pretty minor feature on the surface but it has the potential to eliminate a lot of noisy “ceremony code”.

The concept is very simple and familiar to anyone who has specified a default value in a SQL Server stored procedure.

Up until now, when we’ve wanted to provide defaults for a method in C# and offer the API consumer a more concise way to call the method, we’ve had to rely on overloading.

Take the following common case code snippet as an example:

   1: public void TakeOrder(string name)

   2: {

   3:     this.TakeOrder(name, "Americano");

   4: }

   5:

   6: public void TakeOrder(string name, string drink)

   7: {

   8:     this.TakeOrder(name, drink, "grande");

   9: }

  10:

  11: public void TakeOrder(string name, string drink, string size)

  12: {

  13:     string order = String.Format("{0} wants a {1} {2}", name, size, drink);

  14:     orders.Add(order);

  15: }

Although the client code below is nice and concise, the method definitions contain a lot of duplication.

   1: StarbuxWench wenchDuJour = new StarbuxWench("Russ");

   2: wenchDuJour.TakeOrder("Brian");

   3: wenchDuJour.TakeOrder("Grif", "Mocha");

   4: wenchDuJour.TakeOrder("Kim", "Latte", "tall");

   6: wenchDuJour.PlaceOrder();

You might not notice it at first because you are used to it, but imagine if you had to provide a separate sproc definition for each optional parameter in a stored procedure.

Besides being noisy and high on “ceremony”, overloading is suboptimal because it doesn’t make the default values that are being utilized explicit, which can sometimes lead to unpleasant surprises for the consumer. I recently experienced this first hand when I wrongly assumed that the default value for comparison type for String.Compare was a case insensitive comparison.

Another limitation of overloading is that it requires a unique combination of types, which means that I couldn’t provide an overload with just name and size because they are both strings and I already have a definition with two strings (name and drink).

Now consider the C# 4.0 alternative:

   1: public void TakeOrder(string name, string drink = "Americano", string size = "grande")

   2: {

   3:     string order = String.Format("{0} wants a {1} {2}", name, size, drink);

   4:     orders.Add(order);

   5: }

Besides being much more concise and saving you the trouble of having to modify your code every time you want to expose a new parameter combination, it also solves the unique type combination limitation as well as hiding default parameteres from the client.

Here you can see that I’m skipping the second parameter by using the new named parameter syntax, which should be very familiar if you’ve ever worked with ruby.

   1: wenchDuJour.TakeOrder("Jacob", size: "grande");

Here’s a snapshot of the intellisense, which makes the defaults explicit.

As I mentioned before, this feature is pretty trivial when compared with lambdas or LINQ, but anything that removes cruft from my code is a welcome addition to the language.

Popularity: 1% [?]

I’ve been doing various degrees of Test Driven Development for several years and am still a strong advocate, but I’m definitely in one of those stages now where I am rethinking my approach.

The last time I found myself in this position was several years ago during my pre-mocking days when my test suite was taking an hour to run, the majority of my test failures were data-related ghosts, and the sql-laden setup and teardown sections of tests were painful to create and even more painful to maintain.

Now I find myself facing similar types of friction even though the causes may be different. Tests require too much effort to write due to mocking requirements, especially in areas of legacy code that need to be refactored to use dependency injection. Test failures are too often false positives caused by simple refactorings due to the tight coupling caused by interaction-based testing. The overall number of tests is difficult to manage from the perspective of documenting system behavior or being able to quickly discover whether a test already exists for a particular piece of functionality that is being modified.

As a result, our department has clearly stalled in its effort to incorporate TDD into our everyday development process and now I’m trying to figure out how to rectify that.

My current thinking is that the best way to make TDD a viable and sustainable option is to selectively use it only when it provides a net gain in value.

I know that this is somewhat of a blasphemous thought because TDD\BDD is more about design than automated testing, which means that it is supposed to be baked into the development process and therefore not optional (or so I thought).

Although I have definitely experienced moments where TDD has improved both the usability and elegance of my design by making me start from the perspective of the API consumer and incrementally add features in the simplest possible way that works, I have also seen plenty of cases where it provides little or no benefit in terms of design. For example, I often seem to write code that must fit into an existing design, follows a well known pattern, or only slightly modifies an existing method.

The same holds true for refactoring. While there have definitely been times where TDD has improved the quality of my code by providing a safety net that allows me to catch more bugs and refactor more freely, there have also been times when I’ve gained little value in this respect due to the simplicity of the code. In fact, lately I’ve noticed that there have actually been times when I have been less likely to refactor a section of code due to TDD because it had a large number of interaction-based tests around it that would all have to be changed to accommodate the implementation changes.

Finally, let us not forget that any and all code is intrinsically a liability. Since test code tends to grow at a much faster rate than normal code, the long term maintenance cost of your test suite becomes even more of an important factor to consider.

Ultimately, it seems as though some criteria for making a simple cost-benefit analysis are in order to help decide when it make sense to use TDD.

So far I’ve come up with the following:

When to write a test:

1. The design is unclear.
2. You’re implementing an important or complicated piece of business logic.
3. You’re about to implement a hack or sub-optimal solution because you’re afraid of breaking something in an existing piece of messy, complicated code.

It also occurred to me that just because you write a test doesn’t mean that you have to commit it. There are several design artifacts (whiteboard, napkins, etc) that are extremely helpful despite being disposable. Occasionally writing throw-away tests would certainly allow me to gain the design benefit without incurring the cost of maintaining a test that has little long term value.

With that in mind, the following scenarios seem like reasonable examples of when it makes sense to take the extra step of committing a test:

When to commit a test:

1. The code is important to the business and heads will roll if someone unintentionally breaks it.
2. The code is complicated and the next poor schmuck who touches it to make an enhancement has a good chance of unintentionally breaking it.

Other ways to improve the cost-benefit ratio of testing:

1. Use SRS to isolate important business logic – By favoring small classes and composition and focusing your testing efforts at this level rather than a higher level where they all meet, you will drastically reduce the setup cost of mocking out all the dependencies that probably aren’t relevant to your test anyway.
2. Favor state-based testing over interaction-based testing – I’ve run into a  few scenarios where interaction-based testing has been a blessing, but it seems like more often than not it just leads to inappropriate coupling with the implementation details that results in brittle test code. Use it sparingly.
3. Make test suite spring cleaning a post release ritual – Nothing succumbs to entropy like code. Test code is even more critical to keep clear, concise, and organized, because this has the potential to represent the specifications of how your system works. If something is no longer important delete it. If the test name isn’t clear or the folder structure isn’t optimal for finding features, then invest the effort to change it. Otherwise, the broken window theory will take affect faster than it takes Visual Studio to load.

Am I way off base here? Does anyone else have additional criteria for deciding when it makes sense to remove yourself from TDD mode?

Popularity: 1% [?]

I just finished my February book from my 2010 tech book reading list, so I thought I would share some thoughts on Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck before moving on to my March book, Clean Code by (Uncle) Bob Martin.

Rating - 1/2  (out of 5)

Prerequisites – This book doesn’t assume any prior knowledge, but it helps if you’re familiar with some basic Agile concepts. If you’re like me and prefer to have some mental hooks in place before starting a non-fiction book, then also take a few minutes to read the wiki summary page first.

The Good

1. Easily Consumable – Unlike the vast majority of technical books, this one is well structured, concise, and well written. The authors package up the information in 7 easy principles and 22 tools which neatly correspond to chapters and subsections. Weighing in at a slim 180 pages, many of which contain easy-to-read project anecdotes, business novelettes, and case studies, the book can easily be read in the span of a week.
2. Broadly Applicable – This book is all about concepts and principals that can can be applied incrementally to almost any scenario. In other words, you can still get value from it even if you don’t have the desire or the freedom to change your current development methodology.

The Bad

1. Management Genre – It has been a while since I’ve read Dante, but I’m pretty sure that at least one of the inner circles of hell is dedicated to making developers recursively read management drivel until they beg for mercy. While this book is very developer-centric and arguably has potential to greatly improve the quality of life for the average developer, it is still firmly grounded in the business-management genre and thus may inevitably irritate developers in a number of subtle ways.
2. Too Vague at Times – While the focus on broadly applicable principles has its strengths, it could also be frustrating for someone who is looking for a more concrete and instructional guide to help them overhaul their Software Development Lifecycle. This book is probably best used in conjunction with other more detailed and prescriptive resources.
3. Potentially Out-Dated – Despite being written in 2003, this book remains remarkably relevant. However, it is not at the forefront of Lean-inspired thinking these days and does not take into account the lessons learned from the front-line agilistas over the last 7 years. Based on some preliminary research, it appears that the current Lean-inspired trend is focused around Kanban, which you can find out more about here and here.

Conclusion – As long as none of my negative bullet points are deal breakers for you, then I would go ahead and recommend reading the book. If your bookshelf already over-floweth or you can’t justify spending another penny on tech books, then this might be a good one to “thoroughly browse” cover to cover at your local bookstore over a series of lunch breaks.

Popularity: 1% [?]

Disclaimer: This is not an exotic edge case or even a particularly difficult bug to figure out. I am merely writing about it because I managed to learn a few useful things about how .NET works in a 64 bit environment as I was investigating it and thought it might be useful to share.

The Bug: We recently upgraded one of our desktop apps from .NET 1.1 to 3.5 and our tester reported that it immediately crashed during start-up on a 64-bit machine (both XP and Vista). There were no problems with it prior to the upgrade and it still worked fine on 32 bit machines (…or rather, it did after we fixed all the cross-threading exceptions). The event viewer only showed a rather unhelpful unhandled exception in the Kernel32.dll (exception code 0xe0434f4d).

The Mystery: Why would upgrading an app cause it to stop working on a 64 bit machine? Wouldn’t upgrading it make it more rather than less likely to work on a newer machine?

Clues:

1. We have another desktop app that went through a similar upgrade but experienced no problems on a 64 bit machine.
2. The desktop app in question uses the default build configuration.
3. The application references an older ActiveX component.

Helpful Facts:

1. 64-bit machines support running applications as both 32-bit processes and 64-bit processes. The simplest way to find out if an application is running as 32-bit is to look for the *32 suffix in task manager. When testing a pre-upgraded version of the app, the suffix was there. After the upgrade it wasn’t there.
2. 1.1 apps automatically run as 32-bit processes, but 2.0 apps can be run as either. On 64 bit machines, the OS looks at a flag in the PE header of the executable to determine which type of process it should run in. The flag is set by the compiler and can be ‘x86’, ‘x64’, or AnyCPU. AnyCPU means that it will run as a 32-bit process on 32-bit Windows and as a 64-bit process on 64-bit windows. The default configuration in Visual Studio is AnyCPU.
3. A 64-bit process cannot load 32-bit dll’s – The application will crash with a BadImageFormatException.

The Culprit: The problem was obviously the ActiveX Control, which was a 32-bit dll. It didn’t cause problems before the upgrade because the application was forced to load in a 32-bit process since it was using the 1.1 framework. Once it was upgraded, it started loading in a 64-bit process because of the ‘AnyCPU’ default configuration we were using.

Our Solution: We simply changed the build configuration to ‘x86’, which forces our app to run in a 32-bit process. I read where you can also make an out of process COM server that wraps the 32-bit dll, but that seemed like more work than we were willing to do at the time.

As I warned, nothing particularly complicated or earth-shattering, but some good fundamentals to be aware of when debugging apps on 64-bit machines.

Anybody else have interesting 64-bit bug war stories or helpful hints?

Popularity: 2% [?]

When I first started writing this blog, I devoted several posts to planning and describing my efforts to become a better developer.

Although I was inspired by a certain unnamed developer’s public quest to read a book a week for six months, I never chose reading technical books as one of my goals.

I’m not sure why I didn’t consider reading technical books as a worthwhile endeavor at the time. Perhaps it was because I was overly infatuated by my RSS reader or maybe I was just fixated on the burgeoning list of tools, frameworks, and open source projects that I had only recently become aware of after finally branching out from my Microsoft-centric comfort zone.

Whatever the reason, I now find myself with a very different perspective on what will help me grow the most as a developer.

For one thing, after reflecting on my own strengths and weaknesses I realized that I have been focusing on breadth of knowledge for too long and now need to concentrate on increasing my depth of knowledge about software development. I decided the best way to remedy this current imbalance was to embark on a methodical journey to finally read the dozen or more high quality books on software development that I currently have collecting dust on my shelves.

My 2010 professional goal is to read one of the technical books in the picture below each month for twelve months and then do a blog post reviewing each one.

When I first hatched this plan a few months ago, I put some serious thought into the best way to ensure that I would actually meet this goal. I knew that publicly announcing an ambitious goal would provide some motivation, but probably wouldn’t be enough, especially since I have been apt to abandon blogging for 4-5 month stretches these days.

Instead, I opted to take the SMART approach, which is acronym that describes the characteristics of well formed goals. I first read about in Pragmatic Thinking and Learning: Refactor Your Wetware and was impressed how such a simple concept really helped me to refine my goals in ways that made me much more likely to achieve them.

How did I make my goal SMART?

• S – Specific – I didn’t just make a vague statement about reading more technical books. Instead I went to the trouble of picking out exactly how many and which ones I was going to read (although I left the order unspecified to give me a little bit of freedom to pursue what was most interesting or relevant to me at the time).
• M – Measurable – Writing a blog post review after finishing each book not only serves as a clear finish line for each monthly goal, but also provides a good way to mentally assimilate the information in each book from a SQ3R reading perspective.
• A – Achievable – I didn’t want to make myself miserable for a year with unrealistic demands on my time, so I sat down and thought about the maximum number of hours I could realistically spend doing technical reading in a week (10 hr) as well as how many pages I average an hour on technical reading (25 pg) and how long my biggest books were (800 pg). After doing the math, I figured out that I could realistically handle one book a month, especially if I alternated between easy and challenging books. So far I’ve validated my hypothesis by successfully tackling one of my toughest books in January, CLR via C# by Jeffrey Richter, and also being ahead of schedule for finishing my February book, Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck.
• R – Relevant – Besides addressing my concerns about focusing too much on breadth of knowledge and not enough on depth, I also found these goals to be particularly relevant to me because I had just received 6 new ones in the mail due to my amazon gift certificate windfall that I got from taking JP Boodhoo’s Nothing But .NET class last fall and thus was suffering from a nasty spike of unread book guilt.
• T – Time-Boxed – Setting clear time deadlines is essential in order in terms of both motivation and measuring success. I chose one month reading iterations because they were easy to track (my January book is…) and it kept me on a brisk yet sustainable pace.

As I already mentioned, I’ve completed one of my books so I’m off to work on my first review.

Popularity: 1% [?]

A friend of mine recently revealed a super, ninja-level consultant secret to me.

Whenever his work pipeline floweth over and an unknown client approaches him with a job, he quotes them a ridiculously high rate that he assumes they would never accept.

He calls it his “Go Away” rate.

The only problem is that these clients often do accept his proposal.

In fact, my friend admitted to me with a certain amount of amusement that he has noticed that clients are actually much less likely to balk and haggle over his “Go Away” rate than they are his normal, more reasonable hourly rate.

It reminds me of a recent wine tasting experiment that I read about where subjects did a taste test for a variety of wines and the only piece of information they were given was the price.

Not surprisingly, the subjects of the experiment overwhelmingly reported enjoying the pricier wines more even though the sneaky researchers often swapped the price labels between the cheap and expensive wines.

What is surprising, however, is that according to brain scans that were conducted by researchers during the experiment, people actually did experience more pleasure while drinking the cheap wines that they thought were pricier and not simply falsifying their answers to avoid looking uncultured.

In other words, the wine actually tasted better to them simply because they believed that the wine was higher quality.

While that improves the prospects for many consultants hoping to take that 4 week vacation to the Bahamas this year, what lesson can us poor salaried corporate slaves glean from this experience?

Although most developers don’t have the luxury of being able to quote a “Go Away” rate, they often do (at least on a subconscious level) have the option of giving a “Go-Away” estimate.

Don’t believe me? Consider the following scenario.

Your boss asks you how long it takes to code a CRM system from scratch using your dream technology stack. Do you actually sit down and give him the bad news, which is that the project probably won’t be finished until after he retires or is fired for incompetence or do you succumb to the typical developer’s hopeless optimism and mumble a couple of months?

Now, what if on the same day your boss asks you to give an estimate of how long it would take to change the color of some text on a legacy PowerBuilder app?

Just to make it interesting, let’s assume that the app in question is written using an unsupported version of PowerBuilder. Moreover, the data travels through no less than 6 rube goldbergian layers, the highpoint of which is an excel worksheet written by a disgruntled accountant and a 5000 line .bat file written by the network admin who just sent to prison for embezzlement. To top it off,  it interacts with a mainframe you’ve never heard of that was scheduled to be retired a decade before you started working there.

In the second scenario, would you err on the side of optimism or would you promptly ask your HR person how much time is left before you vest and then multiply that answer by 8 in order to derive your very own “Go Away” estimate?

If you noticed yourself leaning towards the second option, then you may want to stop and consider what we’ve just learned from the wine researchers.

If you over-inflate your time estimate too much, then you may inadvertently make your boss want that change all the more.

Quote too high of a “Go Away” estimate, and you’ll soon find yourself in a product kick-off meeting heading up a team of “high quality” consultants, all of whom are charging “go-away” rates, and listening to your CIO give a sunshine up the arse speech about how the new TCII (Text-Colorization Improvement Initiative) is going to revolutionize the way you do business.

Don’t say I didn’t warn you.

Popularity: 2% [?]

I’m deeply sorry.

The post you are about to read is mental masturbation in its purest form.

Its sole purpose is to release the mental tension that has been distracting me and otherwise preventing me from moving on to more productive lines of thought.

Yes, you guessed it. I am about to add yet another blog post to the already tedious list of reactions to Joel Spolsky’s now infamous Duct Tape Programmer Post.

So let’s skip the cerebral foreplay and jump straight in to my naked thoughts on the matter:

1. Did Joel really think that anyone would feel flattered by the Duct-Tape metaphor? – If you’re resourceful, then you might be able to use duct-tape get a car to the closest mechanic without the aid of a tow truck or keep pipes from flooding the house until the plumber gets there. If you’re McGuyver, you might even be able to fashion a bomb out of it. However, duct-tape is not typically a tool ascribed to artists or a material associated with fundamentally important work. Even Jamie Zawinski, the hero of the post, appears to have taken it for a back-handed compliment. Many of Joel’s ideological allies in the mini-flame wars that ensued also conceded that it was an unfortunate choice of words.
2. Is Netscape truly the ideal poster child for the ‘Just F__ing Ship It’ movement? I’ll concede that Netscape deserves a prominent place in history for its role in opening the web to the masses, but its long term track record for both quality and business success is problematic at best. Early versions of the browser were widely criticized for being excessively bug laden and the company eventually went bankrupt shortly after the failed rewrite debacle that ended up causing a three year lag-time between releases. Although there’s definitely room to debate exactly who was at fault for the spectacular failure, it seems to me like Netscape wasn’t the best choice to use as a centerpiece for this argument. Perhaps it would have been better to practice the Separation of Concerns principle, one of those crazy design fads that Joel rails about, and split apart the book review thread from the other tangled ball of themes in this post. Then he could have selected a more effective example to illustrate his point.
3. Does Joel really think multiple inheritance, templates, design patterns, and COM are good examples of the “fadish programming craziness” espoused by today’s architecture astronauts? – Perhaps he just forgot to insert “Imagine you were coding back in 1994” before he went off the latest installment of his architectural astronaut rant. Then again, perhaps it has been a little too long since he’s been on the developer end of things and its time that he stick with the marketing and managerial topics that he have become his staple in recent years.
4. Does he really not see the conflict of interest in starting a “shipping over quality” crusade while at the same time selling bug tracking software – At the risk of falling victim to a circumstantial ad-hominen, Joel arguing against Test-Driven Development is a little like the proprietor of a fat person’s clothing store attacking the medical establishment for advocating diet and exercise as a way to lose weight. Perhaps he wouldn’t have been the recipient of quite so many pithy twitter jabs if he spent more time over the last few years focusing on substantive topics and less time pimping FogBugz on his blog.
5. Why the “pretty boy” disclaimer? – This was the most confusing aspect of his post for me. It felt vaguely reminiscent of an old grade school “then I woke up” ending that I used to tack on to stories when I was just too afraid to to commit to their fundamental premise. Was he backpedalling because he realized that extolling “shipping above all else” as a heroic virtue was a fundamentally flawed premise when applied to the software industry at large? Perhaps he was trying to compensate for his unfortunate choice of the duct-tape analogy and reassure Jamie that he wasn’t actually making him the butt of a subtle joke. Then again, perhaps it was just a poor choice for an ending that served only to water down an already questionable piece of writing.

Ah. So much better…

The morning after

So…Um…Joel…AWKWARD…I guess that was pretty harsh in hindsight.

Did I mention that your original book is still among my favorites and that I would probably ask you to autograph on some decidedly non-phallic-looking peripheral device if we ever met in person?

Unfortunately, I still think that your post pretty much sucked. Sorry.

Popularity: 2% [?]

It’s been a few weeks since I’ve taken the Jean-Paul Boodhoo’s Nothin’ But .NET training course and I’ve had enough time and recuperate and reflect more on the experience.

Although I really enjoyed the course and am glad I took it, it seems wrong to just give a blanket endorsement of the course.

I just don’t think that any training course can or should even try to be well suited for every type of person.

With that in mind, I tried to come up with a few helpful criteria to help someone who is thinking of taking the course make their decision.

You may want to take the course if…

1. You are somewhat comfortable with 3.5 .NET syntax, but really want to geek out on Predicates, Actions, Funcs, and the angle bracket cesspool where they intersect with Generics.
2. You like using natural language API’s like Fluent NHibernate and are curious about how to construct an internal DSL of your own.
3. You are a Test Driven Development fanboy, but are looking for cleaner and more innovative ways of writing maintainable tests.
4. You think design patterns are just swell and wouldn’t dream of writing a Hello World app without at least a dozen classes, but would like to see these principals in practice by someone who really knows his stuff.
5. You prefer a code-centric approach to learning and want to spend most of your time either coding or watching someone else code rather than simply listening to concept-laden lectures.
6. You wouldn’t mind a little motivational kick in the butt.

You may want to run away screaming from the course if…

1. You don’t due well with sleep deprivation.
2. You are deeply cynical and motivational tangents cause you physical pain.
3. You view design as hopelessly subjective and are fast to dismiss any additional layers of indirection as over-engineering.
4. Although you might be interested in learning how to use MVC Frameworks and IoC Containers, the thought of creating your own implementations as a learning exercise seems downright ludicrous to you.
5. You are NOT someone who is ‘convention promiscuous’ and the thought of doing things like naming_methods_with_underscores immediately sends you into Rain Man mode.
6. You get frustrated easily whenever you don’t immediately understand what is going on. JP is of the ‘push yourself past your limits’ and ‘learn by immersion’ school of thought when it comes to teaching. Unless you are in the top 5-10% of programmers, you’re probably going to feel pretty lost at various points of the course. If you are someone who can’t deal well with that feeling, then this course is probably not be for you.

Great Big Fat Disclaimer – I get the feeling that the content of JP’s courses tends to change pretty dramatically from month to month. This is a testament to his own talent and discipline when it comes to being a continual learner. However, it also means that you should probably take characterizations of the course (like this one) with a grain of salt.

Some Essential Preparation Tips For Those Crazy Enough to Take It- For those of you that have decided to take the plunge and sign up for a future Nothin But .NET course, I highly recommend that you take the course preparation seriously. At the very least, you should do the following:

1. Watch all of his DNR TV design videos – JP demonstrates design principals continually throughout the course, but doesn’t really take the time to explain them up front. It is helpful if you have a good grounding in these to begin with.
2. Learn and Practice R# short-cuts – JP is a true ReSharper Jedi and therefore his coding demonstrations can be hard to keep up with if your brain isn’t already used to taking the mental shortcuts that R# allows you to take.
3. Practice using his BDD Library Extensions – I feel pretty comfortable with TDD and am used to BDD-style naming conventions, but the fluent interface style BDD library that JP wrote and uses in the course through me for a loop at first. I wish I would have taken the time to get used to it more before the course.
4. Sleep extra the week before the course and consider staying in the hotel even if you are local – In the words of a good friend of mine, “No amount of Starbucks makes you smart at 2:00 am”, at least not after 17 straight hours of intense training. It didn’t help that I only got a few hours of sleep the first night because of a sick baby at home, but I definitely would have been better off if I had tried to get extra sleep the week before.

That’s my two cents.

Any alumni out there want to offer a dissenting opinion?

Popularity: 1% [?]

As part of the Nothin But .Net training experience, JP Boodhoo encouraged us to try out a few non-standard naming conventions that has adopted recently.

The one that intrigued me the most was his convention for naming interfaces.

Rather than taking the Microsoft sanctioned approach of adding an I prefix to all interface names, JP adopted the convention used in the Java world of reserving the unadorned name for the interfaces and instead adding an Impl suffix to the end of the concrete classes that implement the interface.

Actually, this was actually not the first time I’ve been exposed to this convention.

I have a vague recollection of Dru Sellers making a similar case for using this convention a few years ago when I worked with him. However it didn’t make nearly as much of an impression on me at that time because I wasn’t in the habit of using interfaces except when I wanted to achieve polymorphic behavior and I had already used up my base class.

Since then I started using interfaces for almost everything except entity classes. I first went down that path out of necessity because it was a requirement of Rhino.Mocks, but after I started reading about the SOLID principals and getting a better understanding of the benefits of loose coupling I adopted the approach as a de facto design guideline.

Now that interfaces play a much more central role in my code, it makes perfect sense to me that they should take precedence over concrete types when striving to create names that make my types more readable.

It also strikes me as odd that the naming standard for interfaces is clearly a vestige of the days when Hungarian notation (e.g. strName, intAge) ruled supreme. If Microsoft actively discourages the use of Hungarian notation in the case of every other type, then why should this one be any different?

When I first considered the possibility of going against the Microsoft standard, I worried about the confusion it would cause for future developers.

However, my experience in the course was that it was only confusing for the first day and then I actually grew to like it once I internalized the convention and started relying more on my color scheme of my IDE to immediately distinguish interfaces from classes.

I especially liked how the new convention served as a constant reminder of the central role that interfaces should play in my design.

Is anyone else out there using this convention?

Is it folly to swim against the stream in this regard?

Popularity: 4% [?]

I woke up this morning in a semi-zombie state and just learned that tonight will be our “late night”, which means we’ll go until 2 or 3 am instead of midnight. Nevertheless, I’m still enjoying the course.

Here’s some thoughts about the second day of the course (yesterday).

1. Actions, Predicates, and Funcs…Oh My - We started the day with a wrap up of all the work we did with delegates from day one. This is when the lightbulb finally went off in my head on the differences between the Actions, Predicates, and Funcs types. They are just convenience wrappers for delegates with different signatures. If you need to pass around a method that returns a bool, then you’ll want to use a Predicate (filtering & matching). If you just need to store a void method, then pick Action. Otherwise, if you’re working with a method that returns a value, then Func is what you’ll need.
2. Imitate, Assimilate, Innovate – This is a model that represents the stages of learning. I realized that I spend too much time in the imitate stage (adapting googled code) and almost no time in the innovate stage. One of the first goals I selected for myself this week is to spend more time in the innovate stage. A long term goal is to eventually launch an open source project. Kudos to Dru and Rob, two former co-workers, who took this step already.
3. JP’s BDD framework – This is a fluent interface that replaces test attributes, asserts, and obscure mocking API’s with more a fluent interface that reads more like an English sentence. It disoriented me for a while, but the syntax is starting to grow on me after a few days of using it. Check out this post for a sample of the syntax.
4. Rewriting frameworks from scratch – The first day we implemented LINQ extension methods from scratch. Yesterday we wrote the routing portion of a basic MVC Framework. Today we’ll be writing an IoC container from scratch. These sound like an inane “reinventing the wheel” tasks, but they are meant to be simple exercises to help us practice good design. Not only did it help increase my conceptual understanding of the lower level infrastructure I’ve been using, but it was also very empowering to temporarily counteract the long term trend of consuming API’s and frameworks at that are higher and higher on the abstraction stack..
5. Coding Centric Course with no Lab Manuals – Most training courses that I’ve attended or taught have provided students with detailed instruction manuals on how to complete the lab portions of the course. By contrast, JP cuts you loose with minimal direction. It was frustrating at first, but then I saw the value as soon I noticed how focused I was when he finally showed us the solution. It made so much more sense than it would have otherwise once I had some context based on first hand experience.
6. Using Delegates to Test the Untestable – Probably the most memorable technical epiphany I experienced yesterday was when JP showed us a technique for testing methods that contain static framework methods or concrete framework classes without interfaces, both of which are unmockable when using RhinoMocks. By turning the methods into delegates that are private member variables, we were able to use interaction based testing to verify that the methods were invoked and that all the correct parameters.

Popularity: 1% [?]