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. 

If heat rises, why is it colder at the top of mountains?

This blog will not answer the title question, but answer a much more relevant question: how and why should we hunt knowledge every day. It is inspired by my son, who asked the question and James S Bach’s “Secrets of a Buccaneer Scholar”.

First, about my son, then about James Bach. At six, my son loves science. Every time he asks questions like “why is the sky blue?” and “how long would it take to drive to the moon”, my wife and I dig into the answer with gusto. He loves math for much the same reason. We revel in his curiosity and encourage it. I have learned a lot teaching him.

Now, about James Bach. I found his book while looking for books about Software Testing. While James Bach also writes books about software testing, this book was about learning. It describes how, after dropping out of school with only an 8th grade diploma, he learned Assembly Language Programming, became a software tester, and now consults other software testers. It was his habit of self-education that gave him the edge over his college educated competition.

I’ll elaborate on just a few of his “great secrets”.

To learn something, it should be relevant. He calls these Authentic Problems. While I’ve studied several foreign languages in school, the 2-3 that I speak well I learned while living abroad, and are not the languages I learned in school. Likewise with software. The most useful software knowledge that I’ve gained has been because I needed the knowledge at work to solve a problem. I take the problem home and beat it into submission.

Cognitive Savvy. You have to understand how you learn. Everyone will learn differently. I learn well by processing things in multiples ways. For example, this blog entry will be my Toastmaster’s speech Tuesday. I know that I often fragment ideas as I restructure on the fly, so I videotaped myself reading it to ensure it flowed well.

Other minds. Woodrow Wilson said, “I not only use all the brains that I have, but all that I can borrow.” Bach refers to hunting knowledge in packs. I refuse to work alone because I want the ability to come up with crazy ideas. Some will be brilliant, some will be chaff. Other minds attacking my ideas allow me to be brilliant.

I will conclude by how I answered my son’s query: I dove in and made up a plausible answer on the spot. Diving in is always the first step across a river. Perhaps I could have solved it on my own, but I thought it would be more fun to hunt down the answer with my pack of friends and relatives. The most amusing answer was, “Because you’re further away from hell.” The most thorough and correct answer came from my brother, who has climbed all of the 14ers in Colorado. This was a very authentic problem for him. Now that I know the answer, I’m trying to understand it well enough to explain it to my six year old son. Finding the answer was a great hunt.