Code Obsession

Visual Studio Hotkey for Web Devs: Attach to W3WP

2011-12-14T12:19:00.000-08:00

Friends keep asking for this, so here are the instructions:

In VS2010 open the Tools / Macros / Macro IDE menu item
Create or edit the MyMacros project
Add a new Module called "AttachToProcess"
Replace all the code with the following:

Imports System
Imports EnvDTE
Imports EnvDTE80
Imports EnvDTE90
Imports EnvDTE90a
Imports EnvDTE100
Imports System.Diagnostics

Public Module AttachToProcess
    Sub IISWorkerProcess()
        Dim attached As Boolean = False
        Dim process As EnvDTE.Process

        For Each process In DTE.Debugger.LocalProcesses
            If process.Name.EndsWith("w3wp.exe") Then
                process.Attach()
                attached = True
            End If
        Next

        If Not attached Then
            MsgBox("Couldn't find w3wp.exe")
        End If

    End Sub
End Module

Save this macro
Close the Macro IDE
Right click the VS2010 menu bar
Select Customize...
Click Keyboard...
Select Macros.MyMacros.AttachToProcess.IISWorkerProcess from the lists of commands
Enter a shortcut in the box (I use Ctrl+Alt+A)
Click Assign, then OK, then Close
Open a web application, browse to the site and test your macro

Enjoy!

Global Day of Coderetreat - Attendee Report

2011-12-04T12:36:00.001-08:00

Yesterday was my first opportunity to attend a Coderetreat. I am so glad I did. What an amazing day. I think every developer should attend a Coderetreat. Using the closing circle format, allow me to share my experience as an attendee of the Salt Lake City event.

What, if anything, did you learn today?

I learned that I need to slow down and focus on writing code well. The mute session taught me how hard it is to see an architectural vision from the code. It felt like I was painting a picture using the stippling technique and my pair could only see the dots, not the image. I learned that the idea of intention-revealing, self-documenting code cannot be judged by the author only by another developer.
I also learned that Amber Smalltalk is pretty sweet. Thanks, Johnny T!

What, if anything, surprised you today?

The biggest surprise for me was how many developers said the Coderetreat inspired them to go out and actually do TDD. I had expected that most of the attendees would be rather dogmatic about testing and TDD. I know that at several points, I had to remind my pair to write a test before the code.
I was surprised at how far we got and how many tests we wrote in the mute session. It takes a lot of tests to reveal the intent sometimes. We had close to 40 tests when we deleted the folder.
Also surprising was how hard the last session was. We were allowed to pick our own challenge and we really struggled with that. We kind of lost focus and switched challenges midway and by the end, I think we were just coding trying to get as far as we could in the problem.

What, if anything, will you do differently in the future?

I will try harder to value the ideas of others and explore them more deeply. In the last session, my pair told me that was his first session with a bounded world. My pairs and I created a bounded world (array, list, matrix, grid) in every session. I need to open my mind more to alternate ways of accomplishing tasks.
I also need to recognize how attached people can become to the code they write. I had no problem deleting the code I wrote, but more than one person expressed anxiety about it. When others change or remove the code I write, I assume they are improving the application in the best way they understand at that time, so I don't resent the changes. I need to remember that this is not a universally held belief and that changing another developer's code could be considered an insult or attack on them and their abilities.

Global Day of Coderetreat - Organizing

2011-12-04T11:24:00.001-08:00

Yesterday was the first ever Global Day of Coderetreat. Using the closing circle format, allow me to share my experience as an organizer of the Salt Lake City event.

What, if anything, did you learn today?

The first lesson I (re-)learned as an organizer is that we have an awesome community both globally and locally. There were so many people willing to help out and make this a great day for coders. Of the many tasks required to make the day happen, I could only do a portion on my own.

Kay Johansen did an amazing job as the facilitator. I don't know how to thank her enough for all she did.
Mike Clement took the lead in communicating with the facility sponsor including making last minute calls to get doors unlocked so we could set up early.
The STG office staff, including Crystal, Kelly, Thayne, Marth, Ron and Chick, took care of our catering needs including correcting a communication error with the restaurant.
All of the attendees helped clean setup and clean up the room.

The most important lesson I learned through organizing the event is empathy for managers. The lunch mix-up is actually what triggered the epiphany for me. When you delegate an important task to someone else, you have to trust them to do it well. When lunch arrived and was only enough food for 6 people instead of 30, my very first reaction was,

"I should not have trusted anyone else to take care of this.

I should have done it myself!"

Fortunately, I have been working in agile development shops for years and I was able to focus on the solution rather than the problem. My excellent team members Martha, Ron and Chick sprang into action and got additional food ordered and delivered and everyone had a great lunch. Kay ran the prelunch session long so that people didn't realize they weren't eating. I think most of the attendees were thrilled for the extra time anyway.
So, the next time a manager tries to micro manage the team or me directly, I will have a lot more empathy for that behavior. Rather than resenting their lack of trust, I will try to remember the way I felt when lunch arrived. Then I will work in a way that inspires trust, so that they don't have to feel let down or the desire to micromanage.

What, if anything, surprised you today?

I think the biggest surprise was when lunch showed up.

What, if anything, will you do differently in the future?

I'm not really sure what I will do differently. I think that communicating expectations more clearly and communicating with my team more regularly will be part of it. The locked doors and lunch mix-up could have easily been avoided if we had communicated the needs of the event more clearly.

Conclusion

This was a great experience for me. I will not shy away from participating in the organization of future events.

Linux and Coderetreat

2011-11-13T13:53:00.001-08:00

So, I haven't posted in a while. I guess I've been busy? I dunno. I have been organizing/coordinating the Salt Lake City event for Global Day of Coderetreat. I guess that is keeping me busy. We have a facility, a facilitator and meal sponsor, so we are getting pretty close to ready. Good thing, since it is only 3 weeks away! Oh yeah, we're almost sold out too, so if you wanna come, you better register soon!

The other thing eating up my free time is Linux. Specifically Ubuntu. As you may remember, I decided to run an Ubuntu VM on my Windows 7 laptop. I really want to expand my skills in new (and somewhat uncomfortable) directions and this seemed like a great option. I have been going through the 7 Languages in 7 Weeks book with the Utah Software Craftsmanship group and it seems like the Linux support for a lot of these languages is better/easier.

Here is my experience and what I have learned so far:

The first thing I did was use the Wubi installer to create a dual-boot, pseudo-vm of Ubuntu 11.04 on my laptop. I used this for a while and it was fine. I had RubyMine running and I had some decent success using it for learning Io. Despite my initial assertion that I would use Linux for everything I could and only fall back on Windows when I needed to or felt stuck, I found myself booting Windows more and more often.

Eventually, Ubuntu 11.10 was released, and on one of the rare days when I loaded up Ubuntu, I decided to accept the upgrade. After the download and install, there was an automatic reboot. That was the end of my VM. It never again booted past grub. I tried several times to fix or reinstall it and never got anywhere. Eventually, I had the Linux guys at my office help me out and they couldn't get it working either, so we started over...

We used gparted to create a real partition for Ubuntu (60GB) then installed 10.04 LTS Lucid Lynx. It turns out that for me, I have no reason to be on the newest versions of Ubuntu. A nice, stable version is a perfect place for a noob to play. I have learned about some of the nifty UI tools that are build in and I have been enjoying the multiple workspaces even more than I did before I broke my 11.04 install.

With a moderate amount of struggle, I managed to get RubyMine 3.2 installed (I couldn't work out the environment variables and the java version.) I have also have MonoDevelop up and kinda running (it gets a weird error when I try to run NUnit tests.)

My next steps are:

Learn enough VIm to be dangerous
Get a Rails app running
Run through the Erlang tutorials in 7 Languages
Build an ASP.NET app with MonoDevelop
Continue using Ubuntu daily as my primary, at-home OS

SOA : RPC : : Object Oriented Design : Procedural Programming

2011-10-06T00:54:00.000-07:00

Back in 2008, I attended SDBest Practices in Boston. I had recently read Jimmy Nilsson's Domain Driven Design book. One of the contributors to the book was Udi Dahan, so when I say that he was talking at the conference, I was excited to attend his session: How to Avoid a Failed SOA. At that point, I didn't know much about Service Oriented Architecture, but what he described as a failure mode sounded like an architecture I had discussed and planned with coworkers. That session was the start of a journey into learning about SOA.

I spend my spare time reading about SOA. I read Udi's blog. I read Thomas Erl's book Service Oriented Architecture. I read SOA in Practice. I played with various ESBs and Message Brokers. I built a pretty sweet prototype of my company's systems using NServiceBus. I even attended the SOA World 2009 conference in NYC and a full week immersion course on SOA taught by Jean-Jacques Dubray. In the end, I never took any of it to production because it didn't align with the Enterprise Architect's vision.

What I learned is that the naive implementation of SOA is to distribute workload in a system by making Remote Procedure Calls to (web) services running on other systems. Unfortunately, this style of architecture runs into the fallacies of distributed computing. Put simply, you can't take a remote call to a database server from your web server that takes X ms and introduce a web service call in the middle and expect it to take less than X ms.

Taking into account things like the CAP Theorem, eventual consistency, CQRS, etc leads to a different strategy. In this implementation of SOA, one focuses on Domain Events and the Messages exchanged by the Services rather than emphasizing the Services themselves. I have often contemplated these types of systems and how they lead to simple, autonomous, easily-redundant, horizontally-scalable Services.

The similarities to OO are striking. Object orientation is also about message passing. In languages such as Smalltalk, we talk about "sending messages to objects" or "objects receiving messages" rather than talking about "calling methods on objects." The characteristics of these OO systems are similar to the what we desire in SOA. They are (or can be) loosely coupled and focus on performing actions rather than requesting at-rest data to be operated on externally.

So when building software, whether a single application or a collection of inter-operating applications that form a complex network with high availability and scalability requirements, remember to focus on the messages, not the Objects/Services. This is what I was thinking about the other day when I tweeted, "I never understood OO until I studied SOA. It's not the object/services that matter. It's the messages."

Into the mine shaft..

2011-09-21T12:28:00.000-07:00

I think we are all somewhat familiar with the concept of canaries in coal mines. As recently as 25 years ago, canaries were taken into coal mines as a way to detect poisonous gasses such as CO2 and methane. The canary would sing all day long unless overcome by the gasses. At this point, the miners would realize their environment had become toxic and they would flee for their lives.

Development teams sometimes find that they have a canary in their midst. This person seems to point out unseen dangers ahead based on the current path. The things that the canary sings about aren't really affecting the team, but he or she claims they will if not corrected. How do you know if you have a canary or a whiner? That is tricky. The best advice I have is to look to experience. Does the person have experience working with multiple teams in multiple environments? Has she experienced similar situations in the past? Does she give recommendations for alternate courses of action? Is she passionate about achieving success? Is she regularly educating herself on the topic? I find that canaries seem to focus on one or two things that they are really interested in and they take pains to learn as much as they can about those topics. If someone whines about everything, he probably isn't a canary.

Let's face it, a canary can be pretty annoying with their constant singing about unseen dangers. The good news is that canaries are really easy to kill. You can ignore them to death. Martin Seligman did extensive research into learned helplessness which you can read about in the book Learned Optimism. The gist of the theory is that if you learn that your actions cannot affect your environment, you will eventually stop trying to change your situation and you will accept whatever comes. Using the techniques described in his experiments, you can easily, if not quickly, kill your annoying canary. He or she will eventually either leave the organization or give up and stop warning about unseen dangers.

So if they are annoying and easy to eliminate, why not do just that? Well, the obvious answer is that the canary is protecting your team from some real danger. Eliminating the canary doesn't protect miners from CO2 or methane poisoning; it just reduces their chances of survival once they all start feeling the effects of the problem. They say that an ounce of prevention is worth a pound of cure. The canary allows you to address problems before they become large and difficult. Keeping morale high on a team is often easier than fixing an ongoing morale problem. Eliminating technical debt early means that there is less code depending on that bad code. Study after study in our industry has proven that the longer you wait in your process to fix a defect, the more expensive it becomes.

So if you are lucky enough to have a canary, you should listen to her and take what she says seriously even if you choose not to act on her advice at that time. And you accidentally kill your canary, my advice is to get out of the mine shaft in a quick and orderly manner lest you suffer the same fate...

Model View Presenter - A Path Forward from WebForms

2011-09-10T14:20:00.000-07:00

This post is a review of my September 10th presentation at Utah Code Camp.

"So you read and hear about Test Driven Development, MVC Frameworks, Continuous Integration and the safety net provided by high levels of unit test coverage. But you work on a WebForms app that has been around since .NET 1.1. It has thousands of lines of code in the code behind classes and you know that isn't easy to test. How can you experience all of these wonderful things you read about? The Model View Presenter pattern is here to rescue you. We will discuss the purpose and structure of MVP as it is applied to WebForms. We will go through a demonstration of some relatively safe refactorings that allow you to start bringing your unruly code under test. We will then add tests using NUnit and Moq. We will wrap up the discussion with a road map from WebForms chaos through Model View Present into the promised land of the MVC frameworks."

Having worked on ASP.NET web sites/apps since .NET 1.0 beta 1, I have seen plenty of messy code. I have certainly added my fair share to the pile. I have seen 3,000 line code behind files, data access in the markup file and any number of things that make me cringe. If you work on a large or old ASP.NET WebForms site, I am sure you have seen it all too.

Some of the design decisions of the WebForms team have made it really easy to make a mess. That is unfortunate, but it is what it is. WebForms has accomplished its goal of getting VB6 developers into web programming, and, I for one am happy that I was able to easily make that move. The problem many of us face now is that we created web applications without truly understanding web technologies and now we feel like we are stuck in a swamp with no way out.

Software development has changed a lot in the last 10 years. Automated testing has gone from fringe to mainstream. Many development shops require unit tests and even TDD. ATDD is becoming a big deal. MVC frameworks, such as Rails, FubuMVC, OpenRasta or even ASP.NET MVC, have taken over the web. Object oriented design principles such as low coupling and high cohesion, SOLID and patterns are hot topics in the industry.

So as a developer, you want to know about and use all these cool, new things, right? But your code sucks. You can't see any way to use any of these tools or techniques without a rewrite of the system. And the short sited management still puts the business' needs ahead of your career development. Fortunately, there is hope!

Model View Presenter, specifically Passive View, provides a path from where you are to where you want to be.

thanks to Scott Denham for the image

To see an example of refactoring a WebForms application to implement the MVP pattern, walk through the commits on this github repository.

Now that you know how to refactor your code, what have you bought with all that hard work? The bad news is, you have added complexity to the code base. The good news is you are now ready to start implementing several of the patterns you wanted in the first place:

Test Driven Development - Breaking your dependencies allows you to really test isolated units of your code. You can start to write these tests before you write the code that makes them pass.
Inversion of Control - Speaking of breaking dependencies, injecting your dependencies makes it really easy to hand off object construction to an IoC container as well.
MVC - You probably already noticed that HandleSomeEvent() methods look an awful lot like ASP.NET MVC actions. And the fact that you already have ViewModels makes the MVC transition that much simpler. Using DI and an IoC container take you even closer.
Domain Driven Design - Pushing the business logic out of the UI is just the first step. Now you can start to push it out of the Application Layer and into your Domain Model where it belongs.
Acceptance Test Driven Development - When you have a classic WebForms app, where do you hook your FitNesse fixtures? You know the UI is the wrong answer because of the problems you had with WatiN, Watir, Selenium and other UI testing tools. Presenters introduce an Application Layer (or Service Layer) into your app that make ATDD not just possible, but actually pretty easy.

That's about it. MVP isn't a destination, it is just a step on the path to something better. The best part of the pattern is that it allows you to take small, iterative steps forward.

Premature Configurability Design Smell

2011-09-03T15:27:00.000-07:00

Premature Configurability is making some aspect of your application configurable (or data driven) before anyone has ever asked for a change to that part of the system.

This is a topic I have been contemplating for a while. I started writing this post at least 5 different times, but I was never satisfied with my results. Fortunately, Alex Papadimoulis of The Daily WTF recently presented on the topic at Code PaLOUsa and he said everything I wanted to say. He refers to the smell as Soft Coding. Please watch his presentation and read his post on the topic.

No More Ninjas

2011-08-30T21:26:00.001-07:00

Movie ninjas are awesome with the kicking, punching, jumping, etc. Code ninjas are unwelcome on my team.

Let's take a brief look at the characteristics of the ninja:

Ninjas have great skill
Ninjas work alone
Ninjas are stealthy
Ninjas use unorthodox tactics
Ninjas are specialists in espionage, sabotage and assassination

Great Skill - That sounds like what I want in members of my team, provided of course that it doesn't come with Great Arrogance.
Working Alone - Uh oh. No thanks. I want people who collaborate and act as a team. Paired programming for a large portion of the day is a must.
Stealthy - I really don't want anyone sneaking around in my code. I want clear names and explicit abstractions. Make your movements obvious. Create work that you are proud to sign (and then sign it on check in, not in comments.)
Unorthodox Tactics - I liken this to creating your own ORM or web framework. Sure, there may be advantages sometimes, but these are most often outweighed by the constant maintenance work required on the framework, not to mention the requirement that you train new developers not just in the domain, but also your nonstandard tools.
Espionage, Sabotage and Assassination - When I get into a code base that has been written by ninjas, I often feel like they must have been spies from a competitor come to sabotage the code. The code written by these ninjas is full of traps and tricks and kills productivity.

What I want on my team are Samurai. A Samurai follow a code of conduct that emphasizes the following:

Martial Arts Mastery
Loyalty
Frugality
Honor

Martial Arts Mastery - Skill mastery is definitely something desirable for team members. Like the Ninja, the Samurai focuses on constantly improving his already formidable skills.
Loyalty - Who doesn't want loyal team members? These are the guys who treat each other with respect and who will work together to complete the tasks at hand.
Frugality - With regard to code, I like to think of frugality in the terms of good architecture. This means minimizing the number of classes, methods and abstractions while still expressing all of the necessary concepts of the domain.
Honor - This means always doing your best. Do what is right for your team and your code even when it is hard. Write your tests first even when you're under a deadline. Remove duplication even when it's hard. Complete the highest priority tasks first, even if others seem more fun.

Anyway, please try to be less of a ninja and more of a samurai.

As for Rock Stars, if the perks of your job don't include an unlimited supply of illicit drugs and slutty groupies, you are not a rock star! KTHXBAI!

Agile 2011 - Day 4-5

2011-08-12T21:21:00.000-07:00

Thursday I went to WIP and Kaizen: Key Tools for Enabling Continuous Improvement: Michael DePaoli. It was a really interesting talk about how you need to make change slowly, incrementally and steadily to arrive at the organizational goal without causing a fight or flight reaction in your people. I enjoyed it though I expected it to be more about personal improvement for some reason.

I wasn't really excited about any of the late morning sessions, so I bailed and went to Coach's Corner to hang out with Tim Ottinger and ended up meeting Colin Jones from 8th Light and then talking with Matt Barcomb from LeanDog for nearly an hour.

Around noon, Evana Fredricko, my dance partner for Brian Marick's session on Tango, The Stance of Reaction, and Pair Programming arrived. We went out for a slice of pizza near the hotel, then returned for a very fun intro to tango and a great discussion on paired programming. A correlation was drawn between the way dance is taught and the way we should teach software practices: demonstrate, practice in isolation, then practice in the full context of dancing/working.

After thanking Evana for her time, I returned late to the hotel so I missed How Functional Programming Changes Developer Practices and went to The Fundamental Agile Apologetic: Tim Ottinger instead. I chatted with Tim and Rachael Davies about how the constraints of an average software project will lead you toward a set of practices similar to those of XP or other agile methodologies.

The Open Jam was pretty crowded so I wandered around the quiet halls until I found an ex-coworker. We talked shop and how things were going at his company. All too soon, the end-of-conference party started and I went around and said goodbye to my new friends and went home early.

Friday, Dave Brady carpooled to the conference with me. We both really enjoyed Kevlin Henney and Linda Rising's talks and spent some time talking to them after. From there, we went back to the Open Jam to hang out with GeePawHill, Tim Ottinger and Angela Harms. Tim and I left for a late lunch and I dropped him off at the airport.

I am now exhausted and yet completely energized. This was an amazing week full of learning and friendship.

Agile 2011 - Day 3

2011-08-11T21:10:00.000-07:00

I was too tired to post last night. So I am in the Coach's Corner doing the write up now.

The Plan:
Who even cares?

Actual:
I started the day in Agile isn't Enough: Jeremy Lightsmith. The key discussions were on:

What have you read besides books on agile that has helped your job?
A/B Testing
Paper Prototyping
Getting Things Done
Theory of Constraints Current Reality Tree

The item that was new to me was the Current Reality Tree. I am adding that to my queue of things to study.

The second session of the day was Flow Games: Karl Scotland, Eric Willeke. We played a game where we had to toss 20 balls around the group and the WIP and cycle time were tracked by the presenters. We were able to see the affects of our changes to the system and how we could shorten cycle time.

I had lunch at Squatter's with one of my closest friends and that was a great break in the middle of the day.

The first afternoon session was Tests as a Means of Abstraction: Brian Marick, Michael Feathers. This was an interesting talk in that Brian presented and Michael was the respondent. We got to see how Brian uses Midge to write tests in Clojure that don't rely on implementations only on behaviors of the data structures passed around. It was a nice example of TDD to do top down design and the test doubles (meta-constants) were a really interesting concept.

After that, I went to Courageous Curiosity: Agile from the Inside Out: Angela Harms. This was a very powerful and emotionally challenging session. After the crowd left, I was fortunate to get an additional 30 minutes with Angela and GeePawHill. Truly powerful conversations. I am glad that they are both people I trust so that I could really open up and share with them.

I needed to relax and decompress, so I went to Open Jam. There were some people just starting the getKanban game. It was a nice way to relax and also informative about the way that cycle time and WIP relate.

Wandering the expo was a fun way to run into some new friends. After a couple of laps I made my way over to Open Jam again where I was able to watch 3-way, big-screen-projector pairing on Smalltalk between Dave Brady, Pat Maddox and Johnny T. After a few minutes, Johnny split off and started teaching me the basics of Smalltalk. I'm more tempted than ever to go to the Utah Smalltalk User Group.

Dave and I drove home together (we're nearly neighbors) and had an awesome conversation about job satisfaction, business models, etc.

Agile 2011 - Day 2

2011-08-09T22:30:00.000-07:00

This is basically my 3rd day a the conference hotel and I am starting to feel it. I had to unfollow the Twitter hashtag because of information overload. Despite that, this is still exactly where I want to be.

The Plan:
Attend the following: keynote on positivity, "What we have learned so far" by Chet Hendrickson and Ron Jeffries, "Deliberate Discovery" by Liz Keogh and Pat Maddox, "It Depends on Context" by Ainsley Nies and Diana Larsen, "Getting Software Projects Done Right" by Bob Martin, "Industry Experts Panel," and "Dinner with a Stranger."

Actual:
The keynote on positivity by Barbara Fredrickson was very interesting. It seems very closely correlated with the work of Martin Seligman whose book "Learned Optimism" I have been reading. A quick search on google reveals that this correlation is not just in my head, but I am too tired to dig deeper tonight. I tried to pick up her book and ask her about the similarities, but the bookstore sold out, so I just went on to my next session.

Chet and Ron were hilarious. Their slides all used Comic Sans and had kittens on them. I suspect Ron did that to poke at the UX guys. Anyway, I wasn't surprised by what they said about the learning of the last ten years, but I did enjoy the presentation. I also stuck around to chat with Ron and thank him for pushing me out of my comfort and forcing me to think in our past Twitter discussion. I also received one of the gifts he brought to the conference. :)

At lunch, I met Mary Poppendieck and chatted briefly about flow and the construction of the Empire State Building. I also had a nice chat about agility at NASA and decided to attend the Atlassian party in the evening rather than the panel (I can't wait for my Angry Nerds tshirt.)

The session on Deliberate Discover was excellent. I can't tell you about the game we played, but you should find Liz and ask her when and where you can play it. The discussions we had made me start to ponder the decisions we make early in the development process and how many can we safely delay. It seems like we take away our own options far too early far to often. The chat with Pat was excellent. That man knows how to shake your hand!

Rather than the session on context, I opted for "Code Sense" by Micah Martin. It was interesting to see a bunch of different snippets and rate them. It was also fun after Bob showed up to hear his chuckles about the really bad stuff. I was starting to get worried because I rated almost every snippet as bad or terrible.

After that, the schedule completely fell apart (in a great way.) I sat and chatted with Tim Ottinger and Jeff Langr about FitNesse testing and team problems. Jeff gave me some insight into how he has seen teams use FitNesse and Tim gave me suggestions on better retrospectives and the value of single piece flow over time-boxed iterations.

At that point, I was hungry and luckily, Angela and GeePawHill were nearby and hungry as well. We went to the Little America lounge with a few people from DC and Gary Bernhardt. Dave Brady joined us after a while and we had some wonderful conversations. Gary told me (and Dave) to quit our jobs. Dave agreed that mine is holding me back from achieving my full potential, but neither of them offered me the magical replacement. Angela and I made plans to pair on some C# code before Friday.

Now I am exhausted and having a hard time keeping my eyes open to keep writing this post, so I think I must be done.

Agile 2011 - Day 1

2011-08-08T22:21:00.000-07:00

Holy shit! The internet isn't just a series of tubes, it's real! This may affect the way I interact in here... ;-) Anyway, I actually got to meet and shake hands with so many amazing people today including: Michael Feathers, Bob Martin, Angela Harms, Michael Hill, Tim Ottinger, Jeff Langr, Martin Fowler. My mind is nearly blown. There is so much talent and experience here I almost can't believe it.

The Plan:
Attend Refactoring in the 4th Dimension: Michael Feathers in the morning and The Transformation Priority Premise: Robert Martin in the afternoon.

Actual:
The Refactoring session was really interesting. Thinking about how your code base evolves as opposed to just looking at a point in time leads to some interesting metrics. A lot of research needs to be done in this area. Also, my Ruby skills are teh suck. I really need to practice and build a nice breakable toy.

Lunch was better than I expected and worth the wait. The highlight was a brief conversation with Angela Harms and Micheal Hill. I ate with a random attendee whose name I have forgotten.

The afternoon session with Uncle Bob was everything I expected. It was entertaining and educational I ended up pairing on the samples with the same guy I met at lunch. If you weren't able to make the session, it was a longer, hands-on version of his NDC 2011 talk.

After that we had there was a humorous and informative Q&A session with 15 of the original 17 authors of the manifesto.

The day ended with the Ice Breaker event with had amazing food and the opportunity to chat with several of the presenters I am so excited to see this week.

Agile 2011 - Day 0

2011-08-07T21:59:00.000-07:00

While there were no sessions, I think that the Agile 2011 conference technically started today. I was there anyway. Here is the report.

The Plan:
Head up to the Grand America for the 5:15 First Time Attendees session. Hang out until 7:00 then go over to the Zombie Walk.

Actual:
I went to SLC Airport to pick up Brian Marick and take him to the hotel at noon. He treated me to an excellent lunch at Squatters. I had the Black and Bleu burger which is at least as delicious as it sounds. While the food was great, the conversation was better. It was a wonderful opportunity for me to make the hang and learn directly from a well-known master. We spoke at length about software, languages, pets, programming jobs, XP, psychology and gift economies. It was an amazing lunch.
After dropping Brian off at his hotel, I didn't really have time to drive home and back before the 5:15 session, so I decided to wonder around the Grand America. Soon I was helping the volunteers sort shirts and prep welcome packets. After that, I went to the Agile Alliance lounge and hung out until the session.
I skipped the Zombie walk because I was missing Nikki and the kids and I know that, even as a local, I am going to be busy around the clock with the conference this week and I won't see them much. Spending time with them at the splash pad in The Ranches is more fun than hanging out with hipster zombies any day.

Current Status: Optimism and Ruby

2011-07-27T07:49:00.000-07:00

So I am reading this book: Learned Optimism. It isn't the usual tech fair, but it is full of scientific research rather than fluff, and the topic is something I need right now.

I went to the Salt Lake Ruby Brigade last night. Those guys are awesome. They only made fun me for using Windows once. ;-)

I should be studying Clojure so I am ready for Michael Feathers and Brian Marick's talk at Agile this year.

Not to mention prepping for my talk(s) at Utah Code Camp...

Inspiring Developers to Greatness

2011-06-29T14:42:00.000-07:00

How freaking pretentious is that title! And you thought my arrogance knew no bounds. Silly mortal.

Anyway, this is a question that I have been pondering, and asking, for a while. I wish there were a simple answer, but I also wish I could lose weight while continuing to eat like I do and never exercise.

What I have come up with so far are two factors that contribute greatly to the inspiration of developers, but do not actually guarantee anything.

First, you need to give developers some ability to control their destiny. Developers are naturally curious and creative people, so given a little freedom, they are likely to do something interesting. Or maybe they won't, but they will do something out of the ordinary and they will extend their way of thinking and that can only help their ability to do their jobs. [Thanks to Jason Staten for crystallizing this for me.]

The second common thread in these discussions is "where I work, we do..." The company culture of giving a crap about continual improvement seems to be a key ingredient. I know that before I worked with a team of excited developers, I just thought of this as a job. Their passion spread to me and I am trying to spread it to others. This is a pattern that I have heard over and over. (This usually, but not always, includes time to work on what you care about as part of your workday.)

Conversely, if you work in a culture of disinterest, you will either find your interest waning, or you will get frustrated and leave. Chad Fowler would tell you to just get out. I have applied this strategy a couple of times. It isn't worth your sanity or your passion to stick it out at a crappy, soul-sucking job.

Things like reading books on development, trying new languages, attending conferences, watching videos, going to user groups and participating in forums all keep the flames hot and help me continue on the path, but I don't know that any of them will get someone on the path. I have noticed that most of the dispassionate developers I know don't (and won't) do any of those things because they are third or fourth order ignorant. They don't even recognize the existence of the problem.

If you have any thoughts, suggestions, tips, tricks or money for me, please leave them in the comments.

Utah Ruby Users Group - First Impression

2011-06-29T11:03:00.000-07:00

So, last night I went to the URUG meeting. I have been dabbling in Ruby in the evenings for a while now and I decided it was time for a mentor. Dave Brady has been unwittingly filling that role, and in addition to telling me to go through the Ruby Koans, he suggested a little community involvement. I am thrilled that he did because it was the best user group I have attended.

It started off with the AA style My-name-is-and-I-have-been-doing-Ruby-for-X-years introductions. This was a nice change from the anonymous sea of faces at the .NET User Group.

We got right down to the business of blowing my mind with a presentation on EigenClasses. Basically, this seems to be a private class on the instance object that allows you to modify the instance without modifying all instances of the actual class. If I got that wrong, please flame the comments.

Next was Rack middleware. I drew a lot of analogies to FubuMVC. Again, flames in the comments, please.

I couldn't get wireless connectivity, and my Ubuntu VM crashed for the first time ever at about that point, so I just kind of watched the Goliath interactive presentation.

When the conversation moved to topics for which I had no context, I worked on the Koans. I actually finished them around 1:30 last night.

So, after the meeting wrapped up, the "Hall Track" started and we discussed SmallTalk, OO vs Procedural paradigms, how languages encourage certain styles of code, estimates, working in broken organizations, how to inspire/motivate developers, etc. Several of us ended up talking in the hall and the parking lot until around 11. I am pretty sure that, if the conversation had gone on all night, it would have stayed just as interesting.

Status Update: Videos for Great Good

2011-06-26T09:45:00.000-07:00

The NDC 2011 videos are available via torrent: http://thezendev.com/blog/ndc-2011-video-torrent (direct link). My download is still in progress, but the handful I have already watched are as excellent as the last 2 years, so I highly recommend them.

Also, I just downloaded and started watching the Structure and Interpretation of Computer Programs video series. Mind expansion in process. Updates as events warrant.

Not a video, but more like a video game: http://rubykoans.com/. I am determined to learn me some Ruby. I started last night and I'm about a third of the way through.

That is all for now.

Review: Apprenticeship Patterns

2011-06-18T12:08:00.000-07:00

We have been reading Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman as part of our Sequential Learning in the Utah Software Craftsmanship Group. The discussions have been excellent and have lead to greater understanding of the material, at least for me.

The explicit discussion of how to improve has been enlightening for me. There are many patterns that I am now or have in the past applied to my career. There are a few that are new to me. Many of the recommended Actions push me out of my comfort zone.

The assertion that there are not yet any Master Software Craftsmen came as a surprise. There are quite a few people whose works I follow who I have considered masters for a while. Either way, there is a lot of room for improvement all around, so I am excited to Rub Elbows with other aspiring craftsmen.

My favorite quote from the book was "Moreover, most programmers think they are above average. The sad reality is that, due to the skewed distribution of skill illustrated by the following chart, most programmers are actually below average." I know that this has applied to me at multiple points during my career and I assume it always will. That won't keep me from learning and trying and constantly improving though.

Interaction Tests with Mocks

2011-06-14T22:43:00.000-07:00

I seem to always be working on large, unwieldy WebForms apps. Because I am test infected, this means I often find myself refactoring large amounts of code out of code behind classes into Presenters a la Model-View-Presenter so that I can unit test the Application logic as the first step toward a proper Domain model, separation of concerns and, eventually, MVC. Because the only way to know that most of these pages is working is by looking at the UI, I use interaction style tests to verify that the UI is displaying the correct data. Mocks and Stubs become crucial elements of my tests. I used to use Rhino Mocks, but for nearly a year, I have been using Moq. Overall, I prefer Moq, though I don't have any specific reasons why.

Here is a (somewhat contrived) example of how I have been writing these tests using Rhino Mocks:


[Test]
public void HandlePageLoad_displays_client_full_name()
{
 var clientRepositoryMock = MockRepository.GenerateMock<IClienRepository>();
 var viewMock = MockRepository.GenerateMock<IView>();

 var client = new Client { FirstName = "First", LastName = "Last" };

 clientRepositoryMock.Stub(x => x.GetClientId(0)).IgnoreArguments().Return(client);
 viewMock.Expect(x => x.DisplayFullName("First Last"));

 new ClientPresenter(clientRepositoryMock , viewMock).HandlePageLoad();

 viewMock.VerifyAllExpectations();
}

Add a second test...


[Test]
public void HandlePageLoad_displays_client_phone()
{
 var clientRepositoryMock = MockRepository.GenerateMock<IClienRepository>();
 var viewMock = MockRepository.GenerateMock<IView>();

 var client = new Client { Phone = new PhoneNumber(800, 555, 1212, "00000") };

 clientRepositoryMock.Stub(x => x.GetClientId(0)).IgnoreArguments().Return(client);
 viewMock.Expect(x => x.DisplayPhoneNumber(client.Phone.ToString()));

 new ClientPresenter(clientRepositoryMock, viewMock).HandlePageLoad();

 viewMock.VerifyAllExpectations();
}

Of course, now I see duplication, so I want to refactor:


IClienRepository clientRepositoryMock;
IView viewMock;
ClientPresenter presenter;

[SetUp]
public void SetUp()
{
 clientRepositoryMock = MockRepository.GenerateMock<IClienRepository>();
 viewMock = MockRepository.GenerateMock<IView>();
 presenter = new ClientPresenter(clientRepositoryMock, viewMock);
}

[TearDown]
public void TearDown()
{
 viewMock.VerifyAllExpectations();
 clientRepositoryMock.VerifyAllExpectations();
}

[Test]
public void HandlePageLoad_displays_client_full_name()
{
 var client = new Client { FirstName = "First", LastName = "Last" };

 clientRepositoryMock.Stub(x => x.GetClientId(0)).IgnoreArguments().Return(client);
 viewMock.Expect(x => x.DisplayFullName("First Last"));

 presenter.HandlePageLoad();
}

[Test]
public void HandlePageLoad_displays_client_phone()
{
 var client = new Client { Phone = new PhoneNumber(800, 555, 1212, "00000") };

 clientRepositoryMock.Stub(x => x.GetClientId(0)).IgnoreArguments().Return(client);
 viewMock.Expect(x => x.DisplayPhoneNumber(client.Phone.ToString()));

 presenter.HandlePageLoad();
}

I might add a bunch of other tests after that, and they would be short and expressive like these two.

So I have taken that form and translated it directly in to my Moq use.


Mock<IClienRepository> clientRepositoryMock;
Mock<IView> viewMock;
ClientPresenter presenter;

[SetUp]
public void SetUp()
{
 clientRepositoryMock = new Mock<IClienRepository>();
 viewMock = new Mock<IView>();
 presenter = new ClientPresenter(clientRepositoryMock.Object, viewMock.Object);
}

[TearDown]
public void TearDown()
{
 viewMock.VerifyAll();
 clientRepositoryMock.VerifyAll();
}

[Test]
public void HandlePageLoad_displays_client_full_name()
{
 var client = new Client { FirstName = "First", LastName = "Last" };

 clientRepositoryMock.Setup(x => x.GetClientId(It.IsAny<int>())).Return(client);
 viewMock.Setup(x => x.DisplayFullName("First Last")).Verifiable();

 presenter.HandlePageLoad();
}

[Test]
public void HandlePageLoad_displays_client_phone()
{
 var client = new Client { Phone = new PhoneNumber(800, 555, 1212, "00000") };

 clientRepositoryMock.Setup(x => x.GetClientId(It.IsAny<int>())).Return(client);
 viewMock.Setup(x => x.DisplayPhoneNumber(client.Phone.ToString())).Verifiable();

 presenter.HandlePageLoad();
}

While pairing the other day, we started discussing that the intent of the TearDown method is to undo any setup what was put in place before the test, NOT to assert anything. The VerifyAll() call is effectively an assertion that the mocks were interacted with properly. This it what was recommended instead:


Mock<IClienRepository> clientRepositoryMock;
Mock<IView> viewMock;
ClientPresenter presenter;

[SetUp]
public void SetUp()
{
 clientRepositoryMock = new Mock<IClienRepository>();
 viewMock = new Mock<IView>();
 presenter = new ClientPresenter(clientRepositoryMock.Object, viewMock.Object);
}

[Test]
public void HandlePageLoad_displays_client_full_name()
{
 var client = new Client { FirstName = "First", LastName = "Last" };

 clientRepositoryMock.Setup(x => x.GetClientId(It.IsAny<int>())).Return(client);

 presenter.HandlePageLoad();

 viewMock.Verify(x => x.DisplayFullName("First Last"));
}

[Test]
public void HandlePageLoad_displays_client_phone()
{
 var client = new Client { Phone = new PhoneNumber(800, 555, 1212, "00000") };

 clientRepositoryMock.Setup(x => x.GetClientId(It.IsAny<int>())).Return(client);

 presenter.HandlePageLoad();

 viewMock.Verify(x => x.DisplayPhoneNumber(client.Phone.ToString()));
}

I have to admit that this is a much more Arrange-Act-Assert manner of writing tests with mock objects. It also seems to be the intent of the Moq library. I think my Playback-Record experience with early mocking tools was holding me back from seeing this way of writing my tests. I am going to try it for a while and report my experience...

Review: The Clean Coder

2011-05-31T08:44:00.000-07:00

TL;DR - If you care about software development at all, read this book now!

This book is a condensation and distillation of more than 40 years of industry experience. It is an amazing read. The book expresses the concept of professionalism in the clear, simple (not simplistic,) unapologetic style that Bob uses in all his writing. At a short 204 pages, you can read it in a weekend (like I did.)

Having been involved in Agile (XP, XPish, ScrumBut) projects for several years and recently in the software craftsmanship movement, many of the concepts in the book were familiar.

The chapters on Saying Yes, Saying No and Estimation really spoke to me. I have had many experiences where I have agreed to "try." Now I see the danger of that statement clearly. I have also had experiences where I have stayed firm on my estimates and been encouraged to feel as though I was not a committed team player. I now have additional tools to help me combat that feeling and take professional actions despite pressure (from management or the team) to do otherwise.

For me, the most powerful section of the whole book is the commitments section of the Chapter 10 - Estimates. "Professionals don't make commitments unless they know they can achieve them. It's really as simple as that." Wow. I have reread that section several times.

MicroTip: Searching

2011-05-06T20:35:00.000-07:00

Finding the correct code to edit is essential. Here are a few shortcuts to make that easier:

Ctrl+I => Incremental search. Just hit the keystroke and start typing. Your cursor will move to the next match.

Ctrl+F => You better know this one!

Ctrl+Shift+F => Find All.
F3 => Next match.

Ctrl+Shift+F7 => Highlight usages. Esc clears the highlight. Use it more than once is you will see it is a stack.

Alt+F7 => Find usages. Excellent for detecting the scope of a refactoring.

Practice these until they are burned into your fingers. I honestly had to execute the command and watch my fingers.

Ubuntu 11.04

2011-05-06T19:53:00.000-07:00

I updated yesterday. So far, so good. Well, mostly. The top 2 options in my boot menu don't actually work, they just load a black screen and I have to power off the machine and try again. But the next option works like a champ and I get some nifty new features. I hope to figure out what those are in the near future . . .

MicroTip: ReSharper Navigation

2011-05-05T22:17:00.000-07:00

I've read a couple times that the difference between the apprentice and the master performing a the same task isn't one big thing, it is many, many small things that together make a big difference. To that end, I am going to share the small things that help me work more efficiently under the title MicroTips. Here is the first of (hopefully) many:

ReSharper is a very powerful add-on for Visual Studio that improves the way one develops .NET code, but only if you know how to use it. (To see a ReSharper Jedi in action, go here.) One of the primary ways it improves one's ability to express thought in code is to eliminate the need to context switch from keyboard to mouse for navigation.

First of all, you need to configure the keyboard shortcuts. Do yourself a favor and learn the IntelliJ IDEA shortcuts now, because you will eventually find the Visual Studio flavored shortcuts are inefficient as they each require 2 keystrokes for common activities while the IDEA shortcuts only require 1.

Memorize and use (practice) these every time you need to navigate in your code:

Ctrl+N => Navigate to Type by Name. Learn to use the CamelHumps to save typing and time.
Ctrl+B => Navigate to Type under the cursor. This is the same as Ctrl+Click, but better.
Ctrl+Shift+B => Navigate to Derived Type (Implementation/Inheritor.) You will need this when properly coding to interfaces.
Ctrl+- => Navigate back to previous location.
Ctrl+F12 => Navigate to class member by Name.
Ctrl+Alt+L => Locate File in Solution Explorer. This one is useful when you need to move from the code behind to the markup in a web project. [Ctrl+Alt+L, Up Arrow, Enter]
Ctrl+Shift+N => Navigate to File by Name.

Thats it for this time. Just getting around in your code. If you can't live without your mouse, try unplugging it for an hour and see if you can't figure out how to navigate your code with your keyboard.

You’re not a software craftsman if…

2011-04-27T20:08:00.000-07:00

Software craftsmanship is the new fad to replace ALT.NET and Agile as the cool thing to do if you actually like writing software. This post is inspired by a recent post by Whitney Hess about UX designers.

There is a lot of debate about that software craftsmanship means. See my previous post so you can get started on your education.

YOU’RE NOT A SOFTWARE CRAFTSMAN IF…

You don't write code as a primary function of your job. Software craftsmanship is about crafting software. It isn't about being a manager, scrum master or (PowerPoint) architect. It's about creating code that helps people. If you are once involved directly in code, this doesn't count. A craftsman is involved in the craft, not a parallel/supporting craft.
You aren't reading. Blogs, books, magazines (really? do people still get magazines?) are great sources of collective experience. You can't learn do it all on your own, so a wise programmer (person) attempts to learn from the experience of others. Personally, I would say you need to read at least 1 book per quarter and subscribe to a few blogs as well. My RSS feed list is over to the right somewhere. I don't read all the posts of course, but I read a lost of them.
You aren't working to solve a business need. Coding is great fun! Code can be art. If you aren't concerned with RIO (and this includes schedule,) you are not respecting the craft or the client. Artesanal software is lovely. Save it for open source projects done on your own time. Don't make your client pay for art, unless they ask for art. 999 times out of 1000, they ask for features. (There should probably be more 9s there.)
You aren't participating in your community. There are plenty of ways to get involved. You can blog, tweet, go to user groups (.NET, Ruby) and contribute to open source. You need to be involved to be a craftsman. You can't work in isolation. If you don't have a user group in your area, create one at work. I have done this at my last few jobs and it is an amazing way to improve the quality and quantity of the output of your shop.
You aren't willing to learn from others. No one knows everything. Expose Your Ignorance isn't just for beginners. Almost everyone on your team knows more than you about something: (one of) the language(s), the domain, the data, something. Let them teach you. Seek out the knowledge they have. Paired programming is the easiest way I know to share knowledge amongst the developers on a team. Try it out.
You horde your knowledge or act superior when you share it. We all learned from someone and we all need to learn from others. Sure you have original thoughts, ideas, and solutions, but they are based on what you learned from others and you shouldn't keep them from your team. If you are a dick when you explain set-based logic or design patterns, etc., people will stop asking you questions. This will prevent you from sharing and succeeding as a craftsman.
You aren't improving your skills. Craftsmen value skill both in themselves and in others. Practice, practice, practice. Then you can produce finer work when it is time to produce. Find your weaknesses and do something to improve in those areas. My C# and TSQL are strong, but web-fu (CSS, JavaScript) is kinda weak and so is my PL/SQL. I'm working on 'em.
You aren't validating your code. For me this means automated tests both at the unit level and the acceptance level. For you this could mean manual regression after each feature. Actually, I think I would need to be convinced of the second option. You are in the business of automating work, but you do your own manually? Really? WTF? Automate that! We all know manual regression tests are boring and error prone.
You only know one technology stack. This one is hard for me because I am a .NET developer. I have been doing C# since it came out and VB6/ASP/Visual C++ before that. I have been on the Microsoft stack for almost my whole career. I know ASP.NET (WebForms & MVC), WinForms, WCF, SQLServer, IIS and Windows Server configuration. I don't know much about everything else. A craftsman needs to be able to compare and contrast more than one paradigm. I have been trying to learn Ruby (w/Rails) development on Ubuntu for a year+. I have read about half of Seven Languages in Seven Weeks and some of Rails for .NET Developers. It is hard to learn just for the sake of learning. The truth is you need to. Ruby has taught me better ways to C#. My JavaScript has improved once I learned what a prototype language is and (some of) how jQuery works.
You aren't passionate about code. When was the last time you were in an argument about what to name a variable? Software craftsmen care deeply about doing the right thing for the code and for the client. If this is just a way to pay the bills (and buy toys,) you are a laborer (code monkey.) If you aren't passionate, you aren't a craftsman.
You aren't regularly delivering value. This means releasing on a scheduled cycle. It should be a short cycle.
You don't take responsibility for your own education. It is awesome when employers provide training. If yours doesn't, you can't use that as an excuse to stagnate. Find a mentor. Be a mentor. You and you alone is responsible to ensure that you stay current and relevant in this industry. I have never seen an resume with an "Excuses for why I only know a dead technology" section. If I did, I might laugh, but I wouldn't hire the guy.

So, what would you add to this list? What would you take off?

I have written 3 previous versions of this article and thrown them all away because they didn't quite say what I meant. Hopefully this time it came together well.

What is a Software Craftsman?

2011-04-27T20:06:00.000-07:00

What is a craftsman? What is a Software Craftsman? There is a lot of debate. Educate yourself and make up your own mind...

This is a little old, but I wanted to make it available so that I could reference it in another post.

The Manifesto
The Software Craftsmanship Manifesto

The Book
Software Craftsmanship: The New Imperative

The Other Book
Apprenticeship Patterns - Guidance for the Aspiring Software Craftsman

Pete McBreen's Response to The Manifesto
Software Craftsmanship Revisited

David Harvey speaks to the topic
Danger! Software Craftsmen at Work

Dan North starts a war
Programming is not a craft

Liz Keogh explains her discomfort with the software craftsmanship manifesto
Why I didn’t sign the Software Craftsmanship manifesto

Gil Zilberfeld draws a comparison between software craftsmanship and alt.net
The Path Already Taken

Jason Gorman wants us to avoid getting hung up on labels
Enough With The Software Holy Wars!

Michael Feathers looks for more deliberate practice in our work
The Thing of Software Development

George Dinwiddie provides a physical example of why quality work is important to a customer, and how certification and licensing doesn't help
Trades, Crafts, and Certification

Martin Fowler summarizes and aggregates links
CraftmanshipAndTheCrevasse

Dan North expands and clarifies some his earlier points
On Craftsmanship

Bob Martin says software craftsmanship is only about programmers tired of writing crap
Software Craftsmanship: What it's all about.

Bob Martin thinks Martin Fowler's fears are groundless
Bringing Balance to the Force

Glenn Vanderburg clarifies Software Engineering
Real Software Engineering

Mark Haskamp...it's kinda related and I liked it, so just watch it OK? You made it this far for a reason, here is your reward.
Code is the Design

Ruby Inspired Sugary Syntactical Goodness for C#

2011-04-21T18:43:00.000-07:00

I have been playing with Ruby recently and it has lead me to want a couple of methods off of commonly used objects. I have found myself typing each and times into my VS editor regularly rather than curse my primary language, I decided that I should just implement the the missing functions. It is surprisingly easy to do. Here are some snippets for you to drop into a static class:


//Each & Times
public static void Each<T>(this IEnumerable<T> enumerable, Action<T> block)
{
 foreach (T item in enumerable)
 {
  block.Invoke(item);
 }
}

public static void Times(this int count, Action block)
{
 for (int i = 0; i < count; i++)
 {
  block.Invoke();
 }
}

public static void Times(this int count, Action<int> block)
{
 for (int i = 0; i < count; i++)
 {
  block.Invoke(i);
 }
}

The usage should be fairly straightforward, but just in case you need a pointer, here is some code I took from one of my Bowling Game Kata practice sessions:


21.Times(() => _game.Roll(0));
...
private void MultipleRolls(params int[] rolls)
{
 rolls.Each(x => _game.Roll(x));
}
...
5.Times(x => Console.Out.WriteLine("x = {0}", x));

Ok, so I faked the last one, but I think you get the picture. Let me know if you think this is useful and please post any similar tips that you use in your code.

UPDATE: I found some issues with the Each method. It works just find if you are using a concrete Enumerable. If you are using an Enumerable that is evaluated lazily like the results of Select, you will find that it cannot modify the content of your list because each time you enumerate, you will get new objects. I tried several options to resolve this, and they mostly turned the Each back into a Select, so I'm not sure about a clean solution for this one. If you call ToList() on your Enumberable before you call each, you might as well just use the ForEach() method on List(). Still pondering if there is value. Every solution I think of reduces the clarity of the code.

Review: Adrenaline Junkies and Template Zombies

2011-04-10T18:34:00.000-07:00

This is another book in the project management vein. I put it in my Amazon wish list about a year and a half ago, though I only recently got around to buying it. I had a manager strongly dissuade me from reading it based on title. Apparently, Zombies are not approved work fare. ;-)

On the one hand, this book was a fascinating read because so many of the patterns were familiar. Seeing that my experiences haven't been unique, but are often common enough that they have been identified and named was interesting to me. On the other hand, it was a little bit depressing because I had hoped that the industry was more mature than what I have experienced. Apparently, there is a lot of opportunity for improvement everywhere.

The idea of using patterns to describe software development project behaviors struck me as quite appropriate. Unfortunately, the book mostly just presents anecdotes and stories. The patterns all have catchy, if sometimes misleading, names and all have a distillation of the observations of the authors. They do not have any consistent presentation structure. Some patterns mention pros and cons. Some tell you when they should be applied. Some mention ways to implement them, while others just say what behaviors would destroy the pattern when it is already functioning. Maybe this is natural for a book on behavior patterns. In some way it feels unfinished, like the notes for a more detailed book to follow.

Despite the anecdotal feel to the pattern presentation, this was an enjoyable read. I wish I had read the book earlier, it might have helped me identify and then avoid or correct some problems I have seen on teams I've worked with. After a quick review of the pattern names and summaries, I believe I have observed every one of them in the wild. Some only lasted for short periods, while others were long-running.

This book will be of value to any managers/team leaders who are honestly seeking organizational improvement. Because of the natural proclivity humans have for pattern matching, being exposed to these patterns will help identify them when they occur. This, in turn, could facilitate guiding an organization or team away from the detrimental ones and toward the desirable ones.

Utah Code Camp

2011-03-22T19:50:00.000-07:00

Saturday I attended the Utah Code Camp. Despite my previous lack of interest, I decided that this time I would attend out of curiosity if nothing else. I have been invited before, but it never seemed like a good way to spend a Saturday. I have attended a few of the larger software conferences including SD Best Practices and SOA World/AJAX World as well as watching session videos from NDC and QCon. I wasn't really expecting much from a free, local conference.

Wow! I couldn't have been more wrong! Saturday was amazing! I attended 4 sessions that introduced me to new technology and 2 sessions on topics that I a quite passionate about already. All of the speakers were well prepared and interesting. The free lunch (provided by my employer: STG) was also nice. I didn't win any prizes, but I wasn't really that interested in them anyway.

Introduction to Erlang

I have been meaning to learn a little about functional programming for a while. I am reading 7 Languages in 7 Weeks partially for the exposure to functional programming. The fact that Milan Negovian flew in from out of state to provide us with some insight into the how and why of FP was awesome. I am inspired to dive deeper into this different paradigm and especially Erlang thanks to his excellent talk.

Android Development

This was another new technology for me. I love my Droid 2 and I got it partially because of the open platform, but honestly, I haven't seriously considered writing any software for it. Now that I have seen how easy it can be, I am going to take a hard look at doing something there. Thanks to Jacob Glines for the intro.

Software Craftsmanship

Obviously, this is a topic about which I am quite passionate. I enjoyed the solid introductory presentation by Mike Clement. The discussion afterward was quite enjoyable as well. I apologize to everyone if I talked too much. ;-) Anyway, I wasn't even aware we had a local software craftsmanship group, but I have already put the monthly meetings on my calendar, so I hope to see you all there next month!

What is FubuMVC?

I have followed Jeremy Miller on Code Better since I was first introduced to test driven development and the MVP pattern in ASP.NET several years ago. I have been aware of and interested in FubuMVC since its inception, but I haven't really researched it because I haven't had any opportunity to use it at work. I have been missing out. All of the rough spots in Microsoft's ASP.NET MVC are handled so much easier in FubuMVC. The lack of coupling to the framework is amazing. The conventions are elegant. I cannot wait to try this on a serious application. Thanks to Michael Murray did a great job presenting.

Distributed Systems

Jonathan Oliver is like an energetic version of Udi Dahan. I saw Udi speak on How to Avoid a Failed SOA at SD Best a few years ago. I have since been fascinated with the concept of building highly scalable distributed systems via pub/sub. I have worked hard to spread these ideas as a software architect and developer. Know I know who to call in for consulting when I need that outside voice of reason.

RIAs and Node.js

This was new to me. I went with Danny Coates who is the maintainer of Node Inspector perhaps hoping that some of his genius would transfer during the presentation. Unfortunately, I didn't really learn much about Node.js in the talk except that it is going in the queue of things to learn, but not moving to the front for now. It seems interesting as an alternative, but I am not ready to invest much. The website that Jeff Willden presented was pretty slick and the reuse of models from client to server was quite interesting, however.

This was an excellent day of learning and (re-)connecting with other Utah developers. I can't wait for the next one and I encourage you all to attend!

Object Oriented Design Resources

2011-03-20T09:41:00.001-07:00

I was recently asked where one might find some good resources on object oriented design. Since the internet is full of free resources on the topic, I thought it might be useful to point out the ones that have helped me most.

Let's start with the SOLID principles. Roy Osherove is kind enough to host a video of the talk Uncle Bob Martin gave at the Norwegian Developers Conference in 2009 describing these principles. Of course, you can always read the about the principles on Uncle Bob's blog. In addition to SOLID, Uncle Bob encourages us to create Clean Code.

Test Driven Development is a known technique for building consistently well designed of software systems. As Michael Feathers demonstrates, unit testing in an excellent way to expose the flaws in your design.

Of course, one needs some idea of where to start, so learning about domain driven design, design patterns and architectural patterns are all crucial.

Wrapper Classes

2011-03-15T18:24:00.000-07:00

A couple of the developers involved in our hiring process seem to be obsessed with the different wrapper patterns. That got me thinking about the differences between the Decorator, Adapter, Facade and Proxy patterns.

Here is a quick summary that compares and contrasts these four patterns:

The Decorator wraps a single class, exposes the same interface and adds functionality to the wrapped class which is injected into the Decorator.
The Adapter wraps a single class and changes its interface while maintaining functionality. Usually this is done to make the class easier to use in the consuming system.
The Facade wraps multiple classes and provides a simplified interface for using them together.
The Proxy wraps a single class and is similar to the Decorator in implementation, though it does not extend the functionality of the class, but hides an implementation detail such as network transport or lazy loading. The consumer shouldn't know it has a proxy rather than the real object.

This isn't a lot of detail and includes no implementation examples, but it is enough to get you through our interview phone if you can talk about about each of those logically.

Software Layers

2011-03-12T13:16:00.001-08:00

TL;DR: Please learn the currently accepted definitions terms so that you can use them correctly.

I am regularly amazed to see developers, whose primary job function is Applying Proper Names to Things, misapply new (to them) terms to well-known definitions. The most common example is probably calling your process agile whether or not it follows any of the principles. Who hasn't worked on a fixed bid, fixed scope, fixed date project and been told all along how "agile" the project is? The second you hear the phrase "scope creep," you know the customer isn't a priority and agile never made it to the table. While I am a huge proponent of XP (and I mean, by-the-book XP), I won't bore you with a rant on that topic.
What concerns me is Domain Driven Design. Domain Driven Design is a large subject that takes 100 pages to define quickly. I supposed this contributes to the misuse of the term.
Domain Driven Design defines 4 layers of an application: (User) Interface, Application, Domain, Infrastructure. Each of these layers contains business logic that is specific to a certain task. Each of these layers relies on the layers (plural!) below it.

The Interface is pretty simple to define. This is what is consumed by or visible to the user. It could be a rich desktop UI, a web site or a REST/WS-* service. The Interface layer uses the Application layer, Domain layer and Infrastructure layer to accomplish it's task.
The Application layer is the coordinator of what to how. This thin layer expresses the rules of what the users want the application to do (use cases) in terms of the Domain. The Application layer is unlikely to contain any "reusable" code that could be put in another application.
The Domain layer is where the invariants of the business are expressed. Entities, Value Objects and Services are part of this layer. This is likely to be a small nugget of solid gold in the heart of your application. This code has the most potential for reuse (if you believe in that kind of thing). The Domain should be Persistence Ignorant.
The Infrastructure layer provides supporting libraries and state persistence mechanisms for the other layers.

OK, so what is the bazillion foot view of DDD. So, if that is how DDD is defined, why do I keep seeing a much different structure in the actual code on "Domain Driven" projects? Is there some algorithm that I haven't been exposed to that reduces the 4 layers of DDD to the three layers: Presentation, Business and Data? These sound an awful lot like the tiers of an n-Tier app, but I am regularly assured that they are layers now that we have learned RPC doesn't scale.
What causes me the most heartburn is the lack of an Application layer in this model. Where do I encode use cases of this software? If they aren't easy to express in the Business classes, they seem to end up in the Presentation...or sometimes the Database.
The second thing that makes me uncomfortable is those Business classes. What purpose do they serve? Most often, they are placeholders for some future logic that we might discover someday but for now they just delegate directly to the Data layer. I will call your bluff on that one every single time. YAGNI and Dave Wheeler's famous quotation on indirection spring immediately to mind. I suppose could just be because I believe in the XP Value of Simplicity. Maybe it is because I have the Courage to change the software and it's architecture later if I find that it isn't meeting new needs. What ever it is, eliminate these pass-through classes and call the interface you really wanted to begin with.
In summary, please learn the definition of a term before you use it. Don't redefine the unfamiliar term to mean something you already know. Don't assume you understand a complex definition just because you have heard all the word in the term before.

Utah .NET User Group

2011-03-11T07:15:00.000-08:00

Last night I attended the local .NET User Group for the first time. The speaker presented on MEF. It was quite informative. I fulling intend to use MEF to support the plugin feature of the TFS build notifier I am working on.

It was fun to get the chance to talk to other .NET devs in the area, eat free pizza and hear about another tool for the toolbox. I am not really convinced that MEF is a full IoC container and I am wasn't thrilled that all the examples were in Silverlight, but the talk was well prepared and Joe McBride (@XamlCoder) knew what he was talking about enough to stand up to Q&A. :-)

I actually was picked for 2 of the door prizes, but I declined them both. I have been a die-hard ReSharper user for 4 years now, so CodeRush doesn't interest me in the slightest. I also haven't done a desktop app in years (just Web and Server side development) so I declined the Infragistics components so that someone who will actually use them can have them. It was funny how hard it was for them to give away CodeRush. I wasn't the only one who declined it. They asked what software we would want and I recommended dotTrace because (unlike ReSharper, dotCover and RubyMine) I haven't been able to justify the cost for my personal projects. ;-)

I fully intend to make attendance at this user group part of my monthly schedule. See you there next month!

CodeRetreat - Conway's Game of Life

2011-02-28T08:55:00.001-08:00

I wasn't able to justify a trip to Boulder for the CodeRetreat, but I wished I were there, so I watched JBrains virtual session video instead. That inspired me to implement Game of Life in C#. I created a GitHub repository and started test driving some code. Eventually, I got something working, but I have some more ideas I want to try. I want to add a World ctor that parses a string representing the initial state of the World. I would also like to try putting a few different UIs on this including an MVC3 + Knockout.js view and maybe a WPF view.

Here is what I learned:
Get a pairing partner. I started to get tired around 1130 and I got lazy with the testing. Now I need to go back and add tests and clean up some of the design that wasn't test driven.
Timebox things like this. CodeRetreat sessions ar 45 min. I realized I had been playing for hours when my wife asked if I was ever coming to bed.
Git is pretty frigging sweet. I'm just getting familiar with it, but I like this DVCS stuff so far.
Game of Life is an interesting problem. The wikipedia article is worth a read.

Review: The Cathedral & The Bazaar

2011-02-21T14:00:00.000-08:00

I read it, I liked it, Blogger ate my post.

First, it helped inspire me to try Linux, which is no mean feat for a die hard Windows guy like me. (I haven't even turned on my iMac in the last year.)

Second, the management essay added at the end was the most important part to me. The main point being that OSS works well because the participants self select and are passionate about that they are spending their precious time on. Cube dwelling devs may not be so passionate or skilled, and their output reflects that.

Review: The Passionate Programmer

2011-02-13T15:26:00.000-08:00

Chad Fowler's book is all about building a successful career in software development. When I read that sentence, 2 questions immediately come to mind: what's in it for me (as a developer)? and what's in it for me (as a business owner/manager/project manager/etc)? Well the answer to the first question is pretty obvious: what I get out of a successful career is happiness, money, purpose, etc. What does my employeer get out of it? Well, a happy, motivated, driven developer. Why does that matter? Happy, motivated people produce more and better work. So now we have covered the most rudimentary of why, let's look at how this book helps.

There are 5 sections in the book:

Choosing your market
Investing in your product
Executing
Marketing... not just for suits
Maintaining your edge

Choosing your market talks to the importance of being aware of what you do and how it related to the larger picture. Are you .NET developer? Why? Why aren't you a Ruby developer? Or a Java developer? Or a COBOL developer? Or a DBA? Did you make a conscious decision to go into this area or did it just happen? Are you in control of the direction of your career? Are you specialized? Will that help you or hurt you in the short term? Medium term? Long term? Make sure that you know what path you are on, why you are on it and how you will change if that path disappears.

Investing in your product is about improving in the areas you have chosen. Learn continuously from those around you. Help those you can. Read, study, practice.

Executing is make yourself indispensable (not because no one can do what you do, but because you are constantly bringing so much new value to the team/project.) Executing is also being honest: working hard and saying "No" when the answer really is "no."

Marketing is about managing perceptions because they really do matter. Make sure people around you know who you are, what you do and why that matters. Become a brand. Get your name known on not just in your company, but in the industry.

Maintaining your edge is a pretty obvious need. You have to always be improving because the industry is always moving and if you stand still, you will be left behind.

The 53 short essays in this book will help you focus on what you need to do to have an exceptional career that takes you where YOU want to go. I was pleasantly surprised at how many of the recommendations I am already following. I was also amazed at how much work I still have ahead of me. This book can be very useful in providing you with a direction and a starting point. Each essay has an Act On It section that gives you specific advice on how to improve your career right now.

Ubuntu...

2011-02-13T12:35:00.000-08:00

Well, after 10+ years of exclusively using Windows, I am now dual booting Win7 and Ubuntu on my laptop. So far, so good. Only complaint so far is that when I tried to install Ruby from the command shell, apt-get was out of date and as a noob to this platform, the error messages didn't make any sense. A quick google search and I had the answer: sudo apt-get update. Anyway, Ruby is installed. Vim is installed. Chrome is installed. I wrote this post in Chrome from Ubuntu. More to come.

Respect - The Currency of IT

2011-02-12T19:36:00.000-08:00

Just ready Jeff Ello's article The Unspoken Truth About Managing Geeks (thanks to Michael Feathers for tweeting it.) Jeff talks about the stereotypically negative behaviors of software developers and how organizations can deal effectively with these behaviors.

The part of the article that I found most interesting is the discussion of respect: how to earn it, how to keep it, how to lose it. I can attest to the fact that respect is the number one factor in my reactions to those I work with. I have worked with a team lead who was pushy, bossy, rude and consistently corrected my code and coding style (he even took away my mouse because it was a crutch.) Why did I put up with it? Well, he was an order of magnitude better than I was and I ~~wanted~~ needed to learn from him. I would go home from work mentally exhausted from paired programming, but at the end of several months, I felt like Neo in the training construct: I knew TDD. I knew how to separate concerns and used dependency injection and refactor bad code. I had never have learned so much so quickly in my previous 7 years as a professional coder. The best part was that as I began to actually understand the concepts, not just the forms, he listened to me and talk to me as a peer. I was gaining his respect. Had the company we worked for managed their finances better, I imagine I would still be working and following the lead of this great developer today.

Contrast that with another job where I worked for a team lead who had completely stagnated. He would quote from books that he studied at university 15 years earlier as though they were the final word on technology. He clung tightly to his outdated data and information. While a fun guy to hang out with, he never earned the respect of the team and, though regularly promoted, he has become completely irrelevant to the ongoing development efforts of the company. In large part, my departure from that company was due to the fact that I couldn't bring myself to respect the leadership team. They would regularly make deeply technical decisions for the teams for which they were completely unprepared (and counter to the advice of the expert developers on those teams.) The advice from on high was often illogical and sometimes contradictory.

All in all, the idea that technical prowess leads to respect and respect leads to effective cooperation rings very true to me. I feel as though reading this article has helped me more fully understand my own psyche and motivations in the workplace.

What Software Craftsmanship Means to Me

2011-02-07T18:49:00.000-08:00

Throughout the recent debate catalyzed by Dan North, I have spent a significant amount of time thinking about what this profession is that I have chosen to pursue and what it means to me. During the debate Corey Haines and Dan had on Twitter today, my thoughts crystallized and I felt compelled to record them. I doubt that many will read this, but if nothing else, it will allow me to measure my progress when I come back and reread it later.

While I self identify as a Software Craftsman, like Corey, I find that I agree with Dan regarding the movement. Maybe I agree with Dan because I self identify as a craftsman. No one else calls me a craftsman. There was no exam, no council of masters, just me and a desire to write less crappy software. So what does it all mean? What is Software Craftsmanship?

Well, it means not writing crap code, obviously! But what is crap code? I have never in the last 10 years worked with a developer who set out to write crap code. Working at a Fortune 100 company with annual releases, a team that laughed at the one guy doing unit testing and code that could fill hundreds of Daily WTF posts, we were all doing the best we knew how and trying to regularly (every single year!) produce value for our customers. Were we Software Craftsmen? I guess so. I mean, nothing in the manifesto would contradict that assertion.

So what is Software Craftsmanship? More importantly, what isn't Software Craftsmanship? I think the Ri answer is "Software Craftsmanship is doing the right thing." That isn't likely the Shu or Ha answer. Who knows what they are? I guess it depends, right? ;-)

I'm in no position to define this movement, but I will share my thoughts anyway. What else are blogs for, right?

First and foremost, Software Craftsmanship requires constant self improvement through study and practice. This includes learning from the experience of others (books, blogs, discussion groups, Twitter, etc.) and willingly sharing your knowledge and experience with those in the community, especially your coworkers.

Software Craftsmanship favors Clean Code (as defined by Robert Martin): concise, expressive code with limited duplication, (many) single responsibility classes and clear abstractions. Learn about and apply the correct design principles and patterns for your solution.

Software Craftsmanship insists on testable code with high levels of code coverage. This is more important than some grand design with perfect abstractions and encapsulation. Let the tests guide your design.

Software Craftsmanship emphasizes maintenance and enhancement of existing systems rather than regularly attempting to recreate what a business has already paid to build. It can take years for a new system to repay the high initial development investment. If we let it fall into disrepair and demand a rewrite just as the company breaks even, we are not adding business value, we are destroying it.

Software Craftsmanship favors Domain Driven Design rather than Data Driven Design or RAD. RAD tools emphasize the creation phase at the expense of the maintenance phase of a system's life cycle. Data Driven Design produces systems that are bound to a database implementation, generally less expressive of the intentions of the solution and likely run into performance and scalability limitations (vendor promises not withstanding.)

Software Craftsmanship prefers simple over configurable, Little Design Up Front over Big Design Up Front, flexible code over extensive frameworks.

Well crap! That looks like it could have been part of a manifesto for Alt.NET! Is Software Craftsmanship repeating the past? What have we learned that makes this time different? I don't know. All I know is that I have been trying to regularly and consistently improve my skills, share what I know and inspire those around me to improve so we can stop producing quite so much crap. Any advice on how to do that better is certainly welcome.

Review: Domain-Driven Design Quickly

2011-01-30T21:47:00.000-08:00

This book, available for free download on InfoQ.com, is an excellent intro to/summary of Evans' DDD book. What I really appreciate about this book is that at 104 pages it is short enough I can recommend it even to my near-illiterate developer friends who would never attempt to tackle Evans' 560 pages. ;-)
The definitions of the key terms in Domain Modeling are clear and concise. The examples are short and simple which forces them to cut straight to the heart of the concept they demonstrate.
While this book doesn't go as deep as Evans' book, it is excellent as a review or intro. I intend to have my entire team read through it asap during our ongoing training.
Key to Domain-Driven Design is the concept of the Ubiquitous Language. This book helps define the terms used in the Ubiquitous Language of software development. Communication is the key to success in our industry and having a common language facilitates quick, clear communication between developers. Read the book, learn the language, communicate more clearly, build better software.

Review: Facts and Fallacies of Software Engineering

2011-01-28T22:36:00.000-08:00

Robert Glass' Facts and Fallacies of Software Engineering was an interesting read because it focuses so much on the research that has been done in our field. Contrast that with the much more common anecdotal teaching style and this book becomes very valuable for the industry. Honestly, most of the facts are well known, they just may not be accepted as facts. This is a quick read and worthwhile. The emphasis on research and evidence alone is worthwhile.

Review: Software Craftsmanship

2011-01-28T22:16:00.001-08:00

I recently read Pete McBreen's Software Craftsmanship: The New Imperative. This was a pretty interesting book and it was excellent timing because I finished it just before Dan North published his post that set off an avalanche of debate about the topic.

What can I say... Hmm. After all the debate, I still consider myself to be a craftsman. Why? That is an interesting question. I think that there is misunderstanding about the movement. I think craftsmanship is all about building maintainable software and training the next generation of programmers to build maintainable software. As a professional, ROI is king. Everything I do, from personal study to TDD to CI to leading group discussions about the craft is so that my team can produce better, more maintainable software that produces long term business value. This is what makes me a craftsman. I have seen too many projects lose focus and become unmaintainable piles of crap. I have seen too many failed rewrites. I have seen too much money wasted by people who should know better.

The training aspect of craftsmanship alone intrigues me. When I think about the early part of my career, I get pissed off at the vast about of time I spent following blind alleys and being essentially undirected. I have to thank Ross and the guys at FARVV for getting me started in the right direction. I only wish I had received that kind of instruction much earlier.

There are a lot of other interesting points made in the book and in the follow up posts that responded to Dan. I think that anyone who considers himself a craftsman/tradesman/professional software engineer of any sort would be well served to be aware of the debate and why it is ongoing. The more we know, the better off our industry as a whole will operate.

Ok, so that wasn't a very focused review. I think you should read the book. Put it at the front of your reading queue.

Why I don't post on this blog

2010-12-30T22:54:00.000-08:00

When I started the blog, I thought I would share a lot of my experiences and thoughts about software development. After all, I am code obsessed. I read and think about code almost as much as I actually code.

What I have learned about myself is that I don't really have much desire to write about what I read and think about. The reason for this is simple: I feel it is all derivative. What I mean by that is that any serious developer has read read Clean Code, Pragmatic Programmer, Refactor, Refactoring to Pattern, Patterns of Enterprise Application Architecture, Agile Software Development, Service Oriented Architecture, SOA in Practice, Domain Driven Design, Applying Domain-Driven Design and Patterns, Head First Design Patterns, Facts and Fallacies of Software Engineering, Pro ASP.NET MVC Framework, Practices of an Agile Developer, the 97 Things books, etc, etc. He/she also probably follows blogs like Los Techies, DotNetKicks, Object Mentor, InfoQ, Joel on Software, Martin Fowler, Dan North, Ayende, Jeremy D Miller, etc, etc. And he/she undoubtedly attended or watched the session videos from conferences like SDBest or NDC.

Anyway, what I'm saying is that I think that most of my thoughts on software craftsmanship aren't new. They are all regurgitated wisdom of smarter people than me. With only 11 years in this craft, I'm just a journeyman with so much to learn. I advise you to follow some of the masters of our craft and only involve me if you are having an interesting conversation that I won't detract from too much. I do LOVE to talk about software development after all... ;-)

-DA

StructureMap

2009-05-10T01:06:00.000-07:00

I've been using a ServiceLocator class for IoC for the last year and a half. Never really got the point of the containers until the last week. We had a strange API requirement for a component for another group. I didn't agree with it, but basically, they wouldn't let us do constructor or setter injection of the dependencies. Let's not get into that, but lets just say that grabbing StructureMap 2.5 and throwing it into the mix saved me a ton of time. Also, I now get it. The container took what would have been 30-50 lines of ServiceLocator.cs and made it less than a dozen. And they were very clean and easy to read. And since you can initialize the objectfactory where ever you need to, I was still able to test those blocks and get a high level of coverage.

I have been using RhinoMocks since I first started TDD and I am pretty fond of it. The AutoMocker in StuctureMap has forced me to shift from the using(mocks.Record()){}... style to the Arrange-Act-Assert style. I'm comfortable with the other style, but I will admit that this would be easier to teach to beginners (provided you leave the AutoMocking out of it, of course!)

Anyway, I wonder now if I should spend a little time looking into Castle Windor and see which I prefer. . .

Training Materials...

2009-05-10T00:41:00.000-07:00

So after realizing that the 10,000 page book on ASP.NET is better as a reference than as a training guide (seems like someone said that several times before we started this book), we voted on whether to read Clean Code or Refactoring to Patterns next. Considering the make up of our team and the state of our code, I lobbied fairly hard to get Clean Code in front of everyone before we dive into patterns (again).

It seems that a lot of our more experienced developers are pretty resistant to reading Clean Code. I think there is a mentality that "the way I do it is right and there is no need to change or improve." I think that is pretty sad. I read Clean Code a few months ago, and it has helped me vastly. It is amazing how much more maintainable my code is now.

Anyway, I think that for my team (we have not quite a 3 to 1 ratio of juniors to seniors) we need to have a purpose to our refactoring. Making our code more readable and reducing our coupling seems like a pretty worthy purpose. I shudder at the thought of a couple of juniors pairing together and going pattern crazy on some code block that should be simple and straight forward. Don't get me wrong, I think that design patterns are a great idea. I look forward to reading Refactoring to Patterns when it comes up in my personal queue. I just prefer that our mentoring/training take a more methodical approach.

When I finally convinced my team to start using MVP, I had juniors come up to me and tell me that "this new pattern doesn't make my code any more testable at all!" When I looked at the implementations, they had usually done a Supervising Controller and but all of the business logic in the view. Go figure. When you implement the wrong pattern, or misunderstand the pattern, you don't see any of the benefits of the pattern. It seems likely to me that reading a patterns book is going to take us right down that path again.

Ah well, democracy worked and the correct book was selected.

Friends don't let friends leave code dirty

2009-02-06T18:27:00.000-08:00

So it turns out that I prefer writing code to writing about code, but I just finished reading Uncle Bob's "Clean Code: A Handbook of Agile Software Craftsmanship." I highly recommend it. This book very clearly addresses the large majority of the issues I face every day at work. Our environment is full of code that works, but was never finished. In other words, the code is a mess. I'm passing the book around work hoping that it will help spread the vision. Hopefully, we pick it up as one of our next training books for the whole team.

Software Design Speak

2008-11-10T21:12:00.000-08:00

I went to SD Best in Boston, and I have been thinking a lot about what made some of those sessions. While I continue to gather my thoughts about that experience, here is something to keep you entertained:

Often I say things to my coworkers about software design that are the result of a lot of research and time spent in contemplation. The problem is that I usually just give a 1 or 2 sentence summary of the idea and expect my coworkers to just get it. Or at least they could just assume I am right and we can move forward from there (too bad that doesn't ever happen).
I think that the biggest problem I have communicating my thoughts and ideas is one of nomenclature. We use a lot of terms that are heavily overloaded and can have a lot of definitions. I think it will help if I define some terms as I understand them based on my study. I have shared this with my coworkers and invited them to comment and add their own definitions. So far, there are no takers. I'm pretty sure none of them have even read it. I guess they would rather argue with me than speak a common language.

Anyway, here goes the Dictionary of Dave as well as what I think of as the more traditionalist approach to these topics.

Business Object
My Opinion - A business object is any representation of a business rule, requirement or concept as a code structure. Examples include: ThankYou page, Order object, RxDAO repository, etc.
What I think of as a more traditionalist view - A business object is a specific type of component that fits between the UI and the database. These objects have a lot of functionality like loading themselves from the data layer, saving themselves to the data layer, executing rules validation on themselves, etc. Basically, these are buffers that completely isolate the UI from the Database. They most often (if not always) instantiate the data layer object(s) that they need to perform persistence work. Examples include: most of the classes in the CTAC.Core namespace (not child namespaces), anything CSLA, most objects that I wrote between 2002 and 2006, etc.

Domain Object
Dave - A domain object is a specific type of business object that encapsulates a business concept. Often these are referred to as Entities when reading about code. They are composed of primitives and other Domain objects. They enforce rules related to the data they represent and provide a simple, yet specific (read type-safe) way to deal with that data. Examples include: Rx, Customer, etc.
Traditionalist - What's a Domain object? Did you mean data transfer object, cause we have plenty of those, if you need to push an instance of a business object somewhere over a wire or something.

Service (Module)
Dave - Well, this is a fairly simple and ubiquitous type of object. Basically, Services are any object that performs work on Domain objects. Common types of services are Repositories and Presenters. Since the Domain objects have no knowledge of persistence, UI or any other external component, the Services must perform these types of actions on the Domain objects. Services should always implement an interface to loosen the coupling, allow for mocking and facilitate inversion of control. Examples include: the SessionState wrapper, all the DAOs, etc.
Traditionalist - All of this functionality is encompassed by the business objects, so there isn't really a need for these Services of which you speak.

Service (SOA)
Dave - An SOA service is basically a business unit. It can be implemented using any type of design or architecture and doesn't need to share any of these decisions with its sister Services. It can have a separate data store of a different type than its sisters also. Basically, a service is an application or business silo that exposes part of its functionality to other parts of a company for their consumption. Because it owns the rules, logic, data, etc for the entire process, it can share its functionality by exposing web services, COM+, MSMQ or any other communication method. Examples include: the Email Sending Service and the Tax Service (I think).
Traditionalist - Well, this is easy! It is anything that has a web service, duh! The more the better! In fact, every single business object should have at least one web service that is somehow related to it. We should probably implement the Data Layer as web services too. That way, we can use those Data Transfer objects more. Yippee!

n-Tier Architecture
Dave - This is a step in the evolution of software development and it was a big one. Before this, everything was procedural or event driven and we didn't have a lot of structure. N-Tier gave us some structure and helped protect us from the retardedness of having data access in the UI or HTML generated in a stored procedure, etc. There are some problems, but every solution brings problems and overall, we were much better off than ever before.
Traditionalist - What do you think we have been talking about this whole time? N-Tier is the only way to make software. You have to have layers, just like an onion...or is it a cake? Anyway, the layers protect us and wrap us in warm goodness. Layers rule and we should try to have at least N of them.

Modular Architecture
Dave - This is the next step in evolution. The tiers were heavy and sometimes seemed contrived or difficult to work with. We had separation of layers, but we didn't really gain much by way of decoupling. In fact, we were often more coupled than before we adopted n-Tier because creating the UI objects automatically created business and data layer objects. The basic idea of the Modular software design is to create Domain objects and Services that are self contained and can be used independently. You don't restrict who has access to what; you just make sure that each piece does what it says it will do. When you need a thing, you grab that thing and use it (hopefully using the dependency injection pattern). This means that sometimes a UI component (like a Presenter) will have a reference to a Repository or some such. Under n-Tier, it was considered a huge rules violation for the UI to even have knowledge that a data layer (or data service under my definition), but under the modular design, there is no such restriction, so no problem. Components are loosely coupled and can be assembled as needed to create whatever components or features the business requires. No heavy infrastructure has to be created to make use of the components you need. Part of the advantage to this design is that you can create software vertically in slices rather than horizontally in layers (meaning that a feature can be implemented from UI to data as a single story). Because of the fact that every component is separate and loosely coupled, the components can be developed and tested independently. This allows for a more agile approach to development and results in software that is more maintainable.
Traditionalist - I'm not sure what you are even talking about here. N-Tier is the final evolution of software design. There is no need for anything beyond that.

Paired Programming - Who? What? When? Where? Why? and How? . . .

2008-10-19T18:18:00.001-07:00

Cheese Pairing for this Post: blue stilton
[ugh. much like the meeting, this cheese leaves me irritated and with a slight taste of vomit in my mouth that I can't seem to shake for the rest of the day]

So the other day at work, we had a meeting to discuss Paired Programming. The Outlook invite said something about "Improving Paired Programming," but from the time we started, it felt a lot more like "Bitching about Paired Programming." At one point, while we were listing a few things we like about it, one of our managers actually said, "Let's stop giving text book answers and talk about the real world." As I am a huge fan of the technique, I have to vent/rant a little and get my opinions out there.

What (is Paired Programming)?
Just so we are on the same page, allow me to assert some preconditions for the follow discussion. When I say paired programming, I am talking about 2 developers, 1 computer, 1 story/bug/issue to work on. I prefer to have 2 keyboards and 2 mice as well, but that is a matter of personal taste and I can understand why some people prefer to only have one of each. Anyway, that is it. That is all I am talking about. Two programmers, one driving, one navigating (when done properly) or sleeping (when not done properly).

Why (do Paired Programming)?
This is the big one, eh? For those of us who have been doing it for a while, it seems like a no brainer, but let's review for the heck of it.

Let's start with the reason that is least important. We have a business requirement that all production code be reviewed before going to QA and paired programming satisfies that requirement. I called this the least important reason why to do paired programming, but it is actually pretty significant. The alternative is that we perform code reviews after the code has been written. Scientific studies (I read a couple somewhere. . . .you have google, you find 'em) as well as lots of personal, anecdotal evidence prove to me that code reviews after the fact are a less effective way of preventing faults from reaching QA. Time is always a constraint during a review. How many minutes does it take to properly cover all the enhancements, refactorings and reasons behind them that went into 35 hours of work in the last week? And who wants to take that time when they have their own 35 hours of work to get done? If it compiles and passes the tests that the developer wrote for it, that has often been enough to pass any code reviews I have seen. And, since we already mentioned time constraints, if the review happens at the end of the cycle, and the reviewer(s) see an architectural or design flaw, do they mention it? Do you just let it go to get the feature out and add that to the technical debt pile? Do you throw it back to the developer, or another developer, to rework it for the next iteration? These types of issues are reduced when you have 2 sets of eyes on the thing throughout.
Two heads are better than one! I just touched on this a little, but let's face it; two developers looking at the same issue are going to come up with a better design/solution than one developer. If they see the solution differently, they can discuss it and come up with something better than either would have done alone. Even if they have the same solution, that at the least is confirmation that it is a workable one.
It is less likely that 2 people are going to break the rules than one alone. Let's be honest, how many times have you been under a deadline and, even though you know that you need to test, and you are totally committed to working test driven and then you hit up against some legacy code that is just not designed for testability, and you just say, "Screw it, I don't have time to do this right! Add it to the technical debt. QA will do integration testing on this anyway, right?" If your pair is sitting there, you will probably just man up and do it, right? Another flavor of this is coding standards. If your company uses one that isn't the same as you use at home, you may just slip into your own habits. A pair is going to say, "What are you doing?" before you get to the second private field without an underscore. I've tried, honest, but I'm just not feeling that underscore, guys.
This is a simple one, but important. That second set of eyes is going to notice your goofs quicker than you are. If you are really in the groove and you instantiate a CardProcessor where you needed a CartProcessor, a pair who is awake will take away the keyboard and call you a moron or at the very least ask you why you are doing it. Even when it isn't a logic flaw, but just something that the compiler or the tests will catch, it is still quicker to get it before that, eh?
Here is a BIG one: Training. None of us knows everything. I know, that hurts to hear, huh? Well, I said it so I think I may need a Vicodin. But let's face it, there are so many things to know from CSS, JQuery, ASP.NET, C#, T-SQL, TDD, not to mention the Domain itself, that having someone there who may have more experience in at least part of one of these areas can be a big benefit. The good thing about it is that you can just ask them right there and then you own the knowledge too. You don't have to go in search of that-one-guy-who-works-wierd-hours-and-lives-in-a-cave-and-drinks-too-much-Monster and admit to him that you don't know why the subprocessor written in assembly when you were 3 years old is returning a certain value when you pass it the following parameters. Your pair has that knowledge already. . . .or at least he has your back when you are in the C-monster's lair.

In summary, the whys include: Cause I said so!, Code Reviews Suck, 2 Big Brains > 1 Big Brain, Standards, You Can't Type, It's Not a Ubiquitous Language if Only One Person Speaks It.

How (should you Pair)?
There are lots of ways. Just do it comes to mind. Recommendations I have are as follows:

Change pairs often! Daily ought to be enough. Twice a day if you work 4-Tens (lucky jerk). This rule applies even when you are working on a multiday story. I would say even especially when it is a long story. I would put 2 guys on it on day 1, take one of those guys off on day 2 and replace him with someone else. On day 3, take the remaining guy from day 1 off and replace him. There are several advantages to this. Getting stale means getting sloppy. Bringing on the new guy means explaining what you did. This will probably happen pretty quickly. . . .Unless he asks you, "Uh, are you high? Why did you do it like that?" Then you get to hear his solution. Between where you were and where he thinks you should be, you may find a better solution. Good thing he showed up on day 2, rather than day 25, huh?
Also, change pairs often! You know that one guy you can't stand? Working with him all week could make you even crazier than you already are, eh? It is worth noting that you are that guy, at least to one member of your team.
Team Leads ought to select the pairs. Or at least be involved. The reason for this is that, given the option, we are most likely to just work with our friends every day. Let me tell you, that is fun. Also, it is fairly inefficient when it comes to knowledge transfer. Team leads ought to be making pairing assignments based on some overall plan for the team. Certain members may be weak in some areas and should be paired with those who are stronger in those areas to bring them up to speed. They also may chose to pair a couple of seniors together on particularly challenging issues, at least for the initial design. There may also be some constraints, such as one on our team that states that a pair may not consist entirely of contractors. Assigning the pairs will also cause more mixing and this can help the team members become closer and make communication easier and more open.
When pairing, the more knowledgeable member should be the one navigating and writing the tests. By having the guy who knows what is going on write the tests, he can make sure they are correct, and he can also explain to the other guy the why it needs to be done in a certain way. This means that you will be changing drivers often. Coder A writes a little test, Coder B writes a little code. Repeat. When you are of equal knowledge on the subject, just mix it up. A writes a test. B implements it. B writes the next test. A implements it. Repeat. By swapping drivers often, you make sure that you are both involved.
Ask Questions! This shouldn't even need to be said, but it does. Whether you are the junior pair, senior pair, new guy on the team, expert with 20 years experience, it doesn't matter. That guy sitting next to you knows something you don't. He may be using a hotkey you don't know, or possibly a design pattern you aren't familiar with. Big or small, he has some knowledge you need, and you need to ask him for it. Don't be afraid to ask for it.

In summary, the hows include: Change Pairs, Change Drivers, Ask Questions.

When (should you Pair)?
This depends on your environment. I say, as much as possible. At the very least, for everything that is going into production. For us, we start pairing right after Morning Standup and pair until the end of the day. Since this is about 7 hours for us, that means only 35 hours a week of pairing. I heard some of the guys whining about how they never get a chance to do any personal research on the domain, tools, etc, and I gotta say, that is pretty weak, 'cause we really are supposed to work 40+ hours a week. Since all of our meetings fall inside the pairing hours, it seems like there are at least 5 hours a week when you could be doing personal research, or writing more tests (as long as you aren't writing any production code), or asking questions, or whatever. Do you need a list of things to research that you may not be an expert on? Start here: .NET 3.5 framework, ASP.NET, Ajax, JQuery, CSS, C#, TSQL, NAnt, CruiseControl.NET, TDD, NUnit, RhinoMocks, WatiN, ReSharper (and its plugins), TFS, Better source control than TFS (why can't we all just use SVN?), GoF Patterns, Patterns of Enterprise Architecture, Inversion of Control and the Dependency Injection Pattern, .NET MVC framework, Linq, MFP, MFC, MVP, Our Domain. If you are an expert on all that, you are hired 'cause we don't have one on staff. On second thought, you are not hired, cause you are lying. And if you aren't lying, and you really are an expert on all that, we can't afford you. Anyway, there is a lot to learn and you don't need to pair to do it.

Where (should you Pair)?
I think you ought to pair in the same room with the rest of the team. This allows for easier communication and greater camaraderie. You know how you don't know everything? (Sorry to bring that up again) Well, your pairing partner doesn't either, so it might help if you don't have to go trekking around to find the guy who does. I know that this doesn't work in every environment, but if you can do it, I think you should.

Who (should Pair)?

Simple. Everyone who is working on production code.
Teams who want to make high quality software quickly, with few defects.
Also, everyone who wants to learn from another member of the team.
Anyone who thinks they know something worth teaching to another member of the team.
Umm, if you aren't in one of those categories, do you even have source code access? Please say no.

Summary
Paired programming is an excellent methodology if you want to create a software package that is maintainable. Done right, it enhances the quality and the velocity of software development.

Well, there's my ten cents, my two cents is free. . .

Sorry. If you made it this far, you didn't deserve an Eminem quote. I really do apologize.

Live Templates . . .

2008-10-08T06:00:00.000-07:00

Cheese Pairing for this Post: Beecher's One-Year Aged Flagship Cheddar
[mmm. that's tasty]

Live templates in ReSharper are an excellent time saving tool. They allow you to put code that you use over and over into a shortcut that you don't have to retype it all the time or maintain it in files external to Visual Studio.

I have a few that I've created to make my life easier.

test

[Test]
public void $TESTNAME$()
{
 $END$
}

rhino

[Test]
public void $TESTNAME$()
{
 $END$
 using(mocks.Record())
 {
  
 }
 using(mocks.Playback())
 {
  
 }
}

tostring


public override string ToString()
{
  MemoryStream memoryStream = new MemoryStream();
  XmlSerializer xmlSerializer = new XmlSerializer(GetType());
  XmlTextWriter xmlTextWriter = new XmlTextWriter(memoryStream, Encoding.UTF7)
                                    {
                                        Formatting = Formatting.Indented,
                                        Indentation = 1,
                                        IndentChar = '\t'
                                    };
  xmlSerializer.Serialize(xmlTextWriter, this);
  memoryStream = (MemoryStream) xmlTextWriter.BaseStream;
  UTF7Encoding encoding = new UTF7Encoding();
  return encoding.GetString(memoryStream.ToArray()).Replace("><", ">\r\n<");
}

This last one works great for figuring out where the differences are when you get an expectation error in one of your tests. Just throw that XML string from the test output into WinMerge and done. Also, I would like to point out for anyone who isn't aware, there is a hotkey in R# to automatically implement IEquatable and override Equals: Alt+Ins, E. Brilliant stuff. The only issue is that you need to update it (Alt+Ins, E will do that too) every time you change your object. That helps with those stubborn objects that tend to get compared by reference when you want to just compare their values.

Sorry about the delay on this post. Apparently, my blog was flagged as spam for a while. All is better not though.

ReSharper Code Cleanup . . .

2008-10-06T06:00:00.000-07:00

Cheese Pairing for this Post: Jarlsberg
[my favorite emmentaler; jarlsberg is excellent for snacking or sandwiches]

ReSharper will automatically clean and organize your code for you according to your specifications. The default specs are great; however, I find that I like to put my methods, field, etc in a slightly different order. Here is the config that I use. The only enhancement I still want to add is sorting auto properties before properties that have a backing member rather than intermixed. I haven't figured out how to accomplish that yet, so if anyone knows, please post the answer in the comments, thanks.

Without further ado:


<?xml version="1.0" encoding="utf-8" ?>
<Patterns xmlns="urn:shemas-jetbrains-com:member-reordering-patterns">
<!--Do not reorder COM interfaces-->
<Pattern><Match><And Weight="100"><Kind Is="interface"/><HasAttribute CLRName="System.Runtime.InteropServices.InterfaceTypeAttribute"/></And></Match></Pattern>
<!--Special formatting of NUnit test fixture-->
<Pattern RemoveAllRegions="true"><Match><And Weight="100"><Kind Is="class"/><HasAttribute CLRName="NUnit.Framework.TestFixtureAttribute" Inherit="true"/></And></Match>
<!--Setup/Teardow-->
<Entry><Match><And><Kind Is="method"/><Or><HasAttribute CLRName="NUnit.Framework.SetUpAttribute" Inherit="true"/><HasAttribute CLRName="NUnit.Framework.TearDownAttribute" Inherit="true"/><HasAttribute CLRName="NUnit.Framework.FixtureSetUpAttribute" Inherit="true"/><HasAttribute CLRName="NUnit.Framework.FixtureTearDownAttribute" Inherit="true"/></Or></And></Match></Entry>
<!--All other members-->
<Entry/>
<!--Test methods-->
<Entry><Match><And Weight="100"><Kind Is="method"/><HasAttribute CLRName="NUnit.Framework.TestAttribute" Inherit="false"/></And></Match><Sort><Name/></Sort></Entry></Pattern>
<!--Default pattern-->
<Pattern RemoveAllRegions="true">
<!--delegate-->
<Entry><Match><And Weight="100"><Access Is="public"/><Kind Is="delegate"/></And></Match><Sort><Access Order="public protected internal private" /><Name/></Sort></Entry>
<!--enums-->
<Entry><Match><Kind Is="enum"/></Match><Sort><Access Order="public protected internal private" /><Name/></Sort></Entry>
<!--constants-->
<Entry><Match><Kind Is="constant"/></Match><Sort><Access Order="public protected internal private" /><Name/></Sort></Entry>
<!--static and readonly fields-->
<Entry><Match><And><Kind Is="field"/><Or><Static/><Readonly/></Or></And></Match><Sort><Access Order="public protected internal private" /><Name/></Sort></Entry>
<!--fields-->
<Entry><Match><Kind Is="field"/></Match><Sort><Access Order="public protected internal private" /><Name/></Sort></Entry>
<!--Constructors. Place static one first-->
<Entry><Match><Kind Is="constructor"/></Match><Sort><Static/><Access Order="public protected internal private" /></Sort></Entry>
<!--Destructors. Place static one first-->
<Entry><Match><Kind Is="destructor"/></Match><Sort><Static/><Access Order="public protected internal private" /></Sort></Entry>
<!--Instance indexers-->
<Entry><Match><And><Kind Is="indexer"/><Not><Static/></Not></And></Match><Sort><Access Order="public protected internal private" /><Abstract/><Virtual/><Override/><Name/></Sort></Entry>
<!--instance properties-->
<Entry><Match><And><Kind Is="property"/><Not><Static/></Not><Not><Kind Is="indexer"/></Not></And></Match><Sort><Access Order="public protected internal private" /><Abstract/><Virtual/><Override/><Name/></Sort></Entry>
<!--Methods-->
<Entry><Match><And><Kind Is="method"/><Not><Static/></Not><Not><HandlesEvent /></Not><Not><Kind Is="destructor"/></Not></And></Match><Sort><Access Order="public protected internal private" /><Abstract/><Virtual/><Override/><Name/></Sort></Entry>
<!--Event Handling-->
<Entry><Match><HandlesEvent /></Match><Sort><Access Order="public protected internal private" /><Abstract/><Virtual/><Override/><Name/></Sort></Entry>
<!-- event -->
<Entry><Match><Kind Is="event"/></Match><Sort><Access Order="public protected internal private" /><Name/></Sort></Entry>
<!-- operator -->
<Entry><Match><Kind Is="operator"/></Match><Sort><Access Order="public protected internal private" /><Name/></Sort></Entry>
<!--Class indexers-->
<Entry><Match><And><Kind Is="indexer"/><Static/></And></Match><Sort><Access Order="public protected internal private" /><Abstract/><Virtual/><Override/><Name/></Sort></Entry>
<!--Class properties-->
<Entry><Match><And><Kind Is="property"/><Static/></And></Match><Sort><Access Order="public protected internal private" /><Abstract/><Virtual/><Override/><Name/></Sort></Entry>
<!--Class Methods-->
<Entry><Match><And><Kind Is="method"/><Static/></And></Match><Sort><Access Order="public protected internal private" /><Abstract/><Virtual/><Override/><Name/></Sort></Entry>
<!--all other members-->
<Entry><Sort><Access Order="public protected internal private" /><Abstract/><Virtual/><Override/><Name/></Sort></Entry>
<!--nested types-->
<Entry><Match><Kind Is="type"/></Match><Sort><Name/></Sort></Entry></Pattern>
</Patterns>

Qualities of a Good Unit Test . . .

2008-10-02T06:00:00.001-07:00

Cheese Pairing for this Post: smoked gouda
[this is something great for every day consumption; try some on toast]

So I was looking through some of the documents I have used for presentations in the office and I thought this was an interesting one:

Atomic

A unit test should only test a small piece of functionality.

A litmus test is to ask if any part of the unit test could stand alone in a separate unit test.

Another feedback loop for your unit testing quality is the amount of time you spend with the debugger. If your unit tests are coarse, a test failure is more difficult to find. If the unit test exercises a small amount of code, the test failure cause can usually be spotted very quickly.

Order Independent & Isolated
There should never be an order dependency, intentional or not, between unit tests.

Problems arise when one unit test leaves some kind of dirty data lying around. Testing against a database or some sort of static cache is a common culprit.

Put evil, stateful things behind nice, deterministic mocks or stubs.

Intention Revealing

A unit test can, and should, be a valuable form of documentation.

Unit tests are part of the contract that software implements.

A unit test provides a sample of the expected usage of the code.

Excessive data setup can obfuscate a unit test beyond any hope of comprehension.

Easy to Setup
How easily can I set up an environment to run the tests? If the answer is "not very," I might never get the tests running.
As much as possible, decouple unit tests from external dependencies like databases and web services by using mocks or stubs. When you do test against an external dependency, the dependency better be setup correctly by the automated build.

Transactions . . .

2008-09-26T12:37:00.000-07:00

Cheese Pairing for this Post: 1-year-old, Cave-Aged Gruyere
[this is a great one that you can really enjoy every once in a while under the right circumstances]

So, this week a user story was assigned to me that said something like, "Make sure that we don't save and of the Order data if we can't save ALL the Order data." Immediately, I thought, "Sounds like time to add some transactional support to our (custom) repositories." So there I am adding some tests to the repositories solution that assert that I have some infrastructure in place to track all of the database connections, etc, when one of my co-workers says, "Why don't you just use TransactionScope?" This was new to me, so here is what I learned:

TransactionScope is a class built on the Microsoft Distributed Transaction Coordinator. It basically wraps up all that hard work of tracking and committing or rolling back transactions across multiple connections into an easy to use interface, like so:


void MethodWithTransaction()
{
    using(TransactionScope scope = new TransactionScope())
    {
        /* Perform transactional work here */
        scope.Complete();
    }
}

That's it. If you get to scope.Complete(), the transaction(s) commit. If you don't get there, the whole thing rolls back when the TransactionScope is disposed.

Ok, you knew that wasn't all there is to it right? You have to configure your SQL Servers to run the DTC components. I didn't do this as our OPS team already had it done. I did have to do some config on my machine though. Here are the steps:

Run dcomcnfg:

Right-click My Computer and open up the properties. Go to the MSDTC tab:

Click the Security Configuration button:

Those are the setting that work for me. I also had trouble with the firewall we used here at work, but our networking guys were able to resolve that as soon as I mentioned DTC.

In the (likely) event that you need more info, try these links:

Troubleshooting Problems with MSDTC

How To Use DTCTester Tool

Good Luck!

Getting started . . .

2008-09-26T12:28:00.001-07:00

OK, now that that is out of the way, lets talk about code.

I work in C# using Visual Studio.NET 2008 w/ReSharper. After working with ReSharper for the last year, I honestly can't imagine working without it, hence the inclusion as part of my IDE. Why don't I throw some buzzwords at you and then try to justify them: DDD, TDD, Agile, XP, IoC, RhinoMocks, nUnit, WatiN, Patterns, Patterns, Patterns... The list could go on. Years ago, I would have defined myself (as a coder) using the names of technologies (XML, HTML, T-SQL). Now I talk more about tools and methods than technologies.

I mostly work in ASP.NET targeting the .NET 3.5 framework these days at work, though at home, in my free time, I tend to be more desktop focused.

Well, this isn't a resume, now is it? I should just talk about the things that really interest me...

Setting the mood . . .

2008-09-26T12:12:00.001-07:00

I work in a shop that practices paired programming on all production code. While I quite enjoy this style and encourage it, I occasionally feel the need to check out from the team and get into a coding zone of my own. I find that heavy metal and punk rock help set up the correct mood for me fairly well. Here is the Pandora station I generally listen to: Code Machine.