PhatBoyG.com

I came up with this a month or two ago, but finally decided to share it. While working on Mass Transit, I was joking with Dru Sellers about how nice it was to have really good test coverage when making design changes to some all-new development code. I’ve had very limited opportunity for a completely new projected started purely from unit tests, so I was just impressed at how easy it was to make code changes knowing that a passing set of tests meant all was well in the world.

You see, not all parking lots are paved with quality asphalt, generally flat, and void of any obstructions like islands and lights (see my other hobby). At work, our application is a lot of vintage C++ code, a ton of stored procedures packed to the hilt with domain logic, and nearly zero percent unit test coverage. Since adapting agile development, it is something that has been missing from our process. In our latest iteration, we’ve started using unit tests (with NUnit) to design our interfaces and classes. At the same time, we’re integrating Mass Transit to support the loosely coupled layer of application services (which include object translation, communication with high-latency remote systems, and lazy auditing of transactions). Aside from a few basic web services to support remote client application support tools, this is the first C#/.NET development that is being done as part of the main application.

So back to our story, my first project with really good test coverage exposed me to a lot of new things. From a TDD perspective, I’d read about it, used it to build some basic tests for various classes, and thought I had a pretty decent understanding of it. In this new project, I also learned how to use Rhino.Mocks (which took the test run time from 40-50 seconds down to 1.83 seconds on average), a very powerful tool for making an interface behave as you would expect an implementation of that interface to behave. The use of mocks has really helped me focus on actually writing tests and building a single class at a time. Prior to using mocks I would jump around creating additional classes as I defined new interfaces just to be able to continue writing my unit tests on the original class. By using a mock, I’m able to simulate the behavior of the other class without losing focus.

As my appreciation for TDD grew, I jokingly dropped a slogan into a chat window (using Skype, of course, aren’t you?):

I got a few chuckles, and thought it would make a great t-shirt to wear to tech events like code camps. So I threw together a quick online store so that I could order one for myself. I showed it to a few others (like Joe Ocampo, who suggested the slightly less offensive, yet subtly more suggestive variant) and decided to make it available to anyone that wanted one. So if you like it, grab one for yourself and maybe I’ll see you wearing it at ALT.NET Seattle!

It seems the MVC (model-view-controller) framework being added to ASP.NET has been released as a CTP.

There are a ton of posts about how to use the MVC, including a great series on Scott Gu’s Blog.

There, now I’m one of the thousands who probably blogged this today.

I’m trying to let the events that transpired at the ALT.NET conversations this past week since into my brain. It was a healthy discussion, packed with TDD, BDD, DDD, and MVC.

The format of the event was amazing, and not just because people kept talking when I approached a group (they usually become mute, chuckle, or outright laugh). Open Spaces offers an equal playing field to everyone in attendance — there are no presenters, no PowerPoint presentations packed with propaganda. Anyone can convene a conversation on topics related to the event subject matter. When conversations begin, everyone is encourages to contribute and learn.

The format was empowering and everyone was comfortable talking with others at the event — even those they didn’t know. I spoke with many people I had never met and was pleased to find that I wasn’t the only agile novice present. While I spent a lot of time learning and using tools like Subversion, NAnt, CruiseControl.NET, and NUnit, that barely scratches the surface. Yes, continuous integration has been a huge improvement to our development process, and yes, Subversion is an amazing source control system, but that is a tool-only solution. I like to think of these things as easy-entry or low-hanging-fruit on the ALT.NET path.

The real pain alleviation is TDD and Agile. I was somewhat surprised talking to other attendees working in large enterprises that were completely agile. I’ve spent a lot of time thinking how we could evolve into an agile team and the first step is a big one. I’m sure I’ll take a lot of ideas and knowledge that I learned at the event and use it to help plan agile adoption in our team. In a large enterprise, there are a lot of regulatory issues that can limit how deep agile processes can go but those limitations are disappearing as companies learn to adapt and push the boundaries of rules put in place by legislation to protect investors.

As far as coverage of all the topics, there have been many play-by-play posts on the discussions so I’m not going to go too far into detail on each one I attended. I bounced between several sessions, choosing to catch different parts of each session to gather as much knowledge as possible. A few of the sessions seemed to get off track, particularly the ones that spent more time discussing what ALT.NET is rather than the things ALT.NET does. I’m sure there will be more of the is over the next few weeks as the community refines the message. I’m really interested in how those in attendance will take what they learned and share it with their local communities.

Imagine a system with a large amount of C++ and Classic ASP code. The ASP code handles the presentation of data only, making calls into C++ COM objects when data or logic functions are required. In order to take advantage of the huge productivity gains, new code is written in C# and .NET 2.0 when possible.

One of the challenges in adding .NET code to an existing C++/COM application is calling infrastructure components from the new .NET code. Interop can be used, however, this can drastically impact the design of the new code by forcing coding decisions to match outdated idioms. By replacing the old code with new .NET bits, the model and services built in .NET can be more appropriately structured using solid design methods (DDD is my preferred choice in this area).

At ALT.NET, we had a conversation about testing legacy code. The quick response was, “Read Feathers.” The book, Working Effectively with Legacy Code covers a lot of integration topics about legacy code, particularly C++. I plan to pick up a copy in the near future. But the discussion continued and I made a few realizations on how to approach the problem of migrating legacy code to .NET.

When examining a legacy component, don’t focus on the methods in the interface. With a Test-Driven Development approach, the client comes first. Therefore, the new .NET project is written to the point where the legacy dependency is needed. Once a dependency is identified, create tests to call a new interface providing the services of the legacy component. Once the interface methods are defined (from the viewpoint of the caller, not the legacy component), create a proxy class that implements the new interface but using the existing COM component for the implementation.

At this point a new interface, proxy class, and set of tests that exercise the methods have been created. Using the newly created tests, verify that the new interface works as designed. For systems that need to retain the legacy code for other application purposes, the work is done. There is no duplication of code and the new projects are not limited by the design of the legacy components.

However, if the goal is to replace the legacy component, the tests can be used to validate a new implementation. Build a new class in C# and implement the new interface in .NET code. The tests created for the proxy class can be used to verify the implementation in the new class. Once the dependencies on the legacy component are eliminated, the legacy component itself can be removed. If the dependencies on the legacy code cannot be removed, reconsider the decision to duplicate the implementation.

In some cases, it may be desirable to replace a legacy interface with the new implementation. While it is possible to create a class in .NET that implements an IDL-defined interface, there are some gotchas that need to be addressed.

An app.config file will need to exist for every application that used the legacy component. In the case of an ASP application, this means an inetinfo.exe.config or w3wp.exe file we need to exist in the inetsrv folder under /windows/system32. This can result in problems where the server is being shared with other ASP applications.

The new assemblies will need to be registered with regasm using the /codebase parameter. This means the assembly and all of the dependent assemblies will need to be strong named. By registering the assembly with this method, the assembly does not have to be installed in the GAC (which is pure evil IMHO).

The new class must have a ComDefaultInterface attribute and must not have a ClassInterfaceType attribute. The IDL-defined interface dictates the type (dual/custom) of calls supported.

I have personally used this method to transition code from legacy ASP/COM to ASP.NET and C#. It would be wise to note that legacy interop is not easy and it is not perfect. There are a number of gotchas along the way. My only other recommendation is to test early, test often, and stick to implementing only what the client (calling application) needs to function.

Some seriously fried software developers:

Me and Dru Sellers on Sunday morning. I met Dru before the event on Friday and having only read his blog it was great to put a face and personality with the name. I met so many great people at the event, if only I could give a shout out to each one individually.

I’ve managed to get back to Tulsa on-time thanks to Southwest Airlines. They rock, seriously.

I’m still recovering from the weekend — it was surprising, invigorating, frustrating, annoying, amazing, enlightening, and completely overwhelming. I’m going to let my thoughts simmer for a day or two before I share my views on the experience. There are several posters that covered the play-by-play, I chose not to cover the event from that angle. I met some great people, I had some great conversations, and it was an amazing experience.

I’m sure the organizers are relaxing since this afternoon having completed what had to be an enormous amount of preparation to pull off an event of this scale. The logistics were flawless and the format was beyond explanation. You guys did an incredible job on the crucial inception of ALT.NET as a mindset.

Open Spaces is powerful, surprising, awakening, and enlightening. You can’t explain it, you just have to do it.

More to come, for now, I remain…

Well, the foreplay is over. Tonight at the ALT.NET conference, we had a social meet-and-greet before the concepts of Open Space were explained. In the introductions, I mingled with a lot of smart folks, many whose blogs I’ve seen, and many who just have a passionate interest in software development.

Once we were all seated, we did a quick 7-second introduction around the room. I was surprised (well, not really) to find several folks from Microsoft attending. A couple are here to talk about some of the new frameworks coming out of Microsoft (for the MVC pattern) and others are here to find out what they’re doing wrong and how they can improve themselves.

The event then kicked off with an introduction to Open Spaces, the format being open and defined by the people in the room. A demonstration was given of a Fish Bowl, a concept where the only people in the room talking are those seated in the center. As time goes on, people who want to speak come up and take the one empty chair. At that point, the longest standing person in the fish bowl must return to the audience until a later time. This musical chairs continues until the facilitator (?) starts removing the empty chair, at which point a seated speaker must return to the audience. It was very interesting from a dynamic perspective and stayed fairly well focused on the topic.

The next item involved people writing their ideas onto a post it and placing them on the time slots available. This went on for some time as each convener announced their topic to measure the interest. Once all the topics were announced, each of us selected which items we wanted to discuss. This established a level of interest and really served as a tool to arrange the sessions such that they were available to those that wanted to attend. The events with no interest were tossed aside and certain events were put into larger room where there was a stronger interest (Microsoft MVC demo for instance).

At that point, all the official opening night items were done. Everyone stayed and talked for an hour or more, at which point somebody said quite loudly “let’s go find something to eat!” So a number of us, M. Fowler, D Sellers, many many more, went to a place called Waterloo for burgers and beers. We closed the place down (well, they threw us out at 10:07 PM), after which we came back to the hotel bar for a nightcap. The conversations went on until the bar said they were closing and we had to get out. So the after-hours discussions were plentiful and interesting. I tried to surf around to catch as many things as I could, stopping when a familiar pain or pleasure was overheard.

Tomorrow is a full day and I’m really looking forward to it. A hearty breakfast will certainly help and the hotel has a pretty solid buffet that I’ll be attending for sure. I still need to find a place to get some Monster before the start, hopefully a c-store somewhere has Blue Monster to keep the eyes open.

NOTE: I’m going to avoid saying something like “Day 1 of 3″ because I have no idea if there will be another post until I get back to Tulsa. I’m going to try — really, I am — but no guarantees.

Southwest flights are so easy - no hustle and bustle of the commercial airports like DFW. There is something about the quiet, relaxing atmosphere of Dallas Love Field that makes you comfortable.

I’ve landed in Austin, TX and scored a rental car for the weekend.

My first stop is going to be the Barton Creek Mall. They have a California Pizza Kitchen and I’m going to have lunch there. We don’t have one in Tulsa, so I try to stop and get some good stuff every time there is a CPK nearby. UPDATE: Lunch was great!

UPDATE: I got in touch with Dru Sellers, going downtown to meet up with him to burn some time before this afternoon.

After that, I’ll probably just hang around for a bit and see what there is to see. The conference doesn’t start until 5:00 PM, so showing up before even 4:00 PM seems a bit over-eager. I’ll probably roll by the Apple store mostly because there is something fun about an Apple store in Dell headquarters!

The goal of the opening session tonight is to define the content of the event. In Open Spaces, the format of the event is defined by the attendees. We’ll start throwing discussion topics onto the wall and watch as themes start to evolve from those ideas. Once a set of themes emerges, the agenda will be established.

After the opening session tonight, I’m guessing there are going to be some hungry travelers ready to hit the town and find something for dinner. After that, I’m sure some lively libations will find there way onto the scene. Stay tuned!