This is my second post about the changing year. In this post, I look at the areas where I will invest my time in the coming year.
The .NET Core platform is a version of the .NET stack that runs on OSX and Linux in addition to Windows platforms. This is a pre-release project at this time, but there is enough there to beging experimenting.
As this platform matures, .NET truly becomes cross-platform. You’ll be able to use C#, F#, VB.NET, and the bulk of the .NET Base Class Libraries to create software that runs on multiple platforms. The Roslyn compiler platform provides one of the key building blocks by running on OSX and Linux. That means the managed portions of the .NET Framework can be compiled on these platforms, and will run effectively. The remaining work is primarily to make the unmanaged portions of the CLR and the libraries run on other platforms.
Some of the work here is technical in nature. Other work is to ensure that the licenses used by the .NET framework components are compatible with a cross-platform strategy. Most of the components are released under either the Apache 2.0 license, or the MIT license. Check each library for details. (Notably, the previous restrictions on earlier MS-PL licenses for Windows only support has been removed from anything related to .NET Core).
While this work is going on, there is a parallel effort to build out learning materials for .NET Core. This project is also open source, and accepting contributions. (I’ve had a couple PRs merged here already).
I’m really looking forward to the date later in 2016 when a production ready .NET environment runs on Windows, Linux, and OSX.
This will be a very interesting version of C#. The team is using GitHub issues to openly discuss language features and their ramifications. Go aehead and participate in the discussions. It is really exciting to see the community participate with such passion for different features that they would like to see in their favorite language.
As I discussed in the last post, the compiler is Open Source. If you want to experiment with some of the new features, you can try. There are experimental branches for some of proposed features. (The maturity of the implementation varies.) It’s also important to understand that the features haven’t been formally committed to. Do not use those branches in production applications (yet).
We’ve entered a world where our web-based applications are managing more data, and scaling to ever larger numbers of users.
OK, this trend has been in place for a while, but it’s only accelerating and growing.
We have new ways to deliver and scale web-based software. We have cloud platforms that enables us to change the number of instances running. We have docker containers. And, on a related trend, we can offload more and more processing to the client device. That may mean platform specific mobile applications, or SPA style browser based applications.
We will be doing more and more work with software that needs to scale by running multiple copies of your application in different configurations. There are many different options for this, and wise developers will learn a bit about each of them.
Machines are good at examining very large datasets. Machines are also good at running lots of different scenarios.
Put the two together, and I see a trend for more machine learning in the future. The applications we use generate tremendous amounts of data every day. As machines observe and analyze that data, more insights can be gained then ever before. Machine Learning and related algorithms can enable us to play ‘what if’ with more and more different scenarios and make better decisions based on larger and larger data sets.
Our data is a bigger and bigger part of our lives. The software necessary for us to interact with that data is smaller (in relation). This trend affects the ‘stickiness’ of any given platform.
This trend has a huge impact on how network effects work for modern systems.
As an example, consider music applications. Every platfrom has an app that can play music. But, what’s important to users is that they can play the music they’ve already purchased. If you already have an iTunes subscription, you want to play your iTunes music. If you have a Microsoft Groove subscription, you want to play your Groove music.
The important feature is access to the data (music) that you’ve already purchased (or subscribed to, or created).
That impacts the ‘stickiness’ of a platform. Finding and installing programms for a new device takes a fraction of the time (and possibly money) of updating every subscription to a new platfrom. I believe this portends an interesting trend in the network effects for different applications. Namely, changing device platforms will be a trivial exercise, compared to changing the provider of cloud based data.
I believe this means that future platform stickiness will be based on your cloud based data, not your device. Do you want to switch between mobile platforms? That will be easy, as long as your data can come along. If that means recreating or resubscribing to a service, its going to be a non starter.
That leads me to the concluson that the clould is more critical than the device.
In the coming year, we’ll be focusing on reaching the 1.0 milestone (not beta) for the apps currently in development. We’ll also be ading new applications as the year progresses.
I’m excited for the progres, and I’d be happy to see more participation. If you are interested, head over to our home page on github and check out our projects.
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?
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.