So, if you have been wondering what NHibernate is all about and looking for a good place to get started, this could be it for you.

Share This

What we want it to do is bring up the test that filed, where it failed. Here’s how:

Tools > Options > Test Tools > Test Execution

and then click the box.

Share This

So, how do I disable resharper to make sure I don’t get any pesky resharper files into my directory structure? By using Visual Studio’s Add-In manager.

1. In Visual Studio go to Tools > Add-in Manager.
2. Uncheck the ReSharper 4 Add-in and then unselect the Startup box so that when you start up VS the next time, the Add-in won’t load.

Not so fast, Gerome! Turns out that when ReSharper installed, it installed in such a way as to make this impossible. The fix is easy.

In your ReSharper Program Files directory, JetBrains\ReSharper\v4.0\Bin, find the Product.VisualStudio.90.AddIn file. Visual Studio needs to be able to modify this file and the installer laid in down read only. Make the file write-able and go back to VS and go through the process again. This time you will be able to turn off startup.

Even after doing this, the ReSharper menu remains in my IDE, which bugs me. All of the functionality is disabled and the context features in the code files are gone, but still…

Share This

Share This

So, what’s the verdict? Basically, “Where’s my Treo?”

The wheel navigation on the right has always been hard for me to navigate. That’s why I didn’t like my previous BlackBerry. Therefore, I use the touch pad on the front, but I really miss my Treo’s touch screen. A lot.

It is harder in Mobile 6 to customize my front screen and easy-access applications, but at least I can run TinyTwitter with the new CLR.

And get this: You have to hack the registry to change the home page on the browser. That’s right. You have to HACK THE REGISTRY to change the home page. Microsoft, you are already under a microscope. Do you have to make yourself a standing target? This is just bad.

Lastly, where is the mechanical mute switch? Oh, that’s right. There isn’t one. That means I get to fumble this thing like a hot potato in a meeting where I forgot to set vibrate mode. Jeez.

At least it makes phone calls.

Share This

• Healthwise (my full-time employer) has been good enough to offer me the opportunity to pursue this passion in addition to my current duties as Chief Software Architect. Frankly, teaching and learning with the other folks of PluralSight simply makes me better for Healthwise. Thank you, Neal.
• Elegant Code is a community site near and dear to my heart. I will continue to contribute to the Elegant Code community and at times may cross post in both places.
• The Elegant Code Cast will carry on and get even better. I just recorded a great session tonight, as a matter of fact
• With PluralSight, I will have a particular focus on Team System, SharePoint, and we’ll see if I can rub a little of the Agile love on these guys. Need some Team System training? Ask for me

So, sorry if I have been a little quiet lately. As you can imagine, I have been having a couple of VERY busy weeks. Things were beginning to settle back into a manageable rhythm, then I got a call that prompted me to make some hurried family decisions. I will be taking 2 of my boys and heading to Texas (from Idaho) for the next 3 weeks. Real life meatspace issues are way tougher than developer problems, as it turns out. Getting older is for the birds, isn’t it?

This means that my coverage will be spotty for the next few weeks, but on the upside I get to take Mike Azocar out to dinner. Turns out he and I went to rival high schools (we always won the football games).

So, I will be resurfacing at the Agile 2008 conference in Toronto to do some TDD sessions and talks. I hope to bring home some great Code Cast interviews from that one!

Share This

As you may or may not know, I’m a huge fan of using Test Data Builders for setting up the context for the domain objects in my BDD specifications.

[TestFixture]
public class When_performing_something_action_with_an_order
{
    [SetUp]
    public void Establish_context()
    {
        _order = new OrderBuilder()
            .WithCustomer(new CustomerBuilder()
                .WithFirstName("Homer")
                .WithLastName("Simpson"))
            .ForProduct(new ProductBuilder()
                .WithName("Saxomofoon"))
    }

    …
}

The biggest benefit of using the Builder pattern this way, is the fact that the creation of domain objects gets decoupled from the specifications itself. The constructor of a domain object gets called only at a single place in the code. If I wanted to add a new parameter to the constructor, I only have to change it in one place.

The following CQL statement ensures that the Test Data Builders are used instead of directly calling the constructors of the domain objects:

// <Name>Test data builders are not used by SetUp methods.</Name>
WARN IF Count  > 0 IN
SELECT METHODS
WHERE (HasAttribute "NUnit.Framework.SetUpAttribute"
 OR NameIs "Before_each_specification")
AND
((IsDirectlyUsing "NAMESPACE:MyProject.Domain.Model"
 OR IsDirectlyUsing "NAMESPACE:MyProject.Domain.DTO")
AND !IsDirectlyUsing "NAMESPACE:MyProject.Domain.UnitTests.Builders") 

Although its probably not 100% foul proof, this CQL constraint detects the most blatant violations.

Till next time,

Jan, the NDepend addict.

Share This

The Encouraging

Dialog is beginning to focus on Lean and iterative delivery practices. These basic values supported by the Agile manifesto are beginning to receive more attention, much to my pleasure. We are finally getting around to talking about value flow rather than our available hodgepodge of Agile coding techniques. Excellent!

Scrum has finally been recognized as an excellent team management model that supports Agility. It is also prone to fracturing at large scale and must be held together with more pressure at large size. It takes more than Scrum to deliver on the whole promise.

Test Driven Development is a wonderfully Lean practice that has genuinely matured to a standard engineering practice. Who can argue with, “Constant attention to quality?” Now that we can agree this is how to do business, we are simply evolving the technique rather than arguing about whether it has value. Good stuff.

The Exciting

Agile practices and Lean techniques are finding home in even the stodgiest organizations. Few developers would dare admit they aren’t “Agile”. Sometimes it is even true.

The Microsoft team building Rosario is executing their work in a genuinely Agile way. That is, iterative with high visibility and close client involvement. The ASP.Net MVC team is behaving similarly with frequent releases and high bandwidth feedback from the community.

The Discouraging

Many people describing their Agile practices center around the common denominator of, “No requirements and we work on the highest priority item.” That’s firefighting. Agile requires the discipline of focus, if only for a single iteration.

Implementing only a few practices that seem easy to accomplish does not make an organization Agile. Yes, iterations are important, but they are not the end game. Steady delivery of genuine value is the end game.

I cannot count the number of times people have represented their practices as “Scrum-like”. I commonly ask, “Did you start with Scrum and modify it to fit your shop?”

“No,” is the common answer. “We read the books and picked the parts that seemed to make sense for us.”

That really bothers me because if there is one thing I have learned in the last 5 years of implementing Agile practices, it is this: Practice the prescriptive Guidance for 3 months before you change anything.

We all think we’re different, but we struggle with the same issues. There are very real recipes for these techniques. Agile is a lot of things, but it isn’t just what you want it to be.

Share This

I started developing a site using the MVC Preview 2 source. Two weeks in, I pulled the latest MvcContrib project, and a few days ago I upgraded again to the MVC Preview 3 source. Like anyone using beta software, I have spent some time swearing at my screen, but overall, I am pleased with the MVC framework. After returning from vacation, I now find that I am one more release behind on my MvcContrib binaries.

As I began developing with the MVC framework, the similarities I was seeing with Castle’s MonoRail MVC were numerous and reassuring. I felt like I could hit the ground running with previous MVC knowledge. The sample MVC application right out of the box is functional and a helpful place to start familiarizing and education oneself with the new framework. For those tools and features that are not built into the framework at this point, I found the MvcContrib project to be helpful in my development.

It seemed like with each day of development I would discover something new, cool, or exciting, and I wanted to share it on this blog. As I started down the path of writing a blog entry, I procrastinated each time thinking, “let me just get through this one issue first and then I will blog.” That approach snowballed tremendously. With each hurdle I had to surpass, there was another release I had to install. Of course, I did not have to install any of these updates, but I did thinking they would be trivial. In some cases they were, and in some they were not. My point - there is a great deal of change and development constantly occurring on the MVC framework and other tools supporting it. Expect this rate of change while the framework is maturing. Sometimes it is frustrating, but there is great support on the ASP.NET/MVC forums as well as MvcContrib.

Why do I like it?

MVC promotes a cleaner separation of concerns. Since I am used to developing in ASP.NET and trying to adhere to a loosely defined MVP pattern, this MVC framework mitigates some of the frustrations of having to enforce the pattern as well as SoC.

Testability is build into the framework. When creating a new project, there is an option to create a test project to accompany it.

I can create a web site quickly and cleanly. As I add a new page (view), I have a distinct controller and view for it. Unlike MVP implemented in ASP.NET, I do not have to enforce my controller-view separation, it is done for me.

I am able to use use more than one view engine easily. I am tired of using the ASP.NET view engine. While one can roll their own view engine flavor, MvcContrib provides support for a few out of the box. I can free myself of having to use ASPX pages, ASCX user controls, and their code-behind files.

I prefer using the NVelocity view engine. I prefer the more simple HTML view of NVelocity. My customers enjoy it as well, and they do not have to concern themselves with ASP syntax. They will have to learn a few tricks with NVelocity, but nothing that is not intuitive as it is.

Extensible source. I have been able to add custom support to provide overrides and additional functionality to the framework as I need it.

Community support. The MvcContrib project helps make development with MVC easier. Use their view engines and IoC container support. Know of some functionality that is not available, add it.

Pitfalls

IIS 6 and URL rewriting. While it is possible to get the nice URL rewriting to work with IIS 6, ISAPI filters, and extension mappings. It is a PITA. I am in the process of upgrading my customer’s environment to use IIS 7. Today, their URL contains the “.mvc” string, such as, <domainName>/home.mvc, or <domainName>/account.mvc/login. I suggest having IIS 7 available.

Ajax framework. I am still waiting on a good Ajax framework to be included. The one MonoRail includes is nice. As for now, I am using jQuery and developing my own. Hmmm, maybe this functionality could be added to the MvcContrib project, and maybe instead of limiting it to jQuery, I could abstract it to enable other Ajax providers. We’ll see what time permits.

Third party controls like Telerik, Infragistics, et alia. Rich datagrids, tree controls, and other controls that rely on view state and postbacks. I expect support will come around for these.

I tried the NHaml view engine, a .NET implementation of the Rails Haml view engine. My NHaml default layout (master page) was generating runtime errors because I was not use the proper spacing of two characters. Seriously? Two spaces? Who cares. I moved on to try Brail.

I have been pleased thus far. Thank you to the ASP.NET MVC team and the contributors to the MvcContrib project. Keep up the great work.

Share This

Here is the list of some of the extension methods:

• void AssertWasCalled<T>(this T mock, Action<T> action)
• void AssertWasNotCalled<T>(this T mock, Action<T> action)
• void BackToRecord<T>(this T mock)
• IMethodOptions<VoidType> Expect<T>(this T mock, Action<T> action)
• IList<object[]> GetArgumentsForCallsMadeOn<T>(this T mock, Action<T> action)
• void Raise<TEventSource>(this TEventSource mockObject, Action<TEventSource> eventSubscription, params object[] args)
• IMethodOptions<object> Stub<T>(this T mock, Action<T> action)

This is not a complete list, btw.  But these are the methods that I find interesting right now.  Plus, if you start looking at Ayende’s new samples, you will need to keep these in mind.  Speaking of Ayende’s samples, lets look at one.

   1: [Test]

   2: public void WhenUserForgetPasswordWillSendNotification_WithArgumentMatching()

   3: {

   4:     var userRepository = MockRepository.GenerateStub<IUserRepository>();

   5:     var notificationSender = MockRepository.GenerateStub<INotificationSender>();

   6:  

   7:     userRepository.Stub(x => x.GetUserById(5)).Return(new User { Id = 5, Name = “ayende” });

   8:  

   9:     new LoginController(userRepository, notificationSender).ForgotMyPassword(5);

  10:  

  11:     notificationSender.AssertWasCalled(x => x.Send(“Changed password for ayende”));

  12: }

OK, first draw your attention to lines 4 and 5.  Note, there is nothing really new here.  We are creating a set of stub objects.  A stub object is a fake object that doesn’t care if you call it or not.  Now, I’m trying to draw your attention to these lines, because it makes lines 7 and 11 more interesting.

On to line 7.  userRepository.Stub.  userRepository is a stubbed object (see line 4), that I am betting does not have a method called Stub.  It is an extension method from Rhino Mocks.  Here is what the online documentation says the Sub method does:

Tell the mock object to perform a certain action when a matching method is called. Does not create an expectation for this method.

OK, so line 7 is telling userRepository that IF AND WHEN the userRepository method GetUserById is called for User 5, return a new User with an ID =5 and Name = “ayende”.   Before, this would have looked like this:

MockRepository.Stub(userRepository.GetUserById(5)).Return(….)

Now it is

userRepository.Stub( x => x.GetUserById(5).Return(….)

There is a similar Expect extension method that does create an expectation.

There is still room for misunderstanding with this new syntax, but it could be a step in the right direction.  One of the problems I’ve had with Rhino Mocks, and other Mocking frameworks is explaining the syntax to new users.  Namely, you don’t see the mock object you are testing against first, but the method Expect or Stub.  Now the object is out front.  This will still cause a few issues — especially for people who are not expecting extension methods, but I think that is just a small training issue.

Now on to line 11.

I’m looking at AssertWasCalled.  Note, this is called after the method ForgotMyPassword was called.  ForgotMyPassword is the method we are actually testing (also called the SUT, or system under test in unit testing lingo).

So, AssertWasCalled checks to see if the notification sender’s Send method was called, and fail the test if it wasn’t.  B-E-A-U-tiful.  This fixes one of the other major problems I’ve had explaining mocking, and it also made the tests harder to follow.  Here is why.

Typically in your test code you have two types of expectations.  Methods that you expect to call to get valuable information from so the SUT can continue, and methods that you expect to be called with that information.  Historically I’ve had to group both of those method calls together before the SUT is called.  That made things messy to me.  Plus things were all out of order.

The beauty of AssertWasCalled (and AssertWasNotCalled) is that they can be called AFTER the SUT is run.  Thus keeping everything in order and the coded easier to follow.

The big recap:

So here are the positive changes, as I see them:

1. Mock/Stub objects come first when setting expectations
2. You can check for values after the fact with AssertWasCalled and AssertWasNotCalled.

Thumbs up from me.

Share This

Paraphrasing a classic comment from Gates.  We want a computer in every home.  We never thought about the fact that we would have to be a BIG company to do that…

Share This

Suppose we want to enforce a BDD naming convention for every SetUp method. Such methods should be named Establish_context. The following CQL constraint reports those methods that are not named consistently:

// <Name>NUnit SetUp methods that are not named consistently.</Name>
WARN IF Count > 0 IN
SELECT METHODS FROM ASSEMBLIES “MyProject.Domain.UnitTests“,
“MyProject.Infrastructure.UnitTests“
WHERE HasAttribute “NUnit.Framework.SetUpAttribute“
AND !NameIs “Establish_context()“ 

Lets have another one. A while ago, I wrote this post about how WCF gave me this weird exception after I forgot to put a DataContract attribute on one of my DTO classes. Lets write another active convention for that:

// <Name>Data contracts without a DataContract attribute.</Name>
WARN IF Count > 0 IN
SELECT TYPES FROM NAMESPACES “MyProject.MyServiceContracts.DataContracts“
WHERE !HasAttribute “System.Runtime.Serialization.DataContractAttribute“

Now here comes my personal favorite. Being the huge DDD adept that I am, I want to enforce that the domain is the core, the centerpiece, the kernel as you may of my application. I don’t want it to have any dependencies to other assemblies in my application, especially not the infrastructure assembly.

// <Name>Domain is directly using the infrastructure</Name>
WARN IF Count > 0 IN SELECT METHODS FROM ASSEMBLIES “MyProject.Domain“
WHERE IsDirectlyUsing “ASSEMBLY:MyProject.Infrastructure“ 

It can’t get any easier than this, now doesn’t it? This is actively enforcing Separation of Concerns. Another way to have a convention about this is the following:

// <Name>Domain-Driven Design convention</Name>
WARN IF Count > 0 IN SELECT ASSEMBLIES WHERE AssemblyLevel > 1
AND NameIs “MyProject.Domain“

This means that my domain assembly can only have a reference to the .NET framework assemblies and nothing else. This gets my geek heart pounding.

Imagine the possibilities if you incorporate this with your daily and continuous integration builds. Pure software quality assurance if you ask me.

Share This

You probably heard about the ADO.NET Entity Framework Vote of No Confidence. The moment this went online, I signed it without any hesitation. I still believe that version 1.0 of the EF stinks badly compared to NHibernate. NHibernate allows me to write maintainable applications without sacrificing OO programming, and it will be far more superior for a long time to come. I agree that a first version of anything isn’t feature complete, but it should support at least a couple of basic OO principles.

At first, I didn’t want to blog about this until I read Chad’s post. He mentions this blog post by Kathleen Dollard that made me scratch my head for a while. It’s not the general insulting tone of the entire post that sets me off, but rather the following sentence somewhere in the middle of her post:

 EF is not a failure because it has a poor strategy for merging into source control

How on earth can you put something like this on your blog and still call yourself a professional developer? Source control is not negotiable.Period! If a tool doesn’t allow me to use source control, then it’s bye, bye baby! I thought we were past this by now? I guess not, so I will repeat this for the last time: you can’t deliver maintainable software without proper source control in place!.

Regarding the data-driven approach vs the OO approach: those VB6 days are over! Wake up and smell the roses. I never witnessed an OO approach to fail in my eight years as a developer. Maybe I’m lucky. I don’t know. What I do know is that a data-driven approach fails miserably every single time it’s used in a software project of any size larger than an ant. Transaction scripts don’t handle code duplication well, they violate separation of concerns and are a major disabler for loosely coupled (aka maintainable) applications.

Anyhow, back to the title of this post. The EF team has been very open about all this. Daniel Simmons announced the EF Advisory Council and the team responded in a real constructive way to the "Vote of No Confidence" by setting up this blog about the future design of the Entity Framework. These are some of the first positive signs that they are setting themselves up for success.

Share This

From the APLN website:

APLN was founded in 2004 by a group of people who are active in writing about, practicing, and evangelizing the movement towards fast, flexible, customer value driven approaches to leading projects of many types. Although this organization is separate from the Agile Alliance, our intention is to work closely with that group within the software community, but also work with people and companies outside of software and IT to help them become better Project Leaders.

I have been party to the APLN discussion at the annual Agile conferences and have found great value in the stories presented there. If you are interested in becoming part of the discussion, jump in to the Google Group.

Share This

“..a foundation whose combined assets will one day exceed the budgets of all but 30 percent of the countries in the world”

Talk about having to learn how to scale :-).  I it will be interesting to see how he takes on this challenge.

Share This

The way our sprint reviews work, everyone in the company gets to rotate between teams who show their work in 15 minute segments. Picture a science fair with parents moving between booths and spending 15 minutes at each one. This has been a hugely successful format because teams get to have more intimate conversations with people seeing their work. Discussions are more interactive because there is a smaller group watching the demo and folks are more likely to speak up.

From the presenter’s point of view, this is showing the same thing 4 times in a row. This is okay, but gets a bit tedious. Worse, because each group brings up individual issues there may be things about the feature that get skipped in a given 15 minute segment.

What I Did

I recorded a feature walk through on Camtasia and played it during sprint review. Four times. This left 3 minutes for discussion, but with the transition times, it pretty much took up the entire 15 minutes.

The most common feedback was, “Cool idea. It was too long.”

Noted. And, I think the idea of doing a complete walk through as a recording has merit because it sort of forces that all areas I want to show will get shown.

It is important to realize that I made the recording a mere hour before Sprint Review. Thus, the software was real and did do what I showed.

What I Will Do Next Time

• Limit the Camtasia video to 5 minutes and leave plenty of time for discussion.
• Be more animated. No monotone voice.

Your Thoughts? Am I a big, fat cheater?

Share This

I think it went reasonably well.  I saw a lot fewer blank stares than usual, that is good, and quite a few people got involved.  After a few rounds with the attendees, here is the list of topics we settled on:

• Inversion of Control (selling it to upper management, and what is it)
• ORMs (NHibernate, SubSonic, Linq to SQL, oh my!)
• Behavior Driven Design
• Web Service Security

Obviously you cannot cover all of those topics in depth, but sometimes you don’t need to.  In the course of the discussion we also talked about Test Driven Development, Architecture, when to use singletons and when NOT to, and Active Record Pattern vs Repository Pattern.

Take away’s from the meeting:

• There is a lot of interest in IoC libraries out there, but not much practical experience.
• We also need to have a session on how to get started with NHibernate.

Actually, it was amazing to me how much interest there was in “advanced” topics and best practices.  Hopefully that will continue.

Share This

It is an interesting idea and an obvious compliment Domain Driven Design and Behavior Driven Design. The intent of the Mental Model is to allow designers to envision a user’s thought process and although it isn’t out-of-the-box simple, it is inherently useful.

She had some great feedback for our teams on creating more effective personas and user scenarios. Specifically, keep the personas behavior focused. For instance, I don’t need to know that Harold is a 38 year old fat guy, but I do need to know that he struggles to find content he is after on the web. Make sense?

At any rate, I have every good intention of reading her book and look forward to augmenting my toolbox with Mental Modeling.

Share This

I hit on iterative practices, embracing change, adaptive product definition, value flow, and risk mitigation.

What points would you make to a group of Business Analysts in a 45 minute opportunity?

Share This

If it weren’t for this guy, I never would have gotten it to work. Thank you, Josh Anderson! Follow his instructions to the letter, but be prepared to shell out some money (just a few Euros) to RapidShare to download the 2.1 drivers in anything less than 24 hours. Unless you pay, you must wait 92 minutes between each download.

When you get to the video drivers, here is a little simpler explanation of how to do this.

1. Go to www.laptopvideo2go.com
2. Download the latest driver for Vista 64. The site is a little confusing to me, but the bottom line is to just pull the latest Vista 64 driver. Don’t bother searching around for anything like “MacBook” or “NVidia”. That’s not how the site works.
3. Download the Modded INF (nv_disp.inf)  file on the same page as your driver. After extracting the driver, place the INF file in the driver directory.
4. Now do the install.

OK, now to the inane answer of what software I put on my virgin system, because that’s what everyone really wants to know, right? OK, in order:

1. Vista 64 Ultimate + Service packs and drivers
2. Input Remapper (to control fan speed under Vista. The Mac runs hot otherwise.)
3. Launchy
4. MS Office 2007 Ultimate
5. Virtual PC 2007 SP1
6. Live Writer CTP
7. Visual Studio 2008 Team Suite
8. ReSharper (but I’d really like to try CodeRush, hint, hint, Mark)
9. SQL Server Developer + SSMS
10. TortoiseSVN + SvnBridge for Team Foundation Server

Share This

• “How do I expand the envelope of done across the organization?”
• “How do we run sales in an iterative delivery environment?”
• “How can Agile fit within our PMI phased model?”
• “How can I plan for the long haul in this model?”

These kinds of topics represent the maturity that Agile practices are reaching in organizations and their applicability beyond software development teams. What a great thing!

The Agile Project Leadership Network (APLN) is an international association of people interested in these very topics. The organization is formed by local chapters of which there are approximately 40 today. Membership in the APLN affords opportunities to participate in other events, like the APLN Leadership Summit in Seattle in July.

This email is a feeler to the community. Are you interested in a Boise Chapter of the APLN? Contact me if this sounds interesting to you.

david (at) elegantcode (dot) com

Share This

• Entity Framework
• Silverlight
• Designing for Testability
• Data access for RIAs

and of course, qualities of Elegant Code.

Get the podcast here.

Share This

It lets me use categories, but nothing terribly sophisticated, which is what the name implies. It is simply here to dash something off.

Thing is, I simply cannot find a decent and FREE blog client for the Mac. Frankly, nothing I have used stands up to LiveWriter on any platform.

Think MS will port that?

Share This

The excessive amount of NHibernate features  isn’t the only thing that is written down. There is also a good coverage of OO principles and Domain-Driven Design, although it isn’t the primary objective of the book of course. This is especially true for the first and the last three chapters. If you’ve already read the nominal books DDD and you are familiar with Persistence Ignorance, then you can safely skim through these chapters unless you want to see the interpretation of the authors when it comes to these principles. If you are new to these concepts, then these chapters are of great value to wet your appetite.

Although this book covers a lot of ground, I would certainly recommend it when you’re rather new to NHibernate and ORM’s in general. I guess this still includes me, although I’ve been using NHibernate for quite some time now. If you already have some experience with NHibernate, then this book probably doesn’t teach you that much. Still, it can quickly get you up to speed when you want to use a particular feature that you haven’t used before.

The only minor thing about this book is that I’m afraid that it will soon be out-of-date. The book only covers NHibernate 1.2.x and no features from the upcoming 2.0 release, which adds a lot of new and interesting features. It would be nice if the book already covered some of these features as most of them are ported from Hibernate itself, which is the original Java version.

On the other hand, this book provides an in-depth view of the basic features of NHibernate, which aren’t necessarily going to change that much over time anyway.

Let me round off this post by saying that I’m really impressed by the list of books that Manning is going to release the next couple of months. These are the ones that I’m particularly interested in:

• Building Domain Specific Languages in Boo
• ASP.NET MVC in Action
• Brownfield Application Development in .NET
• IronRuby in Action

I already bought LINQ in Action and also read a lot of good things about C# in Depth, which I’m going to pick up soon.

Take care.

Share This

ALM is the enterprise software development holy grail that IBM sought for years and invested in with the Rational tools. And although there is a tremendous value in prescriptive guidance in enterprise development models, there is a natural tension between the ALM crowd and Development as a Craft advocates. ALM, after all, is all about quantifying, measuring, predicting, planning, and economies of scale. Ironically, the kind of transparency and predictability called for by the minimalist Agile community is the same goal of ALM tooling offered by Big Blue and now by the new blue in Redmond.

How are Microsoft products staged to lay across the ALM model? The story today is mixed.

Your familiarity with these products may lead you to the same conclusion that many have already reached. The products in the stack currently fail to integrate cleanly and many provide only a starting taste of the functionality needed to realize the ALM vision. The story is obviously a little muddy today. But what’s next?

Team System Rosario promises much improvement in the areas of tracking, design, quality assurance, and development. Significant bridges are also being started toward improving the release management story.

That won’t do it all, of course. There are other pieces needed in the stack that will need to be freshened up including operational support tools. Microsoft is in hot pursuit of filling this gap with a host of products under the System Center umbrella of products. An actual helpdesk management system to displace the TechExcels and Remedys of the world is essential here.

The point is, MS has its sights set on a complete ALM story and are focusing on the midsize market, as Microsoft is so good at doing.

The Good

A focus on ALM in the Microsoft stack will have a tremendous impact on software development and delivery as we know it. Interoperable components in the pipeline will help bridge those gaps in midsize organizations that are typically only filled in large enterprises. Transparency will be ubiquitous.

Given the open nature of products being developed at MS these days, I have high hopes that these systems will truly be pluggable, so that if you want to bridge TFS to Remedy (for example) doing so is not rocket surgery. Web services are great, aren’t they?

Concerns

There is a fine line between managing for predictability and ‘command and control’. Tools like those in this stack are like guns. They can be used for good, but misuse is more common than not.

Tooling like this gives every non-tool Agilist out there genuine pause, and with good reason. The history of stewardship in complex models like this is less than stellar. That is to say, this tooling can provide huge value, and the basis for crushing souls. Let’s be careful how we wield them.

Share This

• Simplified the user experience through cleaner “Add to Source Control” dialogs, drag and drop support to the Source Control Explorer and a much easier to use “Workspace” dialog for working folder mappings.
• Version control now automatically supports non-solution controlled files.
• Various changes to the Source Control Explorer such as a new checkin date/time display column, local path hyperlink support and en editable source location field.

I am not a big fan of installing a beta SP on may dev laptop, but I gotta tell ya, I did it for that feature alone.

Share This

Go here:

And get this screen.

Why? Because if you have made some changes to a file while it wasn’t checked out, you will not have the option to merge to your local machine. This option will simply overwrite your local code file.

Why does this feature exist? Because oodles of people asked for it because they were used to it in Source Safe, and the team relented.

Repeat: This is a bad idea!

If, however, you are a person who simply must have this turned on in order to feel snug, there is a way to do it without making your entire team experience the hell that will be yours.

In Visual Studio, go to Tools > Options > Source Control > Environment and do this:

I warned you.

Share This

I had the unpleasant task a few years ago of maintaining a series of dBase programs that embraced this concept, and, in fact, were probably written in church. Everything in the code had a value and a meaning, both of which were subject to change as the execution transferred from module to module. A field called field25 in a record may be the business phone number, unless it contained the literal “VEN”, which meant that the business phone number could be found in the vendor profile record. Later, field25 became FirstName. Meanwhile, if the vendor profile record’s b_phone contained “Line33”, then control would pass to the 33^rd line in the code. I called this application the “coat hanger” app, as it reminded me of a huge pile of coat hangers, with the objective being to keep everything straight. This app was not one to screw with, as it screwed back, sort of like playing whack-a-mole with a nest of hornets.

When I first saw the phrase “Elegant code”, I thought “Someone finally gets it.”

So, why take pride in what we do? Let me use the house I live in now, and the work that the previous owner did as an example of what not to do.

Take the laundry room. Recently, I had to remove some of the sheetrock from the wall to repair a leaking main water valve, whose duct tape finally gave out. The center studs were supported by the sheetrock. Perhaps it was to hard to find 16-penny nails, or maybe the sheetrock nails were too short to do the framing. I had never thought of hanging 2×4’s onto sheetrock, but I have seen code that was done in a similar manner. Not elegant.

Then there are the doorknobs throughout the house. Some have a rectangular flange around the latch, and some are simply a round barrel. Why not put the rectangle ones in the doors with simply round holes? After all, the hole is already there, and nobody will notice if the edge of the door doesn’t get routed out to accommodate the rectangle flange. It would be very hard to carve out with a sheetrock nail anyway. Besides, someone else will have to maintain this, not me.

Consider the outside paint job. If nobody can see the top of the window casing, why waste paint on it? Sure, there are parts of the old paint job that need to be scraped off, but new paint will work just like glue, holding the old paint in place. This must have helped to create the shortest direct route from the ladder to the hammock and lemonade.

The plumbing was cool, too. The hot and cold faucets were reversed in the two upstairs bathrooms. Perhaps the people living upstairs were left-handed, or did everything behind their backs.

It must have been out of boredom to place the light switches for the bathrooms to the right of the towel rack, three feet from the doorway. Pretty amusing for first-time visitors: “Does your bathroom have lighting?”

All in all, it seems that this guy’s cranial-rectal inversion was a manifestation of apathy and love of duct tape.

——————— By Contrast ———————

The finish carpenter on the last house that we had built took a great deal of pride in his work. When he was finished with his work on the doors, cabinets, railing, and trim, he videotaped his work. I was impressed.

I suppose that this could be considered elegant woodwork. It was done with a lot of focused energy, from selecting materials to puttying the smallest of nail holes. This guy cared about his work, and believed that what he did would make a difference. To him, it was simply the way he was; he took pride in what he did, and his work was a mirror image of his thoughts and actions.

If, as analysts and developers, we concentrate on the video tape at the end of the project, we can influence the community and make analysis and programming a better place to live.

Share This

We have already worked with BSU to confirm the date of March 28th, 2009. Things will look a little different next year as we try to broaden both our focus of subject matter and our impact on the community.

Next year’s Code Camp will fully embrace the "Business of Technology" discussions that were so popular in 2008 while still focusing on the hard core coder topics that make Code Camp what it is. Watch for updates as we work out further details, but rest assured that 2009 will be a great camp.

Share This

I’ve been playing around with it for a month or so now and it is wonderful to have.  This isn’t the sort of tool that you whip out all the time, but when you need it, you need it.  No doubt there.

But lets throw out some software development methodologies first. 

Rule #1: Premature optimization is the root of all evil. (Donald Knuth said that back in 1974 if you have any issues with it).  Again, this isn’t a tool that you should be using all the time.

Rule #2: If you don’t measure, you don’t know.  The is the heart of the engineering part of software development.  At my last Boise Code Camp (March 8, 2008) I had two separate people complain to me about how slow .net was for WinForms.  OK, so what part was so slow?  What were you trying to do?  Was the database properly indexed?  Did you have measurements about what is slow?  Nope.  Nothing.  I can’t comment on their code, I didn’t see it.  But for all they know the problem could have been anywhere in their code.  It could have been the database was improperly tuned, it could be they were running on really slow hard-drives.  They simply did not know.  To me that is not acceptable.

Rule #3: Where-ever you thing the problem is — is wrong.  This really is just a continuation of Rule #2.  But it is directly related to how many people I’ve talk to that get disgusted with me when I talk about ORMs.  “They are too slow” is the answer I get.  Accordingly, I’ve talked to two developers for whom that was true, for the particular application they were writing.  For the rest, their app was slow, so they were assuming it mush be the fault of the ORM — and telling everyone else as much as well.  Also not acceptable.  They did not know where their problems actually were.

I’ve made this mistake too many times to count myself.  Spending countless hours optimizing and tuning code that had no net effect in the end.  I hadn’t tested, and it proved to be wrong.  And how many of you checked that code in anyway, because you didn’t want to see all that time go to waist?

Rule #4: This isn’t the only tool you should be using.  A properly written application should be testable with unit tests.  It should also have unit tests.  If you find the problem with your code, you should be able to reproduce it with your unit tests, measure it from there, and then possibly fix it.  That is the heart of the Red-Green-Refactor motto of TDD.  A code profiler will help you FIND the problem.  Unit Tests should help you FIX the problem and know it is fixed.

Enough already, on to the review

First of, on Rule #4: DotTrace paired with ReSharper actually make a wonderful paring.  The two integrate in together so you can launch DotTrace from your test cases in the ReSharper unit test runner.  That is just plain beautiful.

On Rule #3: DotTrace’s UI is a tree structure that really does allow you to follow the bread crumbs to find where the performance problems are.  Here is a look at SubSonic SubStage (a nice little application that helps generate your SubSonic files for you, as well as show results of the tables).

I was looking at the boot up time of the application.  Using the tree and the small iconography I was quickly able to figure out that a good chuck of time was being spent in the NavigateFileBrowser method.  Below the tree view a listing of the code is displayed as well.

Another quick note about the display, the grayed out text is system code.  DotTrace doesn’t detect a pdb, so it can’t show you the code that is being executed.

On Rule #2: You can store snapshots — and compare them.  Actually there are three ways to compare snapshots.  Through the call tree (showing the call stack), plain view (showing slowest functions first), and Hot Spots (top 100 problem methods). 

It is amazing how often some seemingly benign code will have significant performance impact.  Best part, now you can find out where the problem is…and where it is getting worse.

As for Rule #1, it might take a while to figure out, but it is true. But the key to the rule, and all software development, is to have good tools to help you along.  This is a good tool, and this is just the beginning of its features.

Share This

I found one chapter in the book particularly helpful, Chapter 2, Commitment and Consistency: Hobgoblins of the Mind. The main gist of the chapter is that people try to be consistent with their actions; therefore by getting commitment from a person you can guide them to a desired action. One example of this is the free SWAG many companies give away. If Apple can get you wear their new cool shirt they are giving away, you will start seeing yourself as an apple person. When it comes time to by a digital music player you will be more likely to buy an ipod as an automatic response to being consistent. Generally speaking the more public the commitment the stronger the consistency response will be. That is why they say if you want to lose weight or quit smoking you will have a better chance by making your intentions public.

At the time I read the book I just started as a Project Lead. One of the first things I ran across in my new position was the issue of poor requirements. These came in several variants. One was the vague requirement that could fit almost any problem. Another was the software solution disguised as a requirement. All this was mixed with requirements that where just plain wrong. Considering myself a pragmatic person I decided that we would revisit each requirement just before we where ready to implement it. To my surprise this approach did not work. As far as the project manager was concerned, the requirements where done and did not need further discussion, no matter how small the change would be.

I later realized that commitment and consistency was the source of the problem we where having. The project manager spent a great deal of time writing the requirements document. It was a mark of the project managers work and who she was. Asking her to break her idea of consistency went against human behavior, and was bound to fail. The problem was not the project manager or the requirements but the process that required a great deal of commitment to information that stood a good chance of being wrong. The trick is to match the level of commitment to the task.

Extreme Programming offered a nice solution to this particular issue, the stories on a note card. This solution is nice as it offered a nice balance between commitment and change. The requirements document from my previous project interjected too much commitment. The note cards do not require as much work and is not as permanent or public as to cause over commitment to a requirement.

On the other hand, some things need a larger degree of commitment. For example time lines usually need to be kept. This is a good place for some kind of public formal agreement. I have worked on many projects where the management team sets the time lines and gives them on the team. This is a sub-optimal situation at best. A much better approach is to create a high level of commitment to the time line with the team.

Scrum has very good solution to this. The time line for a sprint is fixed and public knowledge. The contents of the sprint is decided by the team doing the work and made public. This gives the team the firm commitment that is needed to make the time line work.

I now find that I consider the level of commitment for any team task I am about to oversee. If I am having a problem getting the team to change course, I know I need to tone down the commitment on that part of the project. Conversely, if the team is having an issue keeping on course, I need to increase the level of commitment.

Share This

Share This