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.
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");
var rVal = string.Empty;
if (val % 3 == 0)
rVal += "Fizz";
if (val % 5 == 0)
rVal += "Buzz";
rVal = val.ToString();
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");
private static async Task<string> FizzBuzzAsyncImpl(int val)
var rVal = string.Empty;
if (val % 3 == 0)
rVal += "Fizz";
if (val % 5 == 0)
rVal += "Buzz";
rVal = val.ToString();
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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:
It's working quite well so far.
What have you tried? How has it worked?
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.
All of these projects are Open Source (using the Creative Commons license for content, and the MIT license for code). If you would like to contribute, visit our GitHub Repository. Or, if you have questions, comments, or ideas for improvement, please create an issue for us.