Dispatches from DevTeach Vancouver

DevTeach in Metrotown 

A few months ago, my company offered me the opportunity to choose a software conference to attend. After browsing some conference listing sites, I chose DevTeach Vancouver, despite it's hokey website. I've had enough of Las Vegas -- it also had an impressive and relevant session list. I hopped a train in Seattle with my bicycle. From the Vancouver station, I rode on Vancouver's amazing network of bike trails to the conference 10k out in Metrotown, Burnaby.

Metrotown is ... eclectic. A substantial Asian mall -- almost a proper china town -- called "Crystal Palace", was attached to the conference hotel. (Great food, there). Metrotown boasts one of the Vancouver areas largest shopping malls. I got lost just finding my way back from the restrooms. For a break from the bustle and commercialization, I could easily ride my bike to two substantial parks. Deer Lake Park surprised me. Riding down through suburban sprawl, I discovered kilometers of wetland trails and boardwalks around a beautiful lake. I tried not to run over the goslings huddled on the trail.

(Insert picture here when I get to a computer with some image editing software.)

Some memorable anecdotes from DevTeach

“Objects are the way God thinks!”  Ted Neward in his multi-paradigmatic C#.

"If I looks like a duck, quacks like a duck, and eats batteries, you probably have Liskov violation." Joel Hebert, from his presentation on Design by Contract.

Don't borrow men's phones was the most important lessons learned from Tom Lewis in his talk about Responsive Web Design. Liberally paraphrased: "We shouldn't assume that mobile devices are something you use when walking to a meeting ... when asked where they used their phones, 80% of men admitted to using them on the toilet." ( Where and how people use their mobile browsers was relevant to an argument that we should use same site for mobile devices as their main site. Increasingly people use their phones like their computers. ) 

Dispatch 1: Design by Contract (and how to use it without Visual Studio Ultimate)

Joel Hebert started his discussion with a review of SOLID, including the most memorable description of the Liskov Substitution Principle, which I have only been able to explain for 5 minutes after reading more formal definitions. That was the ducks, above.

Contracts have been a first class construct of the .Net framework since v4 (we can say "since v4" now the 4.5 is coming soon). How does this relate to the Liskov substitution principal? It is quite difficult to implement a class hierarchy that adheres to Liskov-- where derived classes can substitute for base classes -- without Contracts. The best tech speakers also know that if the open with clever descriptions of comp sci concepts, they'll get there audiences attention.

You can read about code contracts on MSDN. What contracts provide are enforcement preconditions, postconditions, and invariants. You can apply contracts on an interface in the style of aspect oriented programming.

Why is this cool? Quality! It makes discovering and preventing defects much easier. Code that calls a method with an invalid value would get caught at compile time via static checking. How many basic validation unit tests would that make unnecessary? Manual testers, system and integration tests that stumble over contract violations will get a very specific error.

While you can annotate your code with contracts with just the v4 SDK, they won't do anything. One tool provides static checking of contracts at compile time (cccheck.exe). That is, it looks for contract violations that it can see in the code, and spits out warnings. Another rewrites the IL to inject the contract assertions (ccrewrite.exe). This throws exceptions if a contract violation occurs in your running code. Visual Studio Ultimate Edition gives you a nice UI to configure this. 

Oh, you don't have Visual Studio Ultimate? Joel did. Too bad I only have Premium. According to documentation, any edition other than Express should show this property pane, but I have only seen it in Ultimate editions. Fortunately, we are all hackers here. I've posted an explanation and example of how to leverage Contracts with lesser versions of Visual Studio using the build targets. This is probably not violating any licenses, as it the pretty UI you are paying for. Without it, you have to edit the build files yourself.

https://github.com/cliffburger/Samples/tree/master/DesignByContract 

A warning about the static checking and compilation. It increased the build time for a tiny project from 1 second to 12 seconds. I could execute a lot of unit tests in that time. 

Dispatch 2: You don't need to design your code well if you are filthy rich

Ah, the advantages of being rich. Schooling, buying laws, poor folk have to design code well to unit test it. They put interfaces around expensive components, use Dependency injection, and replace them with mocks or stubs using open source tools such as Rhinomocks or Moq. If you've got money, you don't need to do that.

Mocking frameworks that are based on the .Net profiler API can mock any class or method, including static and framework methods. We've created our own Time implementation, so that we can control the time in our unit tests. Mocking frameworks that use the .Net Profiler API could even replace the return from DateTime.Now. However, you pay quite a bit.

• Moles from Microsoft (this is the only one framework that you don't have to pay extra for, but it is extremely awkward in its current incarnation).
• JustMock from Telerik ($400 each)
• Isolator from TypeMock ($800 dev + $2500 build server. We have 20 build servers. I hope there is volume licensing.)

Here is what pressed my button: the presenter suggested that these have the advantage that you did not need to use dependency injection and IoC containers to enable unit testing. He argued you using DI and IoC to enable unit testing is bad, because New() is faster than IoC resolution. While IoC resolution is in fact slower, this is irrelevant. You shouldn't resolve in a tight loop. We typically create interfaces in front of components  where the call is expensive, significantly more expensive than new(). File systems, databases, web services, and so forth. There are many other reasons that dependency injection plays a part in good design, and many other reasons to have a layer between your code and its dependencies.

(Is it obvious that I let a red herring distract me from the content of an otherwise well delivered presentation?)

There are few cases, such as DateTime.Now, where the capability to mock the behavior of statics is nice. For everything else, these tools allow developers to unit test poorly written code. While the I'm don't think these tools are worth the price, people who write terrible code have a right to test it, too.

More later (maybe)

I covered a lot of ground at my time at DevTeach, and I'll post more later. I also reserve the right to got back to my regular life and not post. 

• The first day had a Windows 8 promotion key note.
• Design patterns for web services. Moving to Resource APIs. I finally grok Hypermedia as the Engine of State. 
• Several presentations on NOSQL, including some discussion of why defining some by what it is not is nonsense. Volvos, dogs, and my left foot are also not SQL.
• You can write C# in 5 paradigms.
• Source control branching, Shared components, and deployment
• I went to several HTML presentations and an MVC presentation. While I once (1990s) worked a lot in HTML, I have only dabbled in the last decade. I now feel inspired to dabble more dabblishly. Maybe I'll write a complete HTML app in couchdb while sitting on my futon. Apparently, you can write data tier, service tier, and presentation tier in one process!
• I refreshed my knowledge of Scrum and estimation. Always good to review the basics.
• Kinect for windows is cool ... but still definately v1.
• I got schooled by Kathleen Dollard on .Net Geeky stuff. 

I'll send this post to my mother and father. They also say they don't really know what I do.