Bill Blogs in C#

Speaking announcement: ThatConference

Thu, 23 May 2013 19:18:17 GMT

I’m a bit late getting this up. It’s been one of those months. I’m attending and speaking at my first ThatConference this summer.

My talk is on the dangers and misuses of void returning async methods in C# 5. I’ll discuss the problems with that practice, and go over some of the practices that can be used to avoid that practice. It’ a wicked strong lineup of speakers and content, and I do hope you can make time to attend my talk.

I’m also going to be running a hackathon/GiveCamp for the Humanitarian Toolbox. Right now, we’re working with disaster relief experts to pick the right project. If you want your software to make a difference the next time there’s a natural disaster, like the tornados in Oklahoma this past week, come to ThatConference the 10th and 11th to participate. Write some code. Change the world.

Humanitarian Toolbox Hackathon at DevTeach

Mon, 20 May 2013 20:19:15 GMT

The Humanitarian Toolbox is hosting its next Hackathon at DevTeach in Toronto.

DevTeach is a fantastic community-led conference that is celebrating its 10th anniversary this year. Many of my friends in the MVP and RD communities are speaking there. It’s a fantastic way to learn more about software development, and grow your skills.

This year, you can give back as well.

You can spend one evening (May 30th) using your skills to build software that makes relief workers more efficient when disaster strikes. Attend the Humanitarian Toolbox hackathon at DevTeach. Help build the next generation of life-saving tools to meet the needs of relief workers. Your skills can save lives.

We held our first hackathon at DevIntersections in April. (You can read about the experience on my previous blog entries). We’re hoping to build on that momentum during a number of conferences this summer. DevTeach is our first chance to grow more. Richard Campbell (yes, that Richard Campbell) will be hosting this hackathon. If you are going to DevTeach, please join us.

scheduling note: Due to family events (happy ones), I can’t make this conference. I’ll be at other upcoming events later this summer and fall.

Humanitarian Toolbox: Day 2

Thu, 11 Apr 2013 20:51:52 GMT

Awesome. There's no other word. This was positively awesome. On the 10th, we built on the foundation we created on Tuesday. We spent the entire evening coding. The event was supposed to end at 10:00. Everyone asked for "15 more minutes to finish a couple cards". Two hours later, at 12:30 am, we finally left. The best part was that we had finished the key features we came to build. Tony Surma, Microsoft's CTO for disaster relief response said, "if a disaster hit tomorrow and I deployed this, it would get used already. It's better than what's in the field today." A lot of credit goes to some very dedicated people. First and foremost, credit goes to the conference attendees that were part of the hack a thon both nights. We didn't know what to expect, and as a result, we'll plan better in future. The folks were patient, and helped us drive the forward. We got great ideas, lots of energy, and most of all: Working Software. Also, a quick tip of the hat to Aaron Skonnard and Pluralsight. Everyone that participated by making at least one checkin got a free month subscription to the entire Pluralsight library. Selfishly, I hope they learn more, and help us build more software for Humanitarian Toolbox. (Disclosure: I'm working on my first Pluralsight course.) Brian Randell did a lot of behind the scenes work to setup web hosted TFS for us. He also helped us test and work with the Git TF bridge so attendees could use whatever they felt most comfortable with. (And, he helped me get more familiar with TFS and it’s features. He was a great help.) Three people deserve extra thanks: Ward Bell, Julie Lerman, and John Papa. The team wanted to apply what they were learning at the conference, and selected breeze, HotTowel, and Entity Framework Code First for this project. John, Ward, and Julie all gave up quite a bit of time to help. They paired with attendees, explaining as they coded, or guiding their pair (sometimes me) around the code and libraries involved. Pure bliss: Learning and building super useful software at the same time. For examples of what they did, John told me he and Ward would "try to stop by for about 10 or 15 minutes" to help a bit. They were both helping for at least two hours. Julie stayed until she was in jeopardy of missing her flight. (She did make it). We had quite the cast of characters show up and ask how they can get involved as this continues over time. At future events, you may see Phil Haack, Scott Hanselman, Damien Edwards and other familiar names helping out. All of those said they would have helped this time, had they known more about it earlier in the process. I can't close this "thank you" section without mentioning three other very important people. Mari Sessions took on every task that doesn't involve code (she's got a business background, not a developer background). I have no idea where she gets that much energy. She organized the room, promoted the event, walked up and down the halls asking random conference attendees if they wanted to participate. Arranged refreshments, made everyone feel welcome, and made the event happen. Tony Surma, Microsoft's CTO for Disaster Relief, kept us focused on the problem at hand. He's gone to disaster sites and written code while in the field. His experience and knowledge of disaster zones and the problems relief workers encounter in the field was invaluable. I'd be remiss if I didn't mention that he's also a super smart tech guy, and can just pitch in and make things work. Also, an extra hat tip to Microsoft. They are providing free TFS hosting, Azure hosting, and other help supporting the effort. Furthermore, they are not mandating any technology decisions that we make. They are being a great partner to help us build software to solve real problems. And finally, without Richard Campbell, this doesn't get off the ground. I'm thrilled to be working with Richard on this. The reason is simple: when Richard gets behind an idea, things happen. Ideas turn into action. Tony started using the phrase "turn innovation into impact." That sums up Richard's contributions well. What we started only has meaning when it gets in the hands of real relief organizations during a (sadly) real disaster. When that happens, real lives are saved because those relief workers can do more. Richard brings energy, drive, and makes it happen. I'm glad he invited me to join. Finally, this last week can't be a one time event. It's got to be the start of long term commitments to create software that helps relief organizations respond to disaster events. Richard, Tony, Mari and I will be meeting in the coming weeks to go over what we learned. We're going to push code into release cycles. We're going to plan more events. We're going to create a plan to involve more people. Join us: When disaster strikes, code saves lives. If you're interested, signup at humanitariantoolbox.net and well keep you informed.

Humanitarian Toolbox Hack a thon, Day 1

Wed, 10 Apr 2013 16:23:43 GMT

I’m really happy with the response we got from the first night of the Humanitarian Toolbox hackathon at DevIntersections. We’re creating innovations that have a real human impact. We didn’t really know what to expect. Would conference attendees give up a free night after a day of learning new technologies to build more software? Thankfully, the answer was yes. We had a great team of developers helping us start building a crisis checkin system for disaster relief workers. I’m confident that if we get some of the right people to attend tonight, we have a chance to make significant progress on the user stories for our first sprint. It was great to see developers that hadn’t even met each other sit down, discuss designs, create code, and help us build software to make disaster response more effective. There were three key events that make me very excited about where this can go:

We were starting from nothing, and this morning we have working software.
The folks that came wanted to apply what they’ve learned at DevIntersections to this project (more below).
We continued to get commits after we all left at 10:00 pm.

One of the main sessions yesterday was JavaScript Jumpstart, where he explained his HotTowel template to attendees. Our first app is using the HotTowel template. Thanks to John Papa for creating a great framework, and inspiring the team. The big goal is that this is the start of something. It’s not a one time event. We need to continue building software, creating real applications that real relief workers have asked for. We’re using innovation to create real impact in real disaster situations. We’ve got another session tonight at DevIntersections, where we plan to finish the user stories that are in progress. If you’re at DevIntersections, please come by and help. If not, don’t worry. After this hack-a-thon, we’re going to open the source control system and the task board to everyone. We’ve got a few tasks to get done to make that happen, but we’ll get it done. Overall, I’m really impressed with the beginning we made. I’m constantly impressed by the commitment, dedication, and contribution the software development community will make. We are asking developers to give up their free time to build software that aids relief workers. We are getting great response. I’m excited to see what we’ll build next.

Write Some Code, Change the World

Thu, 28 Mar 2013 19:50:04 GMT

I've always found that developers are very interested in contributing their skills and their time to help others.

I'm excited to be part of a new opportunity for developers to help others: The Humanitarian Toolbox.

The Humanitarian Toolbox is the brain child of Richard Campbell, of .NET Rocks fame. The concept is to have developers create Open Source software projects that solve real problems for disaster relief organizations. A group of people, including Richard and I, have been working with global relief organizations to determine what they need most. We've already got a list of more than a dozen application ideas.

It's time to start building. We've picked the first project: a relief worker check-in system. This system would enable relief workers and volunteers to check-in and check-out at a disaster site. The field coordinators would have better information about the skills and the availability of relief workers, enabling them to better deploy the people that have volunteered their time to help. Relief workers and volunteers would get assignments and locations directly on their smartphone. The end result will be that relief workers are more efficient while on site, and more lives are saved.

We need developers that want to build this app.

Humanitarian Toolbox is hosting a hack-a-thon at DevIntersections. I'm working to organize the event, and help organize developers (like you) interested in participating. We plan to create a small proof of concept for the relief worker check-in system during the hack-a-thon. After the initial hack-a-thon, we want to enlist the broader community to continue building the app.

What's our deadline? We'd like it in place before the next natural disaster happens. We don't know when that will be, so we'd like to keep building and have it ready as soon as we can.

If you're going to be a DevIntersections, join us. Contribute your talent and help relief workers save lives. If you're not going to DevIntersections, there's still plenty to do to help. Follow us on twitter: @htbox or the hash tag for the event: #HtBox. We'll have plenty more software to build after the hack-a-thon. For us to be successful, we'll need to keep building and enhancing software for relief workers to battle the next crisis.

Write some code, help the world. Contribute to Humanitarian Toolbox.

Async, Exceptions and Library Design

Tue, 05 Mar 2013 16:49:13 GMT

Hat tip to Stephen Toub for discussing this with me and helping to describe the solution.

At my CodeMash precompiler, I mentioned how the C# compiler ensures that methods marked with the 'async' keyword that contain 'await' expressions never throw synchronous exceptions. Instead, those methods will return a Task (or Task<T>) that will be placed in the faulted state if the method throws an exception. The compiler does the work to add the appropriate try/catch clauses to your methods, and translates any exceptions thrown during your method's execution into returned faulted task.

Jon Skeet was concerned by this strategy. He felt that API designers would prefer throwing synchronous exceptions for obvious programmer errors (things like ArgumentNullException and so on). I mentioned that the language specification defines that async methods will returned faulted tasks; they will not throw synchronous exceptions.

Of course, there is a way around this. You have to separate your public async APIs into two pieces: A public synchronous API that does parameter validation and state validation. This synchronous method then calls an internal async method that does the asynchronous work.

As an example, consider this (rather contrived) async method:

      
        
          
            
public
          
        
         async Task<string> FizzBuzzAsync(int val)

{

    if (val <= 0)

        throw new ArgumentException("We can't fizzbuzz negative numbers, or 0");


    await Task.Delay(250);

    var rVal = string.Empty;

    if (val % 3 == 0)

        rVal += "Fizz";

    if (val % 5 == 0)

        rVal += "Buzz";

    if (string.IsNullOrWhiteSpace(rVal))

        rVal = val.ToString();

    return rVal;

}

Calling this method with a negative number is a programming error. We'd like to have that condition throw a synchronous exception. We can achieve this by separating the method into two parts. The first part is a synchronous method that performs the parameter validation and state validation. The second part is an internal method that performs the asynchronous work. The first method will throw exceptions synchronously. The second will report errors using a faulted task.

      
        
          
            public
          
        
         Task<string> FizzBuzzAsync(int val)

{

    if (val <= 0)

        throw new ArgumentException("We can't fizzbuzz negative numbers, or 0");

 

    return FizzBuzzAsyncImpl(val);

}

 
private static async Task<string> FizzBuzzAsyncImpl(int val)

{

    await Task.Delay(250);

    var rVal = string.Empty;

    if (val % 3 == 0)

        rVal += "Fizz";

    if (val % 5 == 0)

        rVal += "Buzz";

    if (string.IsNullOrWhiteSpace(rVal))

        rVal = val.ToString();

    return rVal;

}

That ensures that your public async methods conform to both important rules.

First, TAP (Task Asynchronous Pattern) methods do not allow synchronous runtime exceptions. They must return errors by returning a faulted task.

Second, to make it easier for callers to detect and correct programming errors, simple programming errors will throw synchronous exceptions.

MVP Summit Recap

Fri, 22 Feb 2013 17:04:02 GMT

Let me start by saying that much of the content at the Microsoft MVP Summit is covered by the NDA MVPs sign with Microsoft in order to participate in events like the summit. This recap necessarily leaves out any information that was covered under the NDA. Specifically, as a C# MVP, much of my time was spent with the C# and Visual Studio teams. There is a tremendous amount of work going on in those areas. I'm not blogging about any of those sessions, because all of those were NDA sessions. My silence on the future of C# is for that reason and that reason only.

There were a number of sessions and discussions around the async features added to C# 5. It was really valuable spending that much time with Stephen Toub and Lucian Wischik discussing common mistakees people make when writing async code. In addition, Lucian and Stephen gave solid, actionable recommendations on good practices for async programming. I say 'good practices' not 'best practices' because these features are new enough that it's a bit arrogant to think we've figured out what's 'best'. We have good ideas, but they will still evolve. One of the async presentations was not covered under NDA, and Stephen has posted it on the pfxteam blog. I really like Lucian's explanation here on the state machine and event-based async programming (slides 23-25). This is a great explanation and example on how async, await, and the Task Based Async APIs can enable you to write async code that much more clearly represents your designs.

Test your own knowledge and take the async quiz at the end of the slide deck.

You probably saw the announcement on Git support in Visual Studio. There were a lot more discussions on Open Source development at Microsoft. Publicly, you can see the Azure support for Node.js is Open Source. ASP.NET MVC development is open source and accepting contributions from the community. For the past several years, there are more and more Open Source announcements at the MVP Summit, and those are always welcome news. I do hope it’s a trend that will continue, and next year's Summit brings even more announcements.

Like every conference, the Hallway Track is always valuable. Other MVPs have other focus areas. Even in SRT Solutions, Patrick Steele and I are C# MVPs, and Dennis Burton is an Azure MVP. It's incredibly valuable to discuss different areas of development with so many smart people from all around the world. The hallway track is where I can ask questions about ASP.NET development, Azure, Windows 8 development, XAML, and all the other areas I understand, but not as well as I do the C# language. I also get to catch up with the future of Visual Studio's ALM tools. (See Git Support above, I'm happy with what I learned).

Finally, a world wide conference with a bunch of developers can make you feel very hopeful about the future. Different regions show their pride in their home with what they wear. All the Canadian MVPs have Team Canada hockey jerseys. (I have one. It's a gift from Peter Ritchie, so I'm an honorary Canadian). The Brazilian MVPs wear Team Brasil football (soccer) jackets. Russian MVPs have Russian Olympic warm up jackets. It's all in fun, and great conversation starters. There are social events every evening, where we can chat with old friends and new acquaintances from all over the world. The final night was another attendee party at Century Link field. The organizers had setup one end for soccer and the other for American football. I learned a bit more about "real football" from some European friends, and taught a few of them how to throw a tight spiral with an American football. And, of course, there were bands and rockeoki (kareoke but with a live band) on the concourse. The quality of the singers varied greatly, but we all had fun. I’m sure some embarrassing YouTube videos will appear shortly.

I can't wait for next year.

2013 Investments: Continuous Client Experience

Wed, 20 Feb 2013 17:23:06 GMT

In this post, I'll drill a bit into the final of the 3 areas SRT is investing in for 2013: Continuous Client Experience.

Users are now expecting that their experience, their work, and their data follows them from one device to the next. It's not enough to have a presence on mobile, web, and desktop. It's important that users have a seamless experience as they move from one device to the next.

One high profile example is Netflix. I can start a movie on my laptop. When I get home, I can switch to my Roku and have the movie pick up in exactly the same location. My picks are the same on my phone as on the living room device. We just expect that experience to move from device to device.

OneNote provides similar behavior as a productivity application. My notes automatically sync in the cloud. As I move from machine to machine, or to my phone, all my data just follows. The newest version of OneNote doesn’t even have a “save” command. My work just moves to the cloud on a regular basis.

All the applications we are now writing for business users demand the same kind of synchronization. It's driving several design decisions.

We're putting data in the cloud, where it's accessible from multiple devices. We're putting more effort into how we synchronize data. We're putting thought into server side data crunching and client side rendering. We're designing applications that have more and more of their algorithms in the cloud. That lets us develop more and more of the functionality for a single server platform. Each client has a smaller footprint and less device specific code. That lowers the cost of creating a great experience on each device. Finally, we're investing in making great offline experiences that synchronize data when the device notifies applications that a network is available.

Put all these areas together, and we believe we're well positioned for an exciting 2013. There are major shifts underway in our industry, and we intend to stay at the forefront.

2013 Investments: Single Page Applications

Mon, 18 Feb 2013 15:41:40 GMT

As I wrote last week, Single Page Web Applications are another area where we're investing in 2013. The term "Single Page Web Application" is probably familiar to most of my readers. But, for those that are not, wikipedia defines Single Page Applications as:

A single-page application (SPA), also known as single-page interface (SPI), is a web application or web site that fits on a single web page with the goal of providing a more fluid user experience akin to a desktop application.

You've probably used this type of application already today: Gmail, Facebook, and Outlook.com are all common examples. The latest version of the Azure developer portal is another great example of a Single Page Application.

These application types bring a desktop-like experience to web applications. Users do not have their workflow disrupted by pauses while the application posts to the web server and redraws an entire new page of content. Of course, these applications do send requests to the server, and receive new data. What's important is that these applications do that work using client-side code. These applications provide a true stateful application experience to the user. The web now becomes more of an application platform.

Single Page Web applications provide the mechanisms to give your users a better experience when using a browser based application. You'll see more and more adoption of these techniques, and the companies that adopt them well will be the companies that succeed in the marketplace.

We're making strong investments in this area to help our customers leverage these techniques. We've even launched a self-guided training lab: Choose Your Own Application so that developers can learn more about the toolkits that can be used to create these modern applications.

Our view on the mobile market

Fri, 15 Feb 2013 22:27:21 GMT

Last time I gave an overview of the areas where we’re making significant investments in 2013. In these posts, I’ll go into some detail on each of the areas where we’re investing. This is somewhat difficult, because our view is that all these areas work together to provide the right experience for users and customers. I’ll return to that in my final post on our investments this year.

The first area I mentioned was Mobile. Mobile applications help you reach your customers in more places and for more time. Your customers are on the move. They are using multiple devices. To deepen your relationship with this customers, you need a quality presence in all the places your customers are.

But, creating a mobile presence isn’t simply recreating your entire application presence on a phone. If you’re going to smartly leverage Mobile, you need to reimagine your application, or your web presence in terms of a mobile device.

The main goal of a mobile application is to reach your customers where ever they are. The only way to succeed in that is to reach them with what they want to do when they have that device. Are they going to do the same tasks they perform when at your website? Or a subset? Or are there tasks that only make sense when they are using the mobile device?

We try to create mobile apps that have these properties:

It provides an authentic experience on the target platform: It fits on the device.
It grows the customer’s relationship with the brand: Customers want to spend time with it.
It adds value because it is native to the mobile device: Mobile users can do things desktop users can’t.

Only when a new mobile application exhibits these properties does it justify the investment. We don’t create mobile apps just to mark the checkbox. They must provide true value on the platform.

SRT Technology Investments for 2013

Mon, 11 Feb 2013 19:06:03 GMT

At SRT, we continuously examine the overall technology landscape and make decisions on where to invest more time, what should stay the same, and what should be getting less investment. The change is actually quite fluid. We are always looking at what can help our customers achieve their goals, and what technologies seem to be getting less emphasis in the future.

But, the beginning of the year seems to be the right time to make a statement for the coming year. Here goes:

We’re seeing three areas that deserve big investments this year: Mobile, Single Page Web Applications, and the seamless integration of user experiences.

Let’s start with mobile: We’ve been building mobile applications for years, and demand continues to grow. There is obvious growth for iPhones, iPads, Android Phones, and Droid tablets. Windows Phone 8 and Windows 8 tablets are adding strong competition as well. There are a number of questions relating to how much market share each of these platforms will enjoy. But there is no question that the overall market for mobile software is growing, and growing quickly.

But mobile is only half (or one third) of the story.

Our customers demand that users access applications from their main computer as well as from their mobile device. Modern web applications, termed “Single Page Applications” behave more and more like desktop applications everyday. Facebook and Gmail are the two most popular examples. These web applications provide an almost native experience in the browser.

This gets to the final and encompassing strategy decision: Applications we’re building now must be available to users on any device, at any time. Data must be available on the web, on mobile devices, or on the desktop/laptop. The best apps can move seamlessly from device to device. That requires building applications that are part mobile, part web, part cloud, and always available from anywhere.

We’ve positioned ourselves to build those applications. We’ve got strengths on mobile platforms, web platforms, cloud platforms, and most importantly, building applications that span those different environments.

In my next few posts, I’ll go into more detail on each of these three topics: why they are important, and how to learn more about each of these topics. In the meantime, what do you think? Are these where you’re investing? Do these ideas represent the kinds of applications you want to use? Leave comments.

Assert.ThrowsException for async lambdas

Wed, 30 Jan 2013 22:16:06 GMT

UPDATE: Jake Ginnivan pointed out an inefficiency in my code below. I was awaiting the async method under test twice. As I mentioned a couple blog posts ago, I want to write tests that provide reasonable examples for users of my libraries. I expect developers to copy my tests as example code and modify it for production code. That can be tough for async tests when the async method should throw an exception. Well, as I was busy laying the background, Phil Haack leaped ahead to the punchline in his recent blog post. My own solution was a bit different: public static async Task ThrowsExceptionAsync<TException>(Func<Task> func) where TException : Exception { try { await func().ConfigureAwait(false); } catch (TException) { return; } Assert.Fail("Delegate did not throw " + typeof(TException).Name); } And you'd use it like this: await ThrowsExceptionAsync<ArgumentException>(() => worker.GetMessage(" ")); Note that the worker.GetMessage() does not need to be awaited here, because it is awaited in the ThrowsExceptionAsync method. Most of the differences between my version and Phil’s are due to the fact that I didn't use any xUnit specific features. However, one part I will discuss in a bit more detail. Note the ConfigureAwait(false) extension method when calling the async method under test: That instructs the framework to avoid the extra work of marshaling the continuation (the code after the await) onto the calling thread. This is a good practice for library code that does not need to have its continuations execute on the UI thread. I'll discuss this in more detail in a future blog post. There's also a few big picture concepts to get across on this post. The first key practice is that that async methods should return Task, not be void methods. If your async methods are void returning, you can't determine if your async methods worked correctly, or failed. By returning Task, you can query that Task (or let the compiler generate that code) to determine if it succeeded, failed, or was cancelled. The second key is that you should await for the result of any async method that returns a Task or Task<T> (even in a lambda). That causes the compiler to generate all the code to check that returned Task and ensure that it completed successfully. If it completed in a faulted state, the compiler generates code to throw the exception during the continuation. Finally, don't Wait() for Tasks to finish. await tasks. The compiler generates much better code to handle continuations when you await. And, that code is asyncrhonous, not synchronous.

Effective Writing guidelines from Scott Meyers

Fri, 25 Jan 2013 16:35:35 GMT

I try not to write posts that are simply links to other posts, but I had to make an exception for this. I was quite happy to see Scott Meyer's post on writing an effective effective book earlier this week. I received an earlier version of this advice almost a decade ago when I first worked on the proposal and outline for Effective C#. That advice, and all of Scott's additional advice and counsel made all the books I've written for the Effective series better. His guidance and advice are a key reason why the Effective Series books are so successful, and so well-received. The the authors in the series receive this advice, and receive constant feedback on the content, the form, the advice, and the style that goes into an Effective book.

The advice I got from Scott helped in many areas beyond writing that book. It has helped me become better at writing in general. I'm also better at explaining difficult concepts when I'm speaking to developers, or in meetings with other technical leaders. I remember several review comments from Scott on my first manuscript that started, “I don’t know C# very well, but this doesn’t make sense to me. Will your readers understand this?” It made me rework several explanations for greater clarity, and to be more complete.

If you're thinking of writing a book, you must read this post. It contains many nuggets of information that will help you reach your audience. You'll explain your points more clearly, and you'll justify your arguments much better. Your writing will actually accomplish its purpose.

Even if you don't plan to write a book, you should read this advice. If you work in technology, and you ever explain difficult concepts to coworkers, managers, customers, or others, this information is very useful. You'll be more effective at work, and your advice and counsel will be taken more often.

If you've enjoyed the books I've written for the Effective Series, this post gives you a glimpse at Scott's advice to make those books as useful as they've been. It’s invaluable advice. Read it. It will help you as much as it helped me.

Testing async Methods in C# 5

Mon, 21 Jan 2013 19:38:43 GMT

Last week I promised that I'd write a blog post on using Assert.ThrowsException() to test async methods. Before I get to that, let's go over some of the other issues that come up with testing async methods. First, let's look at a test to verify that an async method works correctly: public async Task<string> GetMessage(string user) { return await Task.FromResult(string.Format("Hello {0}", user)); } One test that works could be written like this: [TestMethod] public void SimplePathTest() { var worker = new Worker(); var answer = worker.GetMessage("unit tests").Result; Assert.AreEqual("Hello, unit tests", answer); } I don’t like writing tests like that. Calling “.Result” on a task is a code smell. The test method blocks until the result is available. That’s probably OK in a test method (more on that in future blog posts), but I’m still concerned. Developers often copy code from unit tests into production code. (I’ve done it myself when I’m learning how a library works.) For that reason, I want my unit tests for follow the practices I would use in production code. That means I want to ‘await’ the result, not block for it. You might try reworking the test like this: [TestMethod] public async void SimplePathTest() { var worker = new Worker(); var answer = await worker.GetMessage("unit tests"); Assert.AreEqual("Hello, unit tests", answer); } You’ll see one of two results from this change:

You may see that test disappear from your list of unit tests.
You may run the test and find that results are not reported for any code that follows the first ‘await’.

I actually prefer the first, because you’ll quickly figure out that there’s a problem. The problem is that you have an async method that has the void return type. There’s no Task returned for the test runner to examine for any exceptions that were thrown. If your test fails and the Assert expressions throw exceptions, no code is there to receive the exception and report the test failure. If you are using MSTest, or XUnit, you can fix this problem by declaring your async tests with the Task return type: [TestMethod] public async Task SimplePathTest() { var worker = new Worker(); var answer = await worker.GetMessage("unit tests"); Assert.AreEqual("Hello, unit tests", answer); } That’s it. Now, your async tests are using the idioms that you’d want people to use in production code. Above I mentioned that this idiom is supported for XUnit and MSTest. NUnit 2.6.2 adds this support as well. I haven’t had the chance to work with the latest version yet. I’ll write more blog entries about NUnit support for async tests as I work with them. Next time, I’ll finally answer that comment about how to test async methods that throw exceptions with a ThrowsException<> style expression.

Scrum and multiple project teams

Wed, 16 Jan 2013 12:36:23 GMT

One of our customers is grappling with how to manage a scrum process that involves multiple teams with multiple responsibilities. The larger organization produces a number of business applications, all built on a common library. They have teams for each application, and a framework library team.

I thought our recommendations would be of general interest, so I’m posting them here. This is still a work in progress, so I'd appreciate any thoughts from my readers.

Sprint Meetings

We recommended moving away from a process where every team attended one large sprint meeting. Every team planned their next sprint during these large meetings. Our customer was concerned that there was very little energy in these marathon meetings. The main reason was that for many attendees, over 75% of the content was not interesting: it was about other applications. The level of detail was too deep for members of other teams. By scheduling project-specific sprint meetings, each meeting had fewer people, and those people were engaged in the activity.

To make sure that the voice of the customer was represented, we recommended that one member of each application team attend the framework team's sprint meetings.

To make sure that the framework team knew of any issues relating to each application, we recommended that one member of the framework team attend each application team meeting. (Although not necessarily the same person. That would be a lot of meetings).

We made this recommendation because sprint meetings are in depth, and project focused. We feel it's important to have all attendees engaged for the entire meeting. We wanted to reduce the waste associated with attending meetings where someone is not really contributing.

It did raise the energy in the project meetings. It also brought some concerns. Everyone felt this decreased the communication between application teams. That could lead to code duplication, missed opportunities for reuse, and siloes of knowledge.

On to Standups

Standups are a mechanism to communicate to everyone any progress, and any issues. We recommended having all the application teams and the framework team attend the same daily standup. That’s about 30 people, but it can still be a short meeting, if everyone follows the rules. We're finding two main advantages to this process.

If someone is stuck, a larger group of peers hears about the issue. That increases the chance that someone will say "I can help." Issues get solved quicker.

The framework team is becoming much more efficient. Imagine someone on an application team makes a feature request of the framework team at one of these standups. One of three outcomes are possible:

No one says anything. That likely means that no other app needs that feature. Maybe that feature is better implemented in the app team's code base.
Other App teams say they need (or will soon need) that same feature. That information helps the framework team prioritize requests.
Another App team says "we've already built that feature." Now, the work changes from a new feature to refactoring code (and associated unit tests) to move it from the application's codebase to the common framework. That avoid code duplication, and means the framework team can release the new feature more quickly.

It's working quite well so far.

What have you tried? How has it worked?

Testing without ExpectedExceptionAttribute

Mon, 14 Jan 2013 16:45:43 GMT

The Windows Store version of the Microsoft Test Framework does not include an ExpectedExceptionAttribute class. I’ve already received questions on how people should go about creating tests where the code under test should generate exceptions. First, a note on the seriousness (or lack of) for this change: The existing .NET libraries for testing do not display this problem. Your existing unit test libraries are fine. But moving forward, how are you supposed to test failures? Instead of adding the ExpectedExceptionAttribute, you should use the new method: public static void ThrowsException<T>(Action code) where T : Exception There are reasons for this change. ExpectedException is a course-grained check that can cause tests to pass that really should fail. Consider this test: [TestMethod, ExpectedException(ArgumentException)] public void ExceptionPath() { setupTestEnvironment(); var underTest = new Worker(); setupTestObject(underTest); var systemParms = GenerateCollaborator(); underTest.DoSomeWork(systemParms); } The ExcpectedException attribute means that this test passes if *any* code in this test method throws the expected exception. It may not where you expect. It may be that some of your setup fails, and the particulars of the failure mean that the expected exception is what's thrown. That could mask problems in your production code. If the setup method setupTestObject() throws an ArgumentException, this test passes, even though it shouldn’t. Because of the nature of this issue, it can crop up anytime. You could be updating test code and you could accidentally introduce this error. It would masked because the test passed when you started, and the test passed when you finished. Assert.ThrowsException fixes this issue. Here’s the new version of the same test: [TestMethod] public void ExceptionPath() { setupTestEnvironment(); var underTest = new Worker(); setupTestObject(underTest); var systemParms = GenerateCollaborator(); underTest.DoSomeWork(systemParms); Assert.ThrowsException<ArgumentException>(() => underTest.DoSomeWork(default(string))); } This different version of the test passes if and only if the DoSomeWork() method throws the ArgumentException. If the ExceptionPath() test method throws an exception anywhere else, this test fails. As it should. If you update tests as you add features, or change defined behavior, I recommend changing your failure path tests to make use of this technique. I wouldn't retrofit every test you have, though. That feels like a whole lot of busy work, with only small benefit. Next, we'll look at how to write tests for async methods that throw exceptions. There are many nuances there that can mask issues in your tests, and in your production code.

Windows 8 Unleashed Developer Event coming to Ann Arbor

Mon, 07 Jan 2013 19:48:28 GMT

We’ve partnered with Microsoft to host “Windows 8 Unleashed” in Ann Arbor on Thursday January 24th. This is a free event, sponsored by Microsoft, and hosted by SRT Solutions. Windows 8 Unleashed is a developer event focused on people that want to develop apps for the Windows store. (Surely you’ve seen the commercials for Windows 8 by now). The format contains 3 sessions where Jennifer Marsman and I will be explaining the principles of Modern UI Application development (what we formerly referred to as “Metro style apps”). The afternoon is open lab time for you to create your Windows Store Application. Jennifer and I (along with a few possible unannounced guests) will be available to help you over the rough spots. The first link above provide information about the event (including prize opportunities, and who doesn’t like free stuff). The second link is the registration page. Registration is free, but it will help us ensure we have enough room, and food for everyone that attends.

Enter 2013

Wed, 02 Jan 2013 20:58:19 GMT

Welcome to 2013. This promises to be a year of many new adventures, and continuing many of my current activities.

Let's start with the existing activities, and the changes in those programs.

I've been renewed in the RD program, which is starting 2013 with a new logo.

The new logo is cleaner, more modern, and represents the direction of the Microsoft Regional Director program moving forward to stay at the forefront of technology. The RD program represents a strong community of independent technology experts that have key positions in companies around the globe. It's an amazing community.

There will be more news about the program, and the RDs over the course of the year. You'll hear more from this group of amazing people as time goes on.

Also, yesterday I received notification that I was renewed as a C# MVP. This marks my 8th year in the program. This is another highly technical community. The difference is that this community is focused on the C# language and related technologies. The unifying traits of the C# MVPs are that they are very knowledgeable in C# development, and they have a strong desire to share this knowledge with the software community. Sometimes that's the local community; sometimes it's the regional community; and sometimes it's the global community. That brings me to the next item.

This year, we're launching classes to teach professional software developers the techniques we use to create software for our customers. We've already launched the .NET Developer Infusion Series. We're doing our part to help address the skills gap for software talent in our area.

Watch for classes in other technology stacks to launch by March.

For myself, I need to focus more time on my own learning. There's been an amazing set of tools, libraries, and technology stacks that have become popular in the last year or so. I need to learn more about a variety of up and coming skills for building software. Like so many times before, this is a great time to be a software developer, and to learn new ways to create great value for our customers.

That means exciting times for SRT Solutions. Over the course of the coming year, we are planning continued growth, and continued commitment to creating great software that helps our customers achieve success in their chosen markets. Throughout the course of the year, watch for announcements of new applications, new customers, and new people joining SRT Solutions.

Which gets to my renewed commitment to communicate more. As I went through the last year, I can see that my blogging activity dropped off last year. There were a variety of reasons. One was that there were so many new things to learn that I wasn't sure I had the right answers. I looked through the blog archives and I see that it's more important to start the conversations here than to be perfectly correct every time. This year, I will be blogging more. My goal is twice a week. As in the past, many of the posts will be on topics that I am currently learning more about (like Windows 8 development). I need to have those conversations, and hear what you, dear reader, think about the same topics. I'm hoping that by putting my (sometimes half baked) ideas out there, we'll learn more together.

And, there are a few new surprises coming. Keep your eyes and RSS readers open.

SRT Developer Infusion Training: Launching in February

Fri, 14 Dec 2012 18:36:23 GMT

We are excited to announce public classes for developers launching in January of 2013. Twice a month, we'll host .NET developer training classes for professional developers that want to grow their skills. Our curriculum is based on the wealth of material we've created to help .NET developers learn more about the C# language and environment. As readers of my blog, you're probably familiar with my books, videos and articles. But it's not just me. Patrick Steele has a regular column in Visual Studio Magazine. Many of our .NET developers have spoken at conferences and created content that we'll use in our classes. The format, the delivery, and the content are tailored for busy professional developers. Each month, we'll conduct two afternoon sessions. One will be focused on a recent release to help developers learn the latest tools and techniques. The second will be focused on mainstream releases to help developers become more proficient with the tools they are already using. Each session includes discussion and demonstrations. Most importantly, half the time will be spent on labs that provide guided experience on the topics being covered. We'll repeat sessions if there is enough interest. All the classes will be hosted by the experienced conference speakers that have been providing developers with great content for years. We're excited about this launch. It augments but does not replace our core focus: creating great software for our customers. Our area, like many locations, is experiencing a shortage of developers in certain areas, such as C# and .NET. That talent gap is slowing economic growth here. As Dianne and I have gotten more involved in the regional business community, we began looking for what we could do to help. The obvious choice is to help new developers in the community grow their skills. In fact, we’ve already hosted private classes for many of our customers. This launch enables us to reach a wider audience. Longtime readers of any of the blogs on our site know that SRT Solutions has a commitment to continued learning. We know that this industry moves fast, and we have to continue learning to stay relevant and move ahead. All our developers spend time learning new techniques and creating content. It helps us created create great applications for our customers. It also positions us to help other developers in our region. Our goal for this new program is to train the developers that our growing regional companies need to grow. It's our way of closing the talent gap. You can learn more here. You can signup for the first two sessions here, and here. Finally, this effort doesn't stop with .NET. We're also hard at work finalizing the curriculum for alternative languages on the JVM, HTML5/JS, mobile Development, and cloud based development. Those will be going live in the next couple months.

Surface / WinRT review (for consumers)

Mon, 19 Nov 2012 13:04:43 GMT

I've now spent two full weeks with my WinRT Surface. I've tried to spend as much time as possible with this device while I’m forming my opinions.

I bought the Surface Pro, and I bought both the touch cover (red, to match the SRT logo), and the type cover. I wanted to try both to decide which I liked better.

WinRT is the version of Windows8 that runs on the ARM processor. It comes with an ARM version of Microsoft Office Home and Student. (That version includes Word, Excel, PowerPoint and OneNote). Other than those applications, you must install applications from the Windows Store. You cannot install applications from any other location.

The WinRT Surface has a lot to recommend it. Because of the ARM processor, the battery life is amazing. I've been able to take notes through an entire day of meetings without finding a cord or power outlet. The form factor is comfortable to work with. The screen is very clear and bright. The weight is very light, even after a full day.

As I mentioned above, I purchased both the touch cover and the type cover. I have a very strong preference for the type cover. I tried the touch cover for a few days, and I found it too different from a normal typing experience. The type cover is a much better experience, at least for me.

The restriction that all apps must come from the store was really not a problem. I've been able to find great apps for all my non-developer tasks. I'm using Tweeterlight for my twitter client. I've got IM+ to manage my message accounts. I've got skype installed. I use FeedReader for my RSS reader. I don't mean this to be an exhaustive list. It's just to give you some indication of the main applications I'm using. Overall, I've been happy. There are one or two holes that I still need filled, but overall I've been happy with what's available.

Of course, it's not perfect. I'm ambivalent about the kickstand. It's at a great angle when I place the Surface on a desk or a table, and I'm sitting in front of it. However, the angle of the kickstand is not adjustable. It's not at the right angle for me when the surface is in my lap, or when I'm working at my stand desk. However, I can work with the surface lying flat in some of those cases. My one suggestion for a future hardware enhancement would be to allow the kickstand to have a couple of different angles built in. With that said, Microsoft clearly put a lot of thought into the design: the angle of the kickstand is great at a table for me, my wife, and my daughter (all having quite different heights).

I do think that a Surface with Windows RT (on the ARM processor) is a great device for students, home users, and many business users. If you can find the apps you need in the Windows store, you will be very happy with this device on WinRT.

There are a few classes of users for whom the Surface with Windows RT is not the best choice (for their primary device). Serious gamers will not be happy because they will not be able to install games designed for Windows 7. Developers cannot use the ARM -based devices for their main machine (but will want an ARM device. I'm writing another blog post on this topic). Users that have some specialized application needs may not find their specific application ready yet for Windows 8 yet.

Overall, I'm impressed with the Surface running WinRT. I'll use it regularly because of the battery life. It's going to be my primary machine while travelling. I'll also be adding two more of these devices to our family. Both my daughter and my wife are planning on new Surface machines.