Brad Wilson

Getting Started with ElasticLINQ

Jim Newkirk and I have been doing xUnit.net for 7 years now (and for Jim, NUnit for many years before that). You could say that open source is part of our blood, and when we left Microsoft, we made sure that open source would continue to be part of our daily efforts at Tier 3.

Fast forward 15 months: Tier 3 has been acquired (and is now the CenturyLink Cloud Development Center), and our first major open source effort Iron Foundry has been accepted into the Cloud Foundry Incubator project. Lots of great developers are working to ensure that you can write .NET code against a Platform-as-a-Service stack that doesn't lock you into a specific vendor.

Today we are proud to announce our second major open source effort: ElasticLINQ.

Book Review: .NET 4.5 Parallel Extensions Cookbook

Disclosure: I was offered a free electronic copy of this book in exchange for this book review. The publisher had no input on the review.

Parallel processing is one of the most challenging problems for the modern developer. The first time you start creating threads, you open yourself up to a whole host of problems, including deadlocks and data corruption. The ASP.NET team went to great lengths to hide all the difficulties of multi-threading by presenting a programming model that allows developers to reap the benefits of multi-threading without sweating most of the details. Similarly, the Task Parallel Library – introduced in .NET 4, and greatly improved in .NET 4.5 – attempts to bring that same level of abstraction without diving deep into the threading details.

Professional ASP.NET MVC 4

They say that writing a book is a hard way to make an easy living. This is especially true for technical books, which tend to have a short shelf life.

For me, the process was made easier by having three great seasoned authors to work with. We updated all the existing chapters of this 4th edition to cover ASP.NET MVC 4, and we've added three new chapters covering Membership & Security, Web API, and the building of the NuGet Gallery site using MVC. I like to think of this book as my Microsoft swan song. :)

Print Edition, Kindle Edition 

Leaving Microsoft

Tomorrow is my last day at Microsoft.

It's an unexpected journey that brought me here. In 2004, my friend Peter left Denver for Seattle, to take a job at the patterns & practices group, and my parting words to him included: "If you guys are hiring, let me know." I'd just bounced out of a startup that we spent 2 years trying to make succeed, and was doing contract work for a friend. I'd also just gotten separated, and I was looking for a change. Microsoft felt like this mythical place where all software developers should want to work at some point in their lives, and it was my time. Six months later, he called, I interviewed, and away I went.

I'd never been much of a big company person. I still don't think of myself that way, despite 7.5 years at Microsoft. I had my share of complaints about the residual effects of working in a big company (the review system being the by-far worst of it, especially since it's something more fit for 20th century manufacturing than 21st century software development). Some of it, though, has to be attributed to the fact that Microsoft isn't a big company... it's a dozen big companies. And it's not a dozen big companies, but thousands of small companies. As an individual contributor in particular it's easy to pretend that the company is your project, or your group, and ignore the other 90 thousand people.

I count myself lucky that I worked on three amazing teams at Microsoft. Throughout my time at p&p, CodePlex, and ASP.NET, I made several life-long friendships with terrific people like Peter, Scott, Jim, Jonathan, Sarah, Jedidja, and Matthew (and many more than I could list here). I got to pair with Ward Cunningham. I got to work with luminaries like Henrik Nielsen. I got invited to speak all over the world, and met tens of thousands of inspired and inspiring people in the process.

There's no question that Microsoft changed my life for the better.

Leaving Microsoft was one of the hardest career decisions I've ever had to make. Despite all my nitpickings of the company over time, I believe that Microsoft is in the best position that it's ever been during my career there. Xbox, Kinect, Surface, Windows 8, Windows Azure... the engine is firing on all cylinders right now. The team over at ASP.NET is filled with some of the smartest, nicest people I've ever worked with. Despite all that's good about it, though, it's time for me to get back to my roots, and do big things with a small group of friends.

On the question of xUnit.net...

Jim and I have been working (with executive support) to get xUnit.net moved over into the Outercurve Foundation. We are continuing to work on version 2 while we let the legal stuff unfold. The primary benefit to the community will be our ability to accept outside contributions to the code without the excessive legal overhead that prevented it when it was a Microsoft-owned project.

We have lots of plans for v2, and our commitment to xUnit.net has never been stronger than it is today.

What's next?

On October 15th, I'll be going to Tier3.

Webstack of Love

Norway is a great place to visit, and the Norwegian Developers Conference was one of the best conferences I've ever been to (it's no coincidence, I think, that my two favorite conferences are both in northern Europe: NDC and Oredev).

My talk at NDC this year was HTML 5 + Knockout + ASP.NET Web API + SignalR = Webstack of Love. The source code (with all four steps) is available on GitHub.

Enjoy!

Slides:

Video:

Batching Handler for ASP.NET Web API

Update: The Web API team is planning to add this to v2. Please visit the Wiki and give feedback!

While there is no batching standard built into the HTTP protocol, there is a standard for MIME encoding HTTP request and response messages ("application/http" with "msgtype=request" and "msgtype=response", respectively). ASP.NET Web API has built-in support for both MIME multipart as well as encoded request and response messages, so we have all the building blocks we need to make a simple batch request handler.

Task Parallel Library and Servers, Part 4: TaskHelpers

This is part 4 in a series on using Task Parallel Library when writing server applications, especially ASP.NET MVC and ASP.NET Web API applications.

1. Introduction
2. SynchronizationContext
3. ContinueWith
4. TaskHelpers

Simple Task Helpers

I know we left off in part 3 with a problem, but we're not going to solve it yet, because we still need to build some foundation helper classes that will make it easier to do that. In particular, there are some good practices we can codify around the creation and conversion of tasks that led us to write the TaskHelpers class that we use today in ASP.NET Web Stack.

Task Parallel Library and Servers, Part 3: ContinueWith

This is part 3 in a series on using Task Parallel Library when writing server applications, especially ASP.NET MVC and ASP.NET Web API applications.

1. Introduction
2. SynchronizationContext
3. ContinueWith
4. TaskHelpers

What ContinueWith Really Does

I promised that we had a bug in our previous code, and we did... sort of. Calling ContinueWith without any special flags will cause your continuation to always run, regardless of the final state of the task. We wrote our continuation under the assumption that the Task had completed successfully, which can lead to some very odd and hard to debug problems. Luckily, in our code, we ended up calling Result on the Task object, which turns around and throws an exception if the task had ended in a faulted or canceled state. But what if we'd had a Task rather than a Task<T>? Or what if we hadn't called Result? In .NET 4, this is considered a fatal error condition, and when the task object got garbage collected, its finalizer would've thrown an exception that takes down your AppDomain because you had an unobserved fault! Definitely not good.

Task Parallel Library and Servers, Part 2: SynchronizationContext

This is part 2 in a series on using Task Parallel Library when writing server applications, especially ASP.NET MVC and ASP.NET Web API applications.

1. Introduction
2. SynchronizationContext
3. ContinueWith
4. TaskHelpers

Introduction to SynchronizationContext

An important part of the work in properly handling tasks on the server is supporting the synchronization context. When you’re using .NET 4.5, then the await keyword automatically does this for you. When you’re consuming Task objects on .NET 4, though, getting yourself back onto the right synchronization context is critical; otherwise, you may cause errors in your application when trying to access things which touch the HttpContext in ASP.NET.

Task Parallel Library and Servers, Part 1: Introduction

This is part 1 in a series on using Task Parallel Library when writing server applications, especially ASP.NET MVC and ASP.NET Web API applications.

1. Introduction
2. SynchronizationContext
3. ContinueWith
4. TaskHelpers

Okay, let’s just get this out of the way:

Asynchronous (multi-threaded) programming is not easy.

This warning really has nothing to do with .NET in particular, because it can be quite challenging to do correctly on any framework, but here’s the good news:

Asynchronous programming with .NET 4 is a little easier.
Asynchronous programming with .NET 4.5 is a lot easier.