My video series “C# Puzzlers” is live on both Safari and Inform IT.

C# Puzzlers are a series of small puzzles that make you think about some specific facet of the C# language. I put together a series of exercises are several different facets of the language. I think it’s an engaging way to get your mind around some of the areas of the language that commonly cause confusion for developers.

You can get the puzzlers at InformIT, or Safari.

Created on 1/19/2012 8:53:15 AM

Filed in: DevCenterPosts, C#, Technology, books, Me,

While at CodeMash last week, both BBC and ZDNet published stories about the use of booth babes (BBC’s term) at conferences.

We don’t hire models for our booth at conferences, and we’re not going to.

TLDR version: It would misrepresent our company.

OK, if you’re still with me, here’s the lengthy version.

Problem 1: It gives the wrong impression about the company image.

This is the most important issue. We’ve got a great workplace with mutual respect among all our employees, male and female. Hiring models for a conference booth sends messages, subtle and not so subtle, about our company’s attitudes toward the roles of men and women in our business, and our company. Close your eyes and imagine a female software developer at GoDaddy. Their ad campaigns have affected your impression, and probably not in a good way.

When you execute a marketing or advertising campaign, you must live with the impression you’ve created. You don’t get to say “No, no, that’s not really us. We just did that to get your attention.” You’ve created an image, and you’ve associated that image with your company. Your prospects (as customers, colleagues, or employees) form their image of your company, your culture and your values based on the tools and images you use in your marketing and advertising campaigns.

If that image is not correct, you must work doubly hard to correct it. You must not only continue to build your positive brand image, you must live down the negative impression you’ve cultivated. It’s hard enough work telling the world how great you are. Don’t sabotage it by telling the world how bad you are.

The obvious reason we don’t use models at conferences is that it’s wrong for us. It works against our culture, our values, and the professionals (both women and men) that work here.  For the same reason, we don’t use models on our website. The photos that you appear are people who work at SRT, either now, or in the past, when the photos were taken. But, this is the part where some marketing professional usually says, “I agree, but it works. We’ll do it anyway.”  So let’s move on to why I believe it doesn’t even work.

Problem 2: The increased traffic does not indicate increased interest in your business. It indicates increased interest in models.

Suppose there are 75 people at a 1000 person conference who may be interested in what we do. Our goal, as a business, is to maximize the quality time someone spends talking with those 75 people. Nothing else really matters to the business as a whole.

One serious challenge is that you don’t know who those 75 people are. Standard marketing logic says that if you get the highest number of people stopping by your booth, you’ll get the highest number of possible prospects. That may be true in certain markets, and at certain conferences, but I don’t think it applies all the time.

Suppose we hired models to work at our booth. I have no doubt that we would have more traffic. There would be, however, two problems: First of all, a lot of that increased traffic would not be there because of what we do as a company. The additional visitors would be interested in the models. They are probably not in that 75 attendees I mentioned earlier that are actually good prospects. All the models have done is increase bad traffic and make it harder to spot and have real conversations with the real prospects in the crowd.

Problem 3: It drives away people actually interested in your business.

I’ve said nothing about the makeup of the 75 attendees actually interested in us. How many may be women that are turned off by a marketing strategy right out of “Mad Men”? How many, men or women, would be turned off by that image? How many might be interested in a deeper conversation about software development than they would be likely to have with a model?[1] Would they visit, or would they avoid the booth entirely? Real prospects may decide there’s too much traffic, and just ignore it altogether.

So what will you see at our booth?

We will demonstrate something interesting about us and our thoughts on software development. This last week at CodeMash, we demoed an original game built using the Microsoft Kinect. We did that because we believe there are interesting opportunities to use the Kinect in many applications; it’s important for us to demonstrate that we are already learning this. That’s a key part of the message: Our company stays at the forefront of technology trends, and is often even ahead of our markets. Our technical employees are given time to investigate these new ideas and build software that shows the result of these investigations.

In years past, we’ve shown mobile applications, cloud based applications, and a game controlled by the wii remotes. I don’t know what we’ll build next year. We’re still planning that.

Everyone at our booth works for SRT Solutions. Depending on the conference, they may have a more technical role (like at CodeMash), or a more business oriented role. It depends on the audience, and the conversations that will likely occur. Anyone you see at the our booth represents the company with their knowledge and their professionalism.

You’ll see people dressed pretty much like a normal work day. In fact, if anyone asks for guidance, we’ll say “dress the way you would to attend a customer meeting.” That’s consistent with our culture and our values. And, it’s the same advice regardless of the questioner’s gender.

Do I have a point?

Personally, I believe that the way you market yourself, or your company, is about more than simply generating a high number of leads. Your marketing creates an image of your company. If you’re successful, your marketing imparts that image to many different prospects: customers, partners, employees, and more. You don’t want to live down a marketing campaign that is at odds with your company culture. You’ll attract too many of the wrong prospects, and too few of the right ones. There’s the common phrase that says “half of all your marketing is wasted, you just don’t know which half.” If your marketing is at odds with your values, the sad fact is that all your marketing is wasted.

[1] This is not to say that models are not smart. I’m just saying they know less about software development, and our business, than our employees.

Created on 1/17/2012 4:44:16 PM

Filed in: Business, SrtInsights, SRT Solutions,

While at CodeMash, I had an interesting conversation with Cori Drew regarding some code in Effective C#, and some comments from Jon Skeet in our combined async talks. These comments involve breaking some common recommendations, and performance.

In our talk, Jon described how the C# compiler creates a mutable struct when it builds the state machine that handles async continuations. Jon discussed that the nested struct was faster than a nested class. Contrast that with code in Effective C#, where I showed the following code:

public class List<T> : IEnumerable<T>
{
    private class Enumerator<T> : IEnumerator<T>
    {
        // elided
    }

    public IEnumerator<T> GetEnumerator()
    {
        return new Enumerator<T>();
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return new Enumerator<T>();
    }
}

Well, Cori asked, why didn’t I make the Enumerator<T> a struct (which is what the BCL does):

public class List<T> : IEnumerable<T>
{
    private struct Enumerator<T> : IEnumerator<T>
    {
        // elided
    }

    public IEnumerator<T> GetEnumerator()
    {
        return new Enumerator<T>();
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return new Enumerator<T>();
    }
}

So, why didn’t I?

Well, as Eric Lippert points out, “mutable value types are evil.”  In general, you should avoid mutable structs. If your type requires mutation to work properly, you should use a reference type. Implementing IEnumerator requires mutation (keeping track of the current item), so you should use a reference (class) type. Unless you are really sure that you need a struct, you should use a class for any type that supports mutating operations.

Because of that, I chose to demonstrate with a class rather than a struct. I felt it would be too likely for readers to copy the code and use it in different situations where the special circumstances that are in play in both async state machines and the nested List iteration are no longer true. I chose to give up some performance in return for a more general idiom that would be correct in more situations.

Given that, let’s discuss why the mutable struct works in these two situations.

In the case of the nested Enumerator class, it’s because of one of the rules for converting a struct to an interface type. When a struct is converted to an interface, it isn’t actually unboxed. The box implements the interface, and adapts the methods defined on the interface by forwarding them to the struct in the box. The struct does not get unboxed and copied on each function call. See Section 11.3.5 of the C# spec for details. Read the following guidance carefully:

If your struct will always be accessed through an interface pointer, that struct can be safely mutable because it will never be unboxed.

The nested private Enumerator satisfies this requirement. It is a nested private type, so that other code cannot access it through the struct value. Client code can only access it through the interface reference, and therefore, the above rule always applies.

The nested structure that implements the state machine in an async scenario also follows a similar pattern, and therefore is safe.

OK, before you go just applying this rule to structs in your programs, read that guideline again carefully. Notice the strong ‘always’ and ‘never’. There can be no exceptions. In the case of the nested enumerator, this is enforced by the fact that GetEnumerator() returns the interface, not the struct. In the case of the nested struct in the async state machine, it’s enforced because it’s in compiler generated code.

You’re probably not so lucky. Chances are you work with other developers. Someday, someone will make some changes to your code so that one of those rules will be broken. Then, bugs will start to crop up.

Even if you are completely sure that those rules will never be violated, take care. Just because you can get away with something safely doesn’t mean you should turn away from normal guidance. In both these cases, the performance gains by changing from a class to a struct, can be significant. That significant performance gain coupled with the guaranteed safety does mean that its worth breaking the normal guidance.

In the case of the nested Enumerable, the performance gains come from the fact that this code will execute very often over the course of many programs.

In the case of the asyn methods, it’s because the team wants to optimize the ‘hot’ path for async methods. The reason is that you (and me) should prefer making a method async if there is a possibility that it will take enough time to warrant it. We shouldn’t worry that declaring a method async will cause an undo performance burden over its synchronous counterpart. With that in mind, the team is working very hard to optimize those code paths.

If you want to switch from a class to a struct, you should perform some measurements and make sure that the change will actually give you the increased performance you seek.

In the end, the same old advice often holds true: Make it work well. Then, once you’ve measured and determined that performance for a given location is critically important, make the changes necessary to achieve those goals. In my books, I wanted to try hard to write general guidance, and I avoided most performance based guidance. It seemed safer than trying to ensure that readers would remember all the specific rules for a particular optimization.

Created on 1/16/2012 12:03:46 PM

Filed in: C#, Technology, DevCenterPosts, async,

For most people, the holiday season is over, but here, where Michigan and Ohio meet, there is one more major event:  CodeMash.

I have not yet figured out my entire schedule, but there’s a few things I plan to concentrate on.  I need to learn more about WinRT. I’ve had too little time to build samples and learn about it yet. I want to learn more about Scala, an exciting functional style language that runs on the JVM. Beyond those specific goals, I want to learn about techniques I can apply across any platform. I don’t believe I’ve learned as much as I can about modern software engineering techniques: testing, continuous improvement, advances in languages, frameworks, and libraries. I want to spend as much time as possible in sessions that are not platform specific, or language specific.

I am giving two different talks this year.  Early Friday afternoon, I have “C# Stunt Coding: I Dare You to Try This at Home” This is a really fun talk to give. I get to start by saying that all the techniques I’m explaining are for edge cases, and specific problems, so chances are you will rarely want to use them in your everyday coding activities. Of course, that means everyone will pay careful attention, and immediately try everything I show the very next day. There’s no avoiding it. Developers just think that way. That makes it more fun.

Spoiler Alert

Ok, not really.

The other talk I have is “Async From the Outside”, where I discuss how the new async programming model in C# 5 introduces new ways to to make async programming easier.  You may have noticed that the abstract for Async From the Outside references the talk “Async From the Inside”, given by Jon Skeet, author of the very popular and respected “C# In Depth”. If you look at the abstract for Async from the Inside, you’ll see it references Async From the Outside.

There’s a few more items you should notice about these two talks:

• They are in the same room
• The second (inside) immediately follows the first (outside)

You may be thinking that it would be better to mash these two talks together, giving attendees two hours of async inside and out.

Well, Jon and I thought the same thing. We’re working together on a single stream of content, with both of us working together for the duration of the two talks. We’ll discuss how to use a feature, how it’s implemented, and how to use it in your regular development activities.

Well CodeMash fans, this will be the first time Jon and I have met in person. We’ve emailed, chatted, skyped, google talked, and been on .NET Rocks together, but we’ve never yet met in person. I’m looking forward to it. Jon and I are working quite diligently to make sure we deliver quality content. 

Jon also has his own individual talk to give: C#’s Greatest Mistakes. I’m really looking forward to that one as well.  Jon has shared some of the content with me. He’s one of a very small set of people that can give a talk like this, and make it a great talk for people to learn, not a screed. It’s one of Jon’s best qualities: the skill to be critical, yet positive.

Jon has written a similar post on CodeMash.

Created on 1/3/2012 8:34:07 AM

Filed in: C#, Me, upcoming attractions, local interest, SRT Solutions, Technology,

Dianne Marsh and I have been doing some planning for our expected growth. We will be doing more announcements during the course of the next year.

Right now, we’ve got an immediate opening for a business development associate. (I know that most of my readers are developers, so please pass this on, if you know someone interested in joining us in this capacity).

Of course, we are always interested in talking to exceptional developers about our ongoing growth plans as well.

You can read more here.

I promise: the next posts will have the technical content most of my readers prefer.

Created on 12/19/2011 3:01:07 PM

Filed in: SRT Solutions, local interest,

Earlier this week, I read two interesting articles on the importance of software and developer talent to future economic growth and prosperity. They are particularly important because I’ve been asked to participate in some of the talent initiatives Michigan Governor Rick Snyder announced last week.

Let’s start with the Forbes’ article “Now Every Company Is A Software Company” The deck quote ties it directly to Michigan, “Ford sells computers-on-wheels”. The thesis of the article is that no matter what business you think you are in, you are in the software business. I’ve been saying this for almost a decade. Are you developing innovations for healthcare? You need software. Are you in advanced manufacturing? You need software. Entertainment? Software runs that too. Marketing / Branding / presence? You better have a social media and internet strategy. That takes software.

Businesses have to be incredibly smart about creating software that provides true value for their business, and leveraging commercial software in other areas. Our customers don’t ask us to build everything from scratch. There’s no return on that investment. On the other hand, they can’t create the kind of innovations they need without some custom development. If all they do is use software that is commercially available, they can’t differentiate themselves from their competition.

From this perspective, I’m impressed with the emphasis on the software industry in Gov. Snyder’s talent address. Software requires less capital, and a high percentage of that capital goes to pay wages for developers. Software business investment provides a very quick and very high return to the overall economy.

Next, there’s an article in Forbes about the rise of Developeronomics. There’s a lot of hyperbole in this article regarding developers, money, and talent in general. It is well written, and it is a fun read. The core thesis though is very good: Good developers are valuable.  Really good developers are really, really, valuable.

This paragraph sums up the software developer scene well:

In the midst of a thoroughly gloomy labor market, the genuine desperation you see in the software talent wars is almost surreal. Almost every day, I see big companies, little companies, entrepreneurs, wannabe entrepreneurs and even venture capitalists join in the hunt. The talent hunters infest LinkedIn, troll Quora, and trawl Facebook and Google+. Cartoons of homeless-looking CEOs holding up signs that say “Looking for a technical co-founder” are doing the rounds. Heck, I am one of these talent hunters (any star iOS developers out there interested in working with me?).

That paragraph sums up the strategic importance of software developers. It’s important for companies, for local economies, for regional economies, and even for nations. It explains some of the importance of the ‘10x’ effect, coined by Fred Brooks: The best developers are an order of magnitude greater than the average developers. There’s also a ‘-10x’ effect, where the worst developers are capable of dragging down entire teams.

In addition, developers more and more now understand their economic value. They will explore the market, locally, regionally, nationally, and even world wide. They will attract their fair wage, or higher.

But of course, the best developers are interested in benefits beyond money when they pick a job. As the author points out, a developer’s skills have a relatively short shelf life. It’s career suicide to get stuck in an aging technology where career opportunities are slim.

Let’s tie this to Michigan’s talent initiatives.

There’s a serious disconnect between the developers currently seeking jobs, and the technical skills employers are seeking now. As a reader of my blog, I’m sure you’re familiar with many of the skills that are in demand: .NET, Java platform, mobile, web, tablet, cloud. The current applicant pool has a very different skillset: AS400, mainframe, COBOL, and so on. That’s the reason for several of the programs:  To address the shortage of developers, the state needs to update the skills of a generation of developers whose former employers did not stay current with modern software development tools and techniques. (As an aside, there is a corollary with business failure and the absence of a coherent software strategy. More on that in another blog post). There are two very important goals for this program. The first is to teach these developers the immediate skills they need to become employable in today’s software job market. The second, and far more important, goal is to reconnect these developers with the area software community. If they stay engaged, and take control of their own career, they will continue to update their skills, and continue to be relevant to the current job market. That will be the major win, to teach a much greater percentage of our software developers to stay relevant. The Forbes article discusses “The Lifecycle of Software Talent”, where developers grow more and more skills, but eventually becomes an expert in some ecosystem and never move on:

As a developer ages, and finds it harder and harder to switch technologies, at some point, he or she is considered hooked for the rest of their natural lives to some technology — Java or C++ or the Facebook API say — that they can be expected to grow old with. When a technology hits that point of maturity, talent that’s hooked to it starts getting devalued along with falling retention costs. The buffets become skimpier, compensation drops, churn is lowered, and the talent retires into the sunset with the technology. It’s quite poignant really, like a crew going down with a ship.

You have to fight that. The best recommendation (from the same article): “The really talented ones retain an evergreen ability to reinvent themselves around the latest, youngest technology layer, seemingly at will.” 

The software landscape in Michigan is the legacy of a generation of developers that did not do that, believing in life-long job security. The current situation, and the programs to address them, should serve as an example to developers, young and not-so-young, to follow that advice and continue to invest in relevant skills throughout their entire careers.  The more we grow a modern, talented software talent pool in Michigan, the more our region will prosper.

Created on 12/9/2011 2:33:03 PM

Filed in: Business, SRT Solutions, SrtInsights,

I don’t often review business books here, but “Good Strategy, Bad Strategy: The Difference and why it matters”, by Richard Rumelt is an exception.

For my audience, the best feature is that Rumelt is an engineer by training. He explains strategy from an engineering and scientific perspective. He begins his discussion by going over examples where a mission, or a set of buzz-word heavy press releases substitutes for strategy. From that moment on, you know this is not the normal business book. He picks apart such empty direction with the precision of an engineer, or a dilbert cartoon.

That first part of the book is a quick read, and quite humorous. Its value is in preparing you for the second and third parts of the book. That’s where the real value is.

The second section “Sources of Power”, describes where you can find leverage, or power, that enables a well-thought out strategy to succeed. You’ll learn to recognize drivers that can be part of a great strategy. Most of all, you’ll learn the elements of any successful strategy. On almost every page, I found something that I could apply immediately, and I’ve already found myself thinking through his examples and applying them to our current environment.

The final section “Thinking like a Strategist” provides insight into how to use your brain to evaluate strategies, and to create your own good strategies. In addition to learning to recognize a good strategy, you’ll learn how to create and execute good strategy. You’ll finally learn how to benchmark results of executing a strategy. Most importantly, you’ll gain insight into when and how to consider modifying, or even replacing a strategy that is not giving the results you hoped for.

It’s not often that I read a business book, and walk away thinking “I can use this immediately”. This book gave me that feeling several times. I was constantly finding new ideas, new techniques and tools to help me running our business. It’s well worth the read.

Created on 11/30/2011 10:52:37 AM

Filed in: Business, SrtInsights, books, BookReviews,

First, let me preface this by saying I’m truly amazed at the quality and quantity of of submissions.  I’m not on the speaker selection committee, so I don’t see all the abstracts. Several colleagues whom I greatly respect have shared their talk ideas.  There were simply more great talks than they were slots.  I can’t imagine a harder task than being part of the CodeMash speaker selection committee It’s especially hard because there are so many different technologies represented.

That said, I’m super thrilled to have made the list for 2012.  I’ve actually got two talks, and I’m excited to deliver both of them.

The first is C# Stunt Coding: I dare you to try this at home. In this talk, I get to stretch the C# language in ways you don’t expect.  I’ll show techniques to do things you don’t think C# can do. Every technique will come with the warning that it’s one of those techniques that you should only apply in rare situations.  Knowing most C# developers and CodeMash attendees, that will only make you want to use them more.

The second is Async from the Outside. This talk will discuss how the async and await keywords will change the way you code in C#. I’ll discuss the async features, and go over coding practices you should adopt to make sure that you’re making the most use of these new tools.  You may have heard that async APIs are much more prominent in the WinRT library. That’s true, and that’s why many of the demos here will be designed for the Windows 8 Metro platform. People interested in the inner workings of the async details should attend Async from the Inside given by Jon Skeet.

Created on 10/20/2011 2:31:39 PM

Filed in: DevCenterPosts, C#, async, upcoming attractions, codemash,

It’s a little more than a week after //build/ and now I’ve had time to let more of the announcements, changes, and future technology sink in.

Users: Windows 8 and Metro

I’ve tried to spend the last week using the //build/ tablet and metro almost exclusively. It helped that I was at a conference toward the end of the week, and I traveled with only the tablet.

Forcing yourself to live in the new UI for almost a full week was an eye-opening experience. After a short time, I stopped comparing Metro to the full desktop. I stopped wanting the desktop experience. It’s very efficient. It’s easy to use. I’m totally addicted to the instant on experience.

In short, I did everything I could in the Metro shell, and became a sad panda whenever I needed to use the classic desktop.

Users: Working with Desktop Apps

Working in the classic desktop using the //build/ machine is clearly a compatibility play. It works, It does what it’s supposed to do, which is to ensure your existing software investment works on tablet, but it does feel second-class. It’s not the same experience. The performance feels wrong. The crispness is missing. The ease of use is missing.

I found I liked the Metro UI so much better, and had gotten so accustomed to it that I found myself trying to manipulate my desktop as a touch screen once I returned home.

In fact, that’s the single biggest lesson as I close this section and move to the developer section:

I firmly believe that once Windows 8 is out, Metro apps will destroy classic desktop apps in the market. The only desktop apps that will survive in the long term will be those that don’t have Metro alternatives.

Of course, not every application is applicable to Metro. Let’s talk about developing software.

Developers: The future experience

Just like we don’t develop software for phone devices using a phone, We don’t develop for Metro using the Metro UI. You’ll use the desktop experience (and whatever your favorite IDE is) to build Metro apps.  This speaks to the difference between the developer tablet given at //build/ and the consumer tablets that I think will dominate the market when Windows 8 releases.

The developer tablet from //build/ is not the right price point to compete with competitive platforms. End users will buy hardware that is more streamlined for their use, at a lower price point. As you design and develop your applications remember that: Your users will likely have a more painful desktop experience with their tablet devices than you do. They’ll want to spend even more time in Metro.

That’s why I believe it makes sense for you (and I) as developers to spend as much time as possible in Metro. The more time you spend in native Metro apps, the more you’ll understand what makes a great Metro UI.

By the time Windows 8 becomes released, I hope to have Metro versions of every non-developer application I use. Unless I’m developing code, I want to be in the Metro UI. It will feel like an earlier time when we often used cross-compilers and the development hardware was not the same as the deployment hardware.

Developers: Your next Hardware

But hey, you’re a developer. You (like me) will spend long stretches of the day in Visual Studio creating applications. For this, I really like the //build/ hardware. I put it in the dock, hook up my external keyboard, mouse, and large-screen HDMI monitor, and get to work.

This sets the Windows 8 developer experience apart from many competitive platforms. On Windows 8, you can develop for the metro platform on a Metro device, as long as you plug in some accessories. The beauty of that is you may be able to travel lighter, with only one device.

I am hoping that I can continue to find what I’m calling a “developer class tablet” once Win8 is released. It would be a great experience to carry a smaller form factor device, and still be able to do all the developer work I need to do.

Created on 9/26/2011 1:29:26 PM

Filed in: C#, SrtInsights, Technology, Windows 8,

I had to fly out early on Friday, so the only session I attended on Friday was Mads Torgersen and Alex Turner’s talk on the async features in C# 5.0. I’ll start with the punchline:

In C# and async, you’ll never write another callback.

In a nutshell, that’s what these features add to the language: Transformations so that you can write code that looks and reads like today’s synchronous code, and the compiler will transform that into the necessary constructs for async behavior. The compiler will create the state machine, and write the callback code for you.

The second key point is that all the languages (C++/C#/VB.NET/F#/Javascript) all support this construct. It’s also baked into the WinRT libraries. You can await WinRT async operations, just like you can await C# async methods.

There is, however, one very important distinction:

C# / .NET tasks are created “hot”, meaning they start immediately. WinRT async methods are created “cold”, meaning they don’t start until you await them.

The .NET languages are leveraging Task<T> and extension methods which take or return Task<T> to make the operation of WinRT async methods behave as similar as possible to C# async methods. For example, you can use the Start() and StartAsTask() extension methods to start a WinRT async operation. StartAsTask() also massages the WinRT awaitable to a C# Task<T> so that it supports cancellation.

Task<T> is also used to provide some other useful async constructs. Task.Run() enables you to write a compute intensive task for a background thread, and leverage the await pattern. The library handles the thread marshaling so that the continuation executes on the foreground thread when the background thread finishes its work.

Task<T> also contains the Task.Delay() method that you can use to easily check for timeouts expiring in long running operations.

Admittedly, this is a short post. Watch their talk, and try it out yourself.

You’ll never write another callback.

Created on 9/19/2011 1:27:05 PM

Filed in: C#, async, SRT Solutions, Technology,

Let’s preface by correcting a couple tweets from yesterday.

• First, the next version of C# will be C# 5.0, not C# 4.5 as I heard earlier. The next version of the framework will be .NET 4.5.  However, you should expect the language versions to be whole numbers.
• Second, I was misleading on the pattern based comment on C# async.  The await keyword is pattern based. As long as the object being awaited has the right methods to represent a future, it can be awaited.  However, async methods must return either void, or Task<T>. This is different than the current CTP version, but the official release will enforce this.

Onward.

Anyone that still feels managed code, C# and VB.NET are no longer first class citizens in Windows 8 must watch Anders’ talk about the future directions of C# and VB.NET.

The first part of the talk was discussing the async programming metaphor for Windows 8, and how the managed languages support those concepts.

One goal of the Windows 8 runtime and the Windows 8 libraries is to avoid the infamous spinning toilet bowls in your UI. Any operation that could reasonably expect to take more than 200 ms should be an asynchronous operation. The new WinRT APIs take that into account.  Roughly 10% to 15% of the WinRT APIs are async methods. That makes it very important to support async programming in the languages.  Otherwise, your app would block the UI thread unnecessarily  and your UI would frost over.

Most of my audience has seen the async features before, so I won’t dwell on the features of async. Let’s just focus on how these upcoming async features interact with the WinRT libraries.  The move to WinRT shows the benefits of the pattern based await specification. The WinRT methods support the awaitable pattern, even though they don’t return Task<T>. You can await them directly.

One other important point Anders went over in some detail:  async methods do not necessarily mean creating more threads.  However, work delegated to a background thread can be asynchronous. Network APIs and File APIs are async, but do not create new threads. They will use IO Completion ports, or other noification means.

Roslyn gets the big stage

I can’t do Anders’ demo justice in a blog post. Even if you’ve seen earlier Roslyn demos Anders’ has done, watch this.  I’m amazed at how far along the Roslyn team is. I think Anders is thrilled as well.  He was clearly very happy to announce that the team is releasing a CTP for the Roslyn compiler in roughly a month. It will install on top of Visual Studio 2010.

As for the features, I’m really amazed to see the refactoring work in the C# immediate window.  That must have been quite a bit of work. The compiler has also seen significant progress, if the team is far enough to release a CTP.

It’s also clear to me that the Roslyn work would not have been progressing at this kind of a pace if Microsoft is not committed to making continued investment in these languages and the .NET managed environment. Equally important, .NET 4.5 and C# 5 can leverage the already announced async features in the WinRT runtime. It’s just one of many examples that show how much the .NET runtime and BCL design idioms have had an affect on the WinRT API design. Anders also showed some of this interop by creating a C# class library and consuming it in a Javascript Metro application.  It’s amazingly easy.

Starting to grow some Metro skills

I spent the rest of the day learning about the Metro programming model. My initial impression is positive.  The APIs seem very natural from both C# and Javascript.  There has been some very interesting work in the Projection layer to the WinRT APIs in a natural way to any of the supported environments (Javascript, C++, and Managed code).

There are some very strong recommendations and guidelines regarding a well-behaved Metro application. They cover areas like suspending your app when necessary, use of the screen real estate, tiles and other notifications.  As I build some samples, I’ll cover those in more detail.  There are a few key messages I got on Metro applications:

• The guidelines provide consistency for the user. Following them will almost certainly give your application a better chance at gaining acceptance.
• There are a lot of ways for your app to interact with the user. They include tiles, toast, and badges.  Think carefully about what you want to tell the user, and how you want the user to react to that information. It will help you build a better app

Overall, I like the Metro experience, and the programming model. I do have quite a bit to learn before I feel like I can give guidance on creating those applications yet.

Created on 9/16/2011 1:24:18 PM

Filed in: C#, Windows 8, Metro, Technology, SrtInsights,

I must preface this post. There are more than 10 concurrent sessions in each slot, and obviously I’ve only seen one in each session. I also picked my sessions based on my perspective as a .NET / C# developer.

I’m actually very pleased with what I saw today about the WinRT APIs and the C# language.

Windows RT: A Modern Windows API

Let’s start at the WinRT layer. Currently, the base Windows API is Win32. That API dates back to 1995. In fact, the Win32 API was based on and consistent with the Win 16 API, which means its design is even older. Its design dates back to a day when C++ (and other object oriented languages) were not very popular. It also dates back to a time when the concept of having a computer attached to the internet whenever it was on was unthinkable. It’s also an API that has grown considerably over the last decade and a half. New features and capabilities have been added with each successive release of Windows.

The Windows Runtime (WinRT) represents a redesign of the entire API surface for windows. Throughout the day, I heard three phrases repeated from presenters discussing this new API:

• decreased surface area
• consistent view of the system across languages
• Consistent guidelines for API across all Windows functions
• A modern object oriented API

I believe the WinRT team redesigned the Windows API from first principles, and created a modern API for the Windows system. It should be easier to use, and simpler for developers to understand.

Accessible from many languages

The next layer up has some very interesting engineering capabilities. Most importantly, the new WinRT layer provides a projection of its API to managed languages. That’s critically important because it addresses a long-standing frustration for managed language developers: New OS features would be released, and those new new features were not accessible from the managed languages without developers creating their own managed wrappers on top of the new native APIs. With Windows 8 and WinRT, managed developers will see new features in projections for their language as soon as those features are available in the OS release. That lag between OS feature and its presence in the managed APIs should go away in this next release. Note these new features will also be immediately surfaced in javascript as well.

That means languages such as C# and VB.NET will immediately have access in their own natural syntax to any new features available in the OS.

In addition, the next version of the C# compiler (and the VB.NET compiler) can produce WinRT components. The projection infrastructure is already there, and if you desire, you can expose your current class libraries (almost certainly after some work to make them conform to WinRT standards). C# is a first class language for WinRT development, just like C++.

The costs

Of course, nothing is free. If you want to participate in this new world, you must conform to the new WinRT standards, and possible leverage newer capabilities, and replace some code.

Some of the .NET APIs are changing for WinRT. I don’t have an exhaustive list, and I’m not sure there is one yet. Other APIs are not exposed via WinRT. (They are still available as .net APIs, just not as Metro / WinRT APIs.)

In the build we got, .NET apps will run in the classic Win7 desktop. It appears that all class libraries (that don’t rely on the Win32 APIs) will run in either environment. I’m not sure about that.

In Metro, the CLR runs on top of the WinRT layer. Just like today, where the CLR runs on top of the Win32 layer. There’s really not a lot of painful change here.  Think about how thrilled you would be if you could write C# code that ran on other devices (like the iOS or droid platforms). if you think of WinRT that way, this makes sense: C# runs on both the win32 stack, and the new WInRT stack.

Some Q & A

caveats: I’m still trying to figure this out myself, and I’m sure I’ve got some of this wrong. It represents my current understanding:

Are .NET applications legacy applications?

Well, sort of. The Metro UI is a different UI paradigm. If your using the current Win32 controls (which includes WPF controls), your application will look really dated in Metro. The only way to fix that is to re-implement the UI (your View classes in an MVVM design) using Metro controls. However, C# and majority of the .NET APIs are first class citizens in this new environment. The rest of your application should be fine.

caveat: WinRT has new network APIs and File System APIs. You may also have to change some logic at your persistence layer.

Is .NET Dead?

As a marketing brand, probably. However, C#, VB, F# and other managed languages are continuing just as strong as before.

Why is HTML5/Javascript and C++ getting so much more attention?

I think that’s just because there’s a bigger story there. C++ has a new standard (C++, The Spinal Tap Edition: It goes to 11). And the tools for building modern windows applications with either C++ or Javascript have gotten much better.

It’s a good story for the platform. C# apps are as well supported as before. It’s just not as interesting of a story.

What about the future of the current Windows Desktop?

I don’t know. I’ve only had the build tablet for a day, and it’s a different experience. It’s pleasant for many tasks, but for others, I prefer a keyboard and the classic desktop. That may change as time goes on. And that will have a great bearing on how this evolves in the future.

My guess:  “desktop” apps will run fullscreen in a private ‘virtual desktop’ in the future.

Recommendations

You should recognize that the Metro UI represents a rather large sea change in what makes a great application in Windows. If you ignore it, your applications will start looking dated.

However, this doesn’t mean you should rewrite your applications in WinRT. At least not yet. However, I would think carefully about what your application would look like in Metro. Is there a great Metro experience for your app? If so, start that migration.

Of course, some standard recommendations still apply: If you separate the layers of your application, it will be much easier to preserve large parts of your application as it moves to Metro. Regardless of your plans moving forward, that would be a good practice.

We do live in interesting times.

Created on 9/15/2011 12:38:44 PM

Filed in: C#, .NET General, Windows 8, DevCenterPosts,

Steven Sinofsky discusses the changing world of computing. Form factors and user interaction models change how programs should work. I’m gad that’s at the core of Windows 8 design. In addition, Mobility now means devices that you use while carrying, not just devices you carry and then use. They have clearly been spending a lot of time determining what’s important to users now.

“Touch first, but still comfortable with a mouse and keyboard” is a great way to describe this important design considerations.  Historically, Windows had always been Mouse + Keyboard, and maybe touch. That message changes the design goals, and should provide better end user experience.

Observations on Julie Larson Green’s demo

That customized password design is great for new form factors. Good idea. It’s also going to be a great way to provide security.

The start page is a great idea, However, I’m concerned that what they’ve done is optimize for a very cluttered start screen. My opinion is that a better UX would be to optimize for a smaller number of tiles, and encourage users to have fewer tiles.

The IE demo shows some of the system level features to leverage for applications: the semantic clipboard sharing, the smart sharing. and the system-wide spell checking.  

The best design change for Windows 8 is that the focus is on the application, not on the system (or the system chrome). That really catches the changing face of computing. The second big change is that the system should be an ecosystem (web) of apps connected to each other, and the cloud.

And on to Building applications. The big picture seems to say this to me:

• All the managed languages are in.
• XAML based UIs are in.
• So is HTML5 / Javascript.
• The CLR/BCL seems to move into something now called ‘WinRT’.
• The runtime is surfaced to all clients, including Java script in the browser (at least IE).

There are open questions:

• Does WinRT contain the superset of the BCL APIs and the native C++ library? Or what?
• How many APIs are moving forward? And in what timeframe?
• What will the performance implications be for the managed languages with respect to C++?

The tools are moving forward in quite a few ways.  VS11 will have support for the HTML/JS development.  Expression Blend gains support for laying out HTML layout by introspection on the DOM.

Great discussion of the different hardware that Windows 8 runs on.  The key take away for the non-hardware nerd:  The OS is optimized for the hardware its running on. It will expose everything in place.

And of course, every Build attendee gets the developer preview tablet.

Sinofsky shows great demos of setup/refresh/and other system tools.  Once again, some really good design into making this a professional system that is somewhat accessible to the average use.

Next, he’s showing a lot of the multi-monitor support and power user synchronization.  There’s a lot for serious power users and developers.  Also, luckily, it doesn’t surface unless you want it.

Windows live synchronization. The big picture here is that it really does show the “Three screens and a cloud” message at its fruition.

There’s a lot of questions.  I am hoping to get some information on these areas over the rest of the week:

• How much control does an app have over sharing? This could be a security risk.
• How easy is it to create an app that runs well in both Metro style and desktop style?
• How much of the existing APIs are going to be surfaced in the Windows Runtime (WinRT)?
• F# wasn’t mentioned on the developer tools slide.  Is that an oversight? (I think so.  Don Syme is speaking at Build)
• How do my apps participate in the Sync PC Settings?

For more of my immediate thoughts, check out my twitter stream from today.

Final Thoughts

Overall, I’m very impressed. Windows 8 clearly is an ambitious redesign of the Windows system. It’s as big a change as the change from Windows 3.1 to Windows 95. It clearly reflects a lot of thought on how people do use computers today, and how they want to use computers.

Created on 9/13/2011 4:22:10 PM

Filed in: upcoming attractions, Technology, Windows 8, Metro,

With Steve Jobs leaving Apple, our industry faces something it hasn’t faced in decades. The two men that built the PC era, Bill Gates and Steve Jobs, have both left the companies they founded.

I don’t think it’s possible to overstate the effect these two men, and the companies they’ve built have had on the IT industry. Before Apple and Microsoft, individuals did not have computers. The most powerful device most people had in their homes was probably a programmable HP calculator. Now, it’s just expected that people have a computer (either PC or Mac), and a phone with much more power than those early computers.  Students at college, high school, even middle schoolers are expected to have access to a computer. Before Gates and Jobs, students were lucky if a high school had a single computer, or any kind.

The proliferation of personal computers spawned so much in the industry. The web would not be what it is today without the industry these men created. Amazon would not have succeeded without computers in almost every home. Buying online makes no sense if you can’t be online at home. Google would be a research toy if the only way to be on the internet was at a research institution. eBay would be a few research geeks trading used disk drives for mainframes and workstations.

It’s right to give the credit to these two men. Remember that they won’t the only companies or people involved in the start of the PC movement: Commodore PET, Atari, TRS-80, and a few others all tried to compete in this space. Apple and Microsoft made home computers, and personal computers a world wide mass-market. Other large companies could have owned this space, most notably HP. These two men had the vision to grow this market, and to own it.

So, what’s next?

I’m not sure, but it’s a fun time in the IT industry, because of that uncertainty. Will we look at Larry Page and Mark Zuckerman the same way we look at Jobs and Gates? Will someone else emerge? Or, will Microsoft and Apply both manage to remain leaders after iconic founders have left? How far is the industry moving beyond the personal computer/mac?

Most importantly, how much value is in new hardware, and how much value is in the software? And where does that software live?

Their 2007 joint session

A great way to get some perspective on these two men is to watch this video of Gates and Jobs in 2007. There’s a lot of perspective from two men who built an industry.  Here are some of my favorite bits:

Bill Gates discussing his first trip to Apple, to work on Apple Basic’s floating point handling. All his data was on cassettes, “which was how everyone did it”. Yes, software written by Bill Gates ran in the Apple II.

I liked how both men said what they remember most was always being “the youngest guy in the room” at most business meetings.

Steve Jobs credits Gates with creating the first software company, a company where the business model was around selling software.

Bill Gates crediting Apple with recognizing that the home computer was a mass market machine, and an “incredibly empowering phenomenon.”

Throughout their careers, both men said that they “created the products they wanted to use themselves.” I think there’s a lesson there for every business: the farther you are from your target market, the less likely you’ll be able to succeed.

Jobs talks extensively about his return to Apple. He credits Apple’s turnaround with a change in attitude. He said when he came back, Apple’s culture had become one of a zero sum game: for Apple to win, Microsoft had to lose. Jobs said that was unsustainable: If that was the game, Microsoft had already won. He took investment from Microsoft, found new markets, and grew Apple to where it is today. I’ve had similar conversations with business reporters in our area. They are so tied to the American auto industry that they see every market as a zero-sum game: gains by one company must (be definition) mean some else is losing. They don’t understand when companies like us see competitors grow, and find that a good thing. It’s a high growth industry, and I want our area to see as much of that growth as possible.

Jobs shows how you can attack what looks like a mature market, if you have something worth selling. He talks about the fact that the portable music player market was dominated by Japanese companies (Sony, in particular) before the iPod. Not anymore.

Two segments from Jobs point very clearly to the future (even 5 years later). First, listen to him describe the iPhone maps application. Software that is tailored for the device a user has will always win over a general solution. Period. The iPhone maps app uses the same data that Google maps in a browser uses. But, it’s tailored for the device, and works much better.

As they talk about what’s next, Steve Jobs says, “Everything is a computer in a different form factor.” He’s right. You will probably use several different devices today where the value is not in the physical device, but in the software running on that device.  It’s still a growth market, because more and more devices we use are really computers. They just look differently.

My take on the future of software

I think the computer and mac markets are going to grow more slowly. They are still growing. The high-growth markets are in the other devices and cloud + device based software.

These two men, and their companies, created a completely new ecosystem, and that ecosystem is now morphing in ways these men didn’t predict.

Only one thing is crystal clear: The market for software is growing, and growing exponentially. I’m still grateful for the contributions these men made in creating this ecosystem.

I’m going to close with a look into the future for both Jobs and Gates. What makes me saddest about Jobs stepping down for likely health reasons is that he won’t get to enjoy the second career that Gates is having with the Bill and Melinda Gates Foundation.  To see Gates put his energy and economic resources behind problems like malaria, and global hunger is very hopeful. I do wish Jobs would have the same opportunity to tackle some of the humanity’s biggest challenges. We’d all be the better for it.

Created on 8/31/2011 9:18:01 AM

Filed in: Business, News, SrtInsights,

I try to avoid performance topics in my blog, because it’s very hard to create generalizations on performance. So, read this not as general performance guidelines, but as a way to understand Lazy Evaluation, LINQ, and Functional Programming.

A developer asked me a question about an algorithm that calculated some statistics for a very large sequence of numbers.  Here’s a (slightly) modified version of the code that calculated the Standard Deviation:

var mean = sequence.Sum() / sequence.Count();
var variance = sequence.Select(n => n * n).Sum() / sequence.Count() -
    (sequence.Sum() * sequence.Sum()) / 
    ((double)sequence.Count() * (double)sequence.Count());
var stdDeviation = Math.Sqrt(variance);

In the production code, each value in the sequence is calculated from other values, and requires a file read.

The important point for this code was that the sequence (more than a million numbers) was being enumerated eight times. Every call to Count(), or Sum(), including calculating the sum of squares, required enumerating the entire sequence. For a sample like this, you could pre-calculate and store the count, sum, and sum of squares:

double sum = sequence.Sum();
int count = sequence.Count();
var mean = sum / count;
var variance = sequence.Select(n => n * n).Sum() / count -
    (sum * sum) / ((double)count * (double)count);
var stdDeviation = Math.Sqrt(variance);

More complicated algorithms may require more work.  In many cases, a better solution is to use a different method, Aggregate, to calculate all the needed values in one enumeration.  Here’s the same calculation using one enumeration to calculate the sum, sum of squares, and count for the sequence:

var seed = new { Count = 0, Sum = 0.0, SumOfSquares = 0.0 };
var accValues = sequence.Aggregate(seed, (currentTotal, element) => new
{
    Count = currentTotal.Count + 1,
    Sum = currentTotal.Sum + element,
    SumOfSquares = currentTotal.SumOfSquares + element * element
});

// now, calculate Standard deviation:
var mean = accValues.Sum / accValues.Count;
var variance = accValues.SumOfSquares / accValues.Count -
    (accValues.Sum * accValues.Sum) / 
    ((double)accValues.Count * (double)accValues.Count);
var stdDeviation = Math.Sqrt(variance);

I said in my opening that this wasn’t about performance. In fact, in my tests on a sequence of random numbers, all three samples take very similar times, within 100ms. In the full production version, where enumeration took much more time, and there were more calculations (resulting in more than 8 enumerations), the results were quite striking.

Another possible enhancement to this algorithm would be to use a new version of Aggregate in PLINQ to perform some of the calculations in parallel.

What I’m saying is this: please don’t rewrite LINQ queries that your happy with. Instead, remember that lazy evaluation means calculating the values each time. File this away for later and when you see code that does exhibit the problems I mentioned above, try folding enumerations into a single operation that calculates multiple results.

Created on 8/29/2011 1:10:24 PM

Filed in: C#, DevCenterPosts, LINQ, Technology,