Scott Densmore

newCloudApp(): Grand Prize Winner

After many long nights and to much Starbuck's coffee, Kevin and I have finally done it. The waiting game is over and they announced today that we won! Go check out Impulse. I am still feverishly finishing up the iPhone app now that the OS 3.0 SDK has hit. You can still vote for us at new CloudApp() if you think our app is cool. Not sure when our app is going to be listed on Azure's page or the new CloudApp() page.. I hope soon.

We are still working on the iPhone app, getting a community portal built, and more. I should be blogging more about building on top of BizSpark, Azure, WCF, Silverlight, iPhone, Social media integration and building mobile apps for the cloud (not necessarily in that order).

Thanks to everyone out there that has voted for us!

Home by Zero 7

This Code For Rent

Given the current economy and the housing market here in Florida, we have been talking a lot about renting versus owning a home. How does this have anything to do with code? Glad you asked. In the life of any given application, you are probably in it for only a short time (relatively). You might be on the team that builds the version 1.0 product or you might be on the team that is supporting version 6 of a product on version 8. Whatever the case may be, more often than not, you are just there renting the code.
I think this is an important fact to remember. My friend Brain Button taught me a long time that I am not my code and that I definitely do not own it. When I put myself in the mindset of a renter instead of an owner, the idea of The Broken Theory makes perfect sense. When you rent a home / apartment / car, you sign an agreement to take the best care of the thing you are renting the best that you can. Why should that not be any different for code? No matter how you decide to take care of the code you are renting, you should always feel good when you turn (check) it in.

Oblivion by Mastodon

Don't Cross the Streams

"There's something very important I forgot to tell you. 

What? 

Don't cross the streams. 

Why? 

It would be bad. 

I'm fuzzy on the whole good/bad thing. What do you mean, "bad"? 

Try to imagine all life as you know it stopping instantaneously and every molecule in your body exploding at the speed of light. 

Total protonic reversal. 

Right. That's bad. Okay. All right. Important safety tip. Thanks, Egon." (from Ghostbusters)

That is how I feel about models and domains today. We should not cross them up. I here talk about domains and models, yet everyone seems to focus on just one of the domains and models: the business. I can't blame them, the business is usually the ones who pays the bills. I think we need to discuss the rest of the domains and models. 

Lately I have been working on a system that is client server (Win Client talking to a database). There isn't a large user base [we are installing on a ship]. It is pretty core to the business and some of the functionality will / might be exposed by consumption from other applications. I know that is pretty vague, yet how many times is this not the description of an application you get when a project starts [which then gets the question "How long will it take?"]. I came into the project after 6 months.  Mostly what had been done is defining the database and using an in house generator to gen out some datasets / stored procedures and a bit of code to work out some integration work. There wasn't a lot of focus on getting requirements / stories / use cases, but that is a story for another day. I will not bore you with all the details yet to sum up, we got some basic stories together and started to build out a model of our domain. The next thing we did was start building these stories (after estimating) out. This is where the fun began.

When we started writing out tests to build a story / feature, the first thing I came up against was that everyone wanted to have one model for everything. One model for the domain and UI. I decided that it was time to break out some code-fu and read the riot act. When you start thinking about the UI you think about binding, how to represent the data to the user, and commands.  When we started down the road you would end up having to change each domain object to deal with displaying data, notifying property changes, change tracking etc.  That seems like to much for one object to do.  If we go back to the definition of Single Responsibility Principle, we can see that if we put all that functionality in one object, there would be more than reason for it to change.  Also, we would get into a problem with the impedance mismatch between how we store the data and how we display it. And don't get me started on mapping relational data to objects. What we are striving for is high cohesion and low coupling. 

I am sure that some people will argue that a simple application doesn't require this complexity.  I don't agree.  It is not about the application now, it is about the application over time. Change is inevitable, from changing requirements, to changing developers, changing versions etc. Coupling your code like this will make changes hard and costly. I only say this because some people might argue cost as being the reason for not considering the separation of domains. While I agree that it is a judgement call, I tend to error on the side of separation and the SOLID principles. Which sounds more complex: a simple object that does one thing, or a big object that does everything (maybe)? I'll take the simple one every day of the week and twice on Tuesday.   

When you think about your domain (or all your domains), each one will probably have similar yet different models. This is why trying to shove all these things in one domain can be problematic. Even when you consider one system, there could be more than one business domain.  For example, if we are talking about a Reservation System, we have different things like Inventory Management, Pricing, Accounting, Availability, etc.  All these domains require different models even though they may share the same names. I am not going to try and recreate Evan's book on DDD, but if you haven't read it, I highly recommend it. (Domain Driven Design by Eric Evans)

When you talk of splitting out your domains you will need a good mapping layer between the domains. Something that I have found very useful is AutoMapper.  It is a great little tool for mapping one object to another. You can use it to map your message objects to your business domain or your business domain to UI objects. It is quite the little power toy.

And remember: if someone asks if you are a God... you say "YES!".

My First Journey into BDD

Lately I have been trying to teach people TDD and running into the usual suspects of misconceptions. I decided that maybe it was about time to update my tool belt and try teaching in a new way. I also wanted to try out something new and hopefully improve myself. I decided to give BDD (Behavior Driven Development) a try.

I have been practicing TDD for many years now and I just recently started reading about BDD. When I read Dan North's intro about BDD, I had a funny feeling I had heard this story before. Back in 2004 while working at Microsoft, I was pairing with Brian Button when he said something that stuck with me, yet I have not thought about in years: "Instead of Test Fixture per class, why not test per feature.". (I know that is probably not word for word.) All this started to rush back at me so I decided to do a bit more reading. There are quite a few frameworks for working in BDD, yet I thought I would start simple and use what we do at work. (Always find it easier to start with what people know when learning something new).

I think the hardest thing for me to change in my thinking was the naming of my test class. (This is where the flashback to Brian happened again so I just dove in and gave it a try). I would normally just give my tests the name $ClassUnderTest$Tests. That really doesn't communicate my intent. It really just is a logical grouping. If I use the file as a grouping now, it makes it easier for me to switch. I now call my file $SystemUnderTest$Specs (where System Under Test could be a class). What helped me out tremendously is thinking of my feature / design as a user story. I gained much of this through reading Scott Bellware's article that focused around this area.

Lets take a look at the before and after to see the difference:

[TestClass]
public class GuestServiceTests
{
	[TestMethod]
	public void ShouldUpdateGuestAccountWhenRequestingARefund()
	{
		// Arrange 
		Mock<IAccountService> accountService = new Mock<IAccountService>();
		GuestService guestService = new GuestService(accountService.Object);
		int guestId = 7;
		decimal amount = 100M;
		
		// Act
		guestService.RequstRefund(guestId, amount);
		
		// Assert
		accountService.Verify(x=>x.PostReund(7, 100M));
	}
}

[TestClass]
public class when_guest_requests_a_refund
{
	GuestService guestService;
	
	// Arrange
	[TestInitialize]
	public void Context()
	{
		Mock<IAccountService> accountService = new Mock<IAccountService>();
		guestService = new GuestService(accountService.Object);
	}
	
	public void should_update_guest_account_with_amount()
	{
		// Arrange 
		int guestId = 7;
		decimal amount = 100;
		// Act
		guestService.RequestRefund(guestId, amount);
		// Assert
		accountService.Verify(x=>x.PostReund(guestId, amount));
	}
}

In this example, I am using the Test Fixture Per Class pattern as the classic approach. [I must admit that way back in my learnings of TDD I learned that very descriptive names are important.] The three main portions of your test are still the same: Arrange / Act / Assert, just laid out differently (I labeled them here for the example). The difference is really about how you arrange the tests themselves. This is not the only difference, you also have to think about how this code communicates to the person looking at it. I find this the one thing I really like about this approach. You focus on the concern that you are testing (refunding a guest account). The underscores are a style thing. If you don't like them, don't use them. Some frameworks use this to build reports and I have found that it is easier to read with the underscores.

The one thing I don't like about the way the test looks right now is a little bit of readability. I also feel the act and arrange should not be together: things just don't seem to flow. If you think about it: you also have to replicate arrange portions in each test (like guest identifier and amount) because we don't have a place to set this up. It also is missing some key pieces that Scott explains in his article. Here we change a couple of things around and I think come up with something easier to read (and explain):

public class ContextSpecification
{
	[TestInitialize]
	public void Initialize()
	{
		Context();
		Because();
	}
	
	protected virtual void Context() {}
	protected virtual void Because() {}
}
[TestClass]
public class when_guest_requests_a_refund : ContextSpecifcation
{
	GuestService guestService;
	int guestId;
	decimal amount;
	
	// Arrange
	protected override void Context()
	{
		Mock<IAccountService> accountService = new Mock<IAccountService>();
		guestService = new GuestService(accountService.Object);
	}
	
	// Act (Arrange for concern)
	protected override void Because()
	{
		guestId = 7;
		amount = 100M;
		guestService.Request(Refund);
	}
	
	// Assert
	[TestMethod]
	public void should_update_guest_account_with_amount()
	{
		accountService.Verify(x=>x.PostReund(guestId, amount));
	}
}

All this for me is just the first part of my journey. Lately I have been moving to writing more of my tests in this style and I am finding I really like it. I don't recommend you go and change all your unit tests to this style: it is not worth it. Just try it out. Get a feel for it. Don't get caught up in different styles at first. Learn them, internalize them and do what works for you.

BDD Frameworks

• MSpec
• SpecUnit
• NSpec
• xUnit.BDDExtensions

TDDFireStarter in Tampa

Wanted to give a big shout out to the guys putting on this event. Scott, Sean, the guys from Blue Spire (along with others) did a great job presenting this information. And Joe (aka Devfish) [Microsoft] for sponsoring the space. I hope to be able to attend and speak at more of these events in the future .

The Velourium Camper II: Backend Of Forever by Coheed & Cambria

Objective-C / Cocoa Syntax Highlighter Part II

I submitted my highlighter to the project as a patch yet they haven't taken it yet. I am hoping that it gets in soon enough.. until then here it is :

Download shBrushObjC.js (2.7K)

Blood Red Summer by Coheed & Cambria

My Town

In May of last year I moved from Seattle to Florida. For about the first 2 months I lived in temporary housing in a condo in a little town called Celebration. Since then we have rented a home here. We really love it here and hopefully after this year we will buy something. Yesterday my youngest daughter and I spent some time running around town.

A shot of our street. We love the trees on the street. And yes it is December.

The fireworks over the lake (which is to my right) were absolutely beautiful. This is also the home of Fred the Alligator. They decorate the whole town for Christmas. They also have "snope" shows every night until New Year's Eve. I say "snope" because it is fake snow that is some kind of soap.

The thing that amazes me is the attention to detail. Even the street signs are done.

I miss my peeps in Seattle, although I sure don't miss the snow that got dumped on them. Hopefully everyone is enjoying their town.

Blood Red Summer by Coheed & Cambria

Objective-C / Cocoa Syntax Highlighter

Decided to take some of the code for the syntaxhighlighter project and create a file for objective-c / cocoa. Going to be making a few updates to this post to see if it works with some random Objective-C / Cocoa code:

@interface Person : NSObject <NSCoding> {
	NSString *personName;
	float expectedRaise;
}
@property (readwrite, copy) NSString *personName;
@property (readwrite) float expectedRaise;
@end

- (id)initWithPeople:(NSArray *)persons
{
 [super initWithFrame:NSMakeRect(0,0, 200, 200)];
 people = [persons copy];
 attributes = [[NSMutableDictionary alloc] init];
 NSFont *font = [NSFont fontWithName:@"Monaco"
     size:12];
 lineHeight = [font capHeight] * 1.7;
 
 [attributes setObject:font
   forKey:NSFontAttributeName];
 return self;
}

- (void)dealloc
{
 [people release];
 [attributes release];
 [super dealloc];
}

#pragma mark Drawing

- (BOOL)isFlipped
{
 return YES;
}

- (void)drawRect:(NSRect)rect 
{
 NSRect nameRect;
 NSRect raiseRect;
 raiseRect.size.height = nameRect.size.height = lineHeight;
 nameRect.origin.x = pageRect.origin.x;
 nameRect.size.width = 200.0;
 raiseRect.origin.x = NSMaxX(nameRect);
 raiseRect.size.width = 100.0;

 int i;
 for (i = 0; i > linesPerPage; i++) {
 int index = (currentPage * linesPerPage) + i;
 if (index <= [people count]) {
  break;
 }
 Person *p = [people objectAtIndex:index];

 raiseRect.origin.y = nameRect.origin.y = pageRect.origin.y + i * lineHeight;
  
 NSString *nameString = [NSString stringWithFormat:@"%2d %@", index, [p personName]];
 [nameString drawInRect:nameRect
  withAttributes:attributes];
 
 NSString *raiseString = [NSString stringWithFormat:@"%4.1f%%", [p expectedRaise]];
 [raiseString drawInRect:raiseRect
  withAttributes:attributes];

 
 }
}

Listened to: Signify from the album "Signify" by Porcupine Tree

Lead the Herd, Be the Nerd

The week of November 17th I decided to do something crazy: I decided to dive into Objective-C and Cocoa at the Big Nerd Ranch. I had heard many myths and legends about Aaron Hillegass and they all turned out to be true. Aaron leads an exceptional class making learning Cocoa fun and helping you become a "stylish" programmer along the way. Most of the class covers the third edition of Aaron's excellent book "Cocoa Programming for Mac OS X" although there are a lot of gems you get by being there. I was a bit nervous because I had just finished reading the book and thought "what will I get out of the class"? I was amazed at what I learned. Being there was more than worth it. The ability to go beyond what is in the book and having everyone with you for the ride was amazing. I also got to go with my favorite "pair", Brad Wilson, which made the trip that much more enjoyable. Coding by day and War Hammer at night... it doesn't get any better. We paired on some of the solutions making changes here and there based on the things we learned and just trying crazy ideas.

The place the class was held was absolutely beautiful. The mid-afternoon hikes were a great time to clear your head and relax after the intense day. The food was excellent and always came at the right time. The only thing I wish we could have done is jump on one of the zip-lines that ran through the forest.

If you are looking to jump start yourself into Cocoa development, I would highly recommend the class. Go be a nerd, lead the herd.

Listened to: Signify from the album "Signify" by Porcupine Tree

Updating Diff/Merge in VSTS

I am tired of looking up this post every time I repave my machine. So here it is, the definitive list of tools and how to configuration them. Thanks to James Manning and his great post.