PhatBoyG.com

I arrived in Seattle today to get warmed up for the ALT.NET Seattle conference this weekend. I came up a couple of days early to meet with a few people before the event started on Friday.

Once we landed, our first trip was to the Pike Place Market, which is right on the shore of the Peugeot Sound. We had lunch at a great chowder house, followed by a coffee at the original Starbucks coffee shop. After the food and drink stop, we walked around the market and stopped at an REI outfitters (like a Bass Pro without all the hunting gear) since Dru forgot his jacket in Kansas. As we left the store, the sun came out and it was really too warm for a jacket — such is luck. So we got back in the car and drove to a mini-mart to get some Monster to fuel the next few days, after which we parked downtown and walked to the Westin to meet up with some guys.

When we got to the Westin, we met up with Nick Parker to talk about various open source .NET projects that are active. After a while, Greg Young joined us and shared his understanding of how messaging applications should work and gave us some tips from his experiences using various forms of message transportation. The discussions started off general and got more specific as we talked about particular scenarios within our applications.

Since Dru Sellers and I both work on MassTransit and both use it in our commercial applications, it was very helpful to get feedback on this key infrastructure component. What we found is that while we have a pretty solid start, there are a few clarifying points that will help elevate the platform to be even less complex while adding new functionality. We came away with a lot of good ideas (and some diagrams, which David Laribee never actually witnessed being drawn) that we will probably explore over the next day or two.

After a few beers and some good discussion, the MVPs kicked over to the evening party that MS had arranged, so Dru and I went to dinner and drove out to the hotel.

Tomorrow should be an interesting day as we try to lay down some of the things we talked about tonight into code. We also have a very exciting dinner planned for tomorrow night, but I’ll save that for another post later in the week.

While the MVPs descend upon Seattle for the 2008 MVP Summit, I’m getting ready to head to Seattle for the ALT.NET Open Spaces Conference this coming weekend. Many of the people attending the ALT.NET conference are also MVPs, so there are likely to be some tired folks by the end of this week(end).

Based on the experience I had in Austin at the first ALT.NET conference, my company has agreed to send me to Seattle along with a couple of coworkers. A fellow developer and our agile project manager are going along to share in the experience and join the conversation. As an organization, we’ve seen many improvements since converting to agile development (XP-style) and I’m hoping the conference will help identify some new ways to help us grow and educate the rest of the team.

From a project perspective, Dru Sellers and I are trying to wrap up a 0.1 release of MassTransit in time for the event. We’re hoping to be able to share some of what we’ve done with others who are approaching a distributed application architecture, and even more importantly learn from others with similar experience so that we can improve MassTransit and add some new routing and management features. We’re getting there a couple of days early to have some time to pair up and knock out a few last minute tweaks before calling it good.

I’m looking forward to seeing a lot of the friends I met at the first event, as well as making some new friends. I’m excited to have “Doc” facilitating the event, his coordination of the first event was an inspiration at the start of each gathering (regardless of how many beers were consumed the night before).

As the event unfolds, I’ll be adding pictures to a web gallery for the event. Be sure to check it out (or add a subscription to the feed) if you weren’t able to attend in person. I’m sure there will be plenty of tweets as well, along with an RSS feed overload after every gathering.

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…