Cloud Cover, Episode 2: RoleEntryPoint, Windows Azure’s Billing Model and Troubleshooting Initializing-Busy-Stopping

Get Microsoft Silverlight
Don’t have Silverlight? Get it here or download the video in
MP4, WMA, WMV, WMV (High) or Zune format.

Here’s the second episode of Cloud Cover, the Channel 9 show where hosts Ryan Dunn and Steve Marx show you what’s in the Windows Azure cloud computing platform and how to get the most out of it.

Steve’s off being a jet-set celebrity – what kind of excuse is “I’m off to Japan to shoot a commercial”, anyway? – so David Aiken, who also knows quite a bit about Azure, is filling in for him in this episode. Here’s what David and Steve cover:

  • They do a walkthrough of the RoleEntryPoint class and show you the hooks that you can use to build web and worker services,
  • Explain Azure’s billing model, and
  • Show you how to troubleshoot the Initializing-Busy-Stopping loop.

This article also appears in Canadian Developer Connection.


AlignIT Webcast Series in March and April

Microsoft TechNet Align IT 2010 Tour -- Consolidation. Exploration. Optimization.

Dave Remmer and Adam Gallant, two of my colleagues from Microsoft Canada’s Developer and Platform Evangelism team, are hosting a series of webcasts aimed at enterprise application developers, architects and managers on Tuesdays from March 23 through April 27th.

Here’s what the series is all about:

With IT being an increasingly vital strategic asset and business enabler in organizations today, we all need to strive for excellence in execution in the IT projects we’re leading. There are a number of different ways to help create this excellence; so they’ve put together six, one-hour webcasts to give you our perspective on how to help make it happen. Starting with the ALM [that’s short for Application Lifecycle Management – Joey]  foundation of successful project delivery, they’ll look at architectural patterns for the web, for building secure solutions, for leveraging the cloud and client devices, for IT governance and operations, and finish up with real life stories from experts who’ve done it before. At the end of the series, they hope that you will gain new insights how to help increase business value and agility through IT by having a better understanding of how to leverage the Microsoft platform and toolset.

Here are the individual webcast episodes and their dates and times. To register for a webcast (and yes, registration is free), click on its title:


The “What’s New in Visual Studio” Sessions – March 1st through 9th in Selected Canadian Cities [Updated]


If you’re wondering what’s new in Visual Studio 2010, you’re going to want to catch these sessions taking place in March. You’ll get a grand tour of all the new capabilities as well as the new MSDN offerings that come with the new Visual Studio.

The “What’s New” sessions are taking place in these cities:

City Date Invitation Key
Edmonton Monday, March 1 8ACE98
Calgary Tuesday, March 2 9FA90A
St. John’s, Newfoundland Tuesday, March 2 C89B02
Mississauga Thursday, March 4 5A1CB4
Quebec City Tuesday, March 9 1C5C3C


Here’s the event schedule:

  • Registration & Breakfast
    8:30 a.m. – 9:00 a.m.
  • Event Opening Ceremonies
    9:00 a.m. – 9:10 a.m.
  • Live technical demonstration:
    What’s new with Visual Studio Team System 2010
    9:10 a.m. – 11:00 a.m.
  • Q&A
    11:00 a.m. – 11:20 a.m.
  • Event close / completion of evaluation form
    11:20 a.m. – 11:30 a.m.

If you’d like to attend one of these sessions, select the Invitation Key from the city whose session you want to attend and enter it on the Registration page.

This article also appears in Canadian Developer Connection.


Counting Down to Seven: 7 Rules for Your Mobile Strategy

Counting Down to Seven (Mar 15th at MIX 10): A series about ideas for mobile apps

Welcome to another installment of Counting Down to Seven, a series of articles about mobile app development that I’m writing as we count down the days to MIX10, when we reveal more about the up-and-coming Windows Phone 7 Series.

Cover of 'Mobile Deisng and Development'In an earlier article, I wrote that Brian Fling’s book, Mobile Design and Development, led me to a couple of instances where the number 7 appeared in writing on mobile development. The first was Tomi Ahonen’s thesis that mobile is the 7th mass medium.

The number 7 also appears in Chapter 5 of Mobile Design and Development, titled Developing a Mobile Strategy. In it, Fling lists seven rules for developing your own mobile strategy, which I’ve summarized below.

1. Forget what you think you know.

The mobile industry is highly competitive, evolves quickly and produces a lot of press releases full of speculation and empty promises on a scale that dwarfs that of the early dot-com days.

“Do yourself a favor and forget everything you think you know about mobile technology,” writes Fling. Instead, he suggests that you:

  • Ask the hard questions about your business, your customers and your development capacity without considering the latest hype about a new tool or technology.
  • Focus on what’s right for your user instead of simply emulating what your competitors are doing.
  • Forget what you think you know about mobile – it’s most likely wrong.

2. Believe what you see, not what you read.

Fling writes: “In mobile, any argument can be made, and for a few thousand dollars you can buy a
report or white paper that supports your argument.”

His suggestions include:

  • Mobile industry reports have a short shelf life. Anything over a year or so old is probably useless. (And you should probably ignore anything pre-iPhone other than for a good laugh.)
  • Ask your users questions in person, in their context, rather than relying on focus groups.
  • Record what your users say. “Nothing makes your case like your users’ own words.”

3. Constraints never come first.

There are many constraints in mobile development: the size of the device, processor speed, battery life, networks, business issues and so on. You will have to account for them, but if you do so too early, you might end up killing some ideas before they even get prototyped, never mind implemented.

Fling writes:

If you are concerned about the constraints of the mobile medium, know that there will always be constraints in mobile. Get over it. It isn’t a deal breaker. Just make sure you aren’t the deal breaker. Focus on strategy first, what they user needs, and lay down the features; then, if the constraints become an issue, fall back to the user goals. There is always an alternative.

4. Focus on the user’s context, goals and needs.

Here’s how Fling defines the terms:

  • Needs are simple. The example he uses is the need to eat. He says that our of context, goals and needs, a user’s needs are the easiest to predict if you know some basic information about the him or her.
  • Goals arise from needs. In his example, the goal is to get food.
  • Context is the user’s current state. It could be something like “I am at this location and I’m in the mood for Thai food.”

Fling’s suggested strategy for focusing on context, goals and needs:

  • Define the users’ context first. Without that context, you don’t have a mobile strategy, it’s just a plan of action.
  • Uncover the users’ goals, then try to understand how the user’s context alters those goals.
  • Once you know the users’ goals, find out the actions they want to take.
  • Look for ways to filter what you present to your users by their context.

5. You can’t support everything.

That’s right! Just stick with supporting Windows Phone 7!

But seriously: unless you’ve somehow got access to a big pool of developers to cover them all, you’re going to have to narrow down the number of devices you support – possibly even down to one. I’ll do what I can to make sure that Windows Phone 7 is the platform people want, but you need to see what platform your users are using.

Fling’s tips:

  • Start with the devices that your customers are using.
  • The most popular device or the one that’s easiest to develop for may not be the best device for your project.
  • If you’re converting a web application into a mobile app, look at your server logs and see what mobile devices are accessing it. Target those devices.
  • Go mobile phone window shopping and see what devices the stores are targeting at different types of users.

6. Don’t convert, create.

My mother, a piano player, bought an “electronic sheet music” tablet. The idea was that instead of having to keep lots of books and folders of sheet music, she could get rid of the clutter and have a convenient, easily expandable music library. Unfortunately, the device uses a standard desktop interface – actually, a sub-standard Linux window manager, not even a decent one like Gnome or KDE – and it’s a royal pain to use. Mom went back to sheet music on actual sheets of paper and the device is now gathering dust.

On the other hand, the TiVo – also a Linux device – has a great user interface. It’s designed around the way you use a TV, not around what’s easier to implement. It’s not a port of desktop TV recording software (most of which is terrible to use), but a whole new thing, and it’s better for it.

With that in mind, here are Fling’s “Don’t covert, create” tips:

  • Understand your user’s’ context. Knowing how, when and under what conditions your users will use your mobile app will allow you to create a better user interface and experience.
  • Don’t forget that mobile isn’t just a shrunken-down desktop; it’s its own thing, with its own strengths. 

7. Keep it simple.

That’s simple, not stupid. People tend to use their mobile devices while they’re on the go or doing something else, so helping them get their task done is far more important that loading your mobile app with features. Mobile users have to deal with many constraints, so show restraint in the mobile products you build.

This article also appears in Canadian Developer Connection.


Happy iBirthday, Steve Jobs!

Mosaic of Apple products arranged to form picture of Steve JobsImage created by Chasis Tsevis.

Steve Jobs, Apple iCEO and one of the leaders of the Esteemed Competition, turns 55 today. Happy iBirthday, Steve!

If you want a big honkin’ alternate version of this mosaic, check this out.


Counting Down to Seven: Charlie Kindel and the Windows Phone 7 Team’s Focus

"Counting Down to Seven" badgeTime for another installment of Counting Down to Seven, a series of articles about mobile app development that I’m writing as we count down the days to MIX10, when we reveal more about the up-and-coming Windows Phone 7 Series.

If you’re following what’s happening with Windows Phone 7, you should follow Charlie Kindel – both his blog and Twitter account. Charlie is one of the people behind the new “Phone 7” experience; I don’t think he’s exaggerating in his Twitter bio when he says “The future of application development for Windows Phones is in my hands.”

In his latest blog entry – Focus, Focus, Focus – he writes that the reason that Windows Phone 7 seems atypical of Microsoft is the power of “no”. The Windows Phone team didn’t just decide what they were going to build, they also decided what they were not going to build, and work around the “5P” framework of:

  1. Purpose
  2. Principles
  3. Priorities
  4. Plan
  5. People

Here’s the Windows Phone developer experience team’s stated purpose:

Our purpose is to harness the energy, talent, and attention of developers and designers with a platform and ecosystem that delivers on the developer experience end to end; that, combined with the phone’s end-user experience, results in a winning virtuous cycle.

From that purpose, they derived some principles, among which are:

  • Every decision we make must be made mindful of the effect on end-users. Simply put, the end-user is king. 
  • We will do a few things and do them very, very well; we are better off not having a capability than doing it poorly. There are always future versions.
  • No API will be created or documented without a clear use case; “build it and they will come” APIs almost always do nothing but create bad legacy.
  • We will build on the shoulders of giants; where possible integrate instead of create.
  • We will strive to not show our organizational boundaries to developers.

What’s truly interesting is the list of Windows Phone 7’s targeted developer segments. This is an ordered list, with the highest-priority segment listed first:

  1. Consumer Developer – Pro Devs who build products that are sold directly or given out for free to general public end-users.
  2. Non-Pro Developer – Non-Pro Developers building products for academic/personal use.
  3. In-ROM Developer – Pro Devs who build products & technologies that are sold to mobile operators or device manufacturers.
  4. Enterprise Developer –Pro Devs who build apps & technologies that are sold to corporate clients and businesses.
  5. IT Developer – Pro Devs who build apps & technologies that are only for use by their own corporation.

I have often quipped that sometimes using Microsoft stuff “feels like eating from the dumpsters outside a cubicle farm”; that is, that their software targets enterprise and IT first and small-shop/indie coders like I was last. This list inverts the priorities I image the Windows Mobile team had, and my response to that is “good”.

Charlie makes a point of saying that the prioritization is temporal; over time, the priorities may change and they will serve some of the lower-priority segments, but all the while adhering to the purpose and principles listed above.

Then there’s the plan. The plan is to have Windows Phone 7 ready for the MIX conference, and it looks like that will happen. “Events,” Charlie writes, “are great forcing functions for engineering teams”.

Finally, the people. The Windows Phone 7 team is a diverse bunch coming from all across Microsoft – the Xbox people, developer division geeks as well as members from Windows Live, Exchange, Windows OS, Office and Developer and Platform Evangelism.

Go check out Charlie’s full blog entry, which describes the Windows Phone 7 team’s purpose, principles, priorities, plan and people in greater detail, and check in on him often. If you’re planning on building apps for Windows Phone 7, he’s one of the people to follow.

This article also appears in Canadian Developer Connection.


var article = new List<InterestingDeveloperStuff>();

For your enjoyment and enlightenment, I present 4 articles featuring lists…

Soma’s Key Software Development Trends

S. Somasegar

S. “Soma” Somasegar, Senior Vice President of Microsoft’s Developer Division, writes about what he sees as emerging trends in the world of software development.  He says it’s not a comprehensive list of all trends in the world of building software, but trends where Microsoft is doing some serious investing of time, energy and Dark-Side-of-the-Force midichlorians. You’ll have to read the article for a more fully fleshed-out explanation of each trend, which I’ve listed below:

  • Cloud Computing: Or as I like to call it, “Servers as a Service”.
  • The Web as a Platform: Contrary to what you might have heard, The Empire’s pretty big on the web, on both the server side (from Azure to IIS to SharePoint to ASP.NET/ASP.NET MVC) to the client side (HTML, JavaScript/jQuery and Silverlight).
  • Parallel Computing: I can’t tell you the number of things I’ve ruined with threads. I eventually get them right, but wow, can they be a lot of work. .NET 4.0 introduces a number of parallel programming features that make taking advantage of the multicore power in even the cheapest of today’s machines much easier.
  • Proliferation of Devices: “Computer” no longer refers to just the machine on your desktop or in your lap and “user interface” is no longer limited to just “keyboard, mouse and monitor”.
  • Agile Development Process: The upcoming Visual Studio 2010 provides lots of support for agile processes. Hopefully, we’ll see third parties write plug-ins to support even more!
  • Distributed Development: I don’t just talk about geographically-spread work, I live it! I telecommute from the home office, HacklabTO or cafes, and my co-workers in Microsoft Canada’s Technical Evangelism Team pipe in from Mississauga, Ottawa and Calgary.

My first response to the list was “Hey, Soma, where’s mobile?”, but I choose to group it in with “Proliferation of Devices”.

Five Pervasive Myths About Older Software Developers

1960s computer programmers

I’m 42 years old. In most white-collar work, I would be seen as “entering my prime”. In the software world, many employers would advise me to “stop buying green bananas” (think about it for a moment if you don’t get the joke). Age discrimination is an unfortunate fact of life in our industry, which prizes youth and particularly its willingness to work long hours for little pay.

In his blog, Lessons of Failure, Dave Rodenbaugh debunks five myths about “older” software developers:

  • Myth: Older software developers are more expensive than younger ones, making younger developers more desirable.
    • Reality: Younger means cheaper, but a team of nothing but young’uns without much experience will cost you in the long run. Hiring experienced people is like getting insurance against some of the classic mistakes in project management and software development that you only truly learn in the School of Hard Knocks.
  • Myth: Older software developers are less flexible and less capable of learning new technologies because of their legacy knowledge.
    • Reality: It’s experience that makes software developers more capable of migrating to new technologies, frameworks and systems more quickly and in greater depth.
  • Myth: Older software developers are less able to perform the arduous tasks of software development (read:  work long, painful hours) because of family commitments and other attachments that younger workers don’t have.
    • Reality: They’ve learned the hard way that there’s a point of diminishing returns with long hours. I know I did.
  • Myth: Older software developers are less mentally agile than younger ones.
    • Reality: Yes, aging slows down the brain a little, but thinking faster isn’t always better. There’s also thinking wisely and using good judgment. To quote the old adage: “Good judgment comes from experience, experience from bad judgment.”
  • Myth: Older software developers are more jaded and cynical and therefore, less desirable in the workplace than younger ones.  Younger developers are more enthusiastic than older ones.
    • Reality: Passion is passion. If you have it for your job at 40, you probably really love that field. I know I do. [Joey’s note: Besides, have you met members of Generation Y? For a crowd so young, they’re an incredibly cynical and jaded bunch. I blame Gossip Girl.]

Why Matt Hidinger Loves ASP.NET MVC

Matt Hidinger I’m going to express a personal preference: I’d much rather build web apps with ASP.NET MVC than with Web forms. That’s the PHP-and-Smarty/Ruby on Rails developer in me talking. Matt Hidinger documents a “Web Forms vs. ASP.NET MVC” debate he had on IRC and lists these major points:

  • Fallacy: Web forms does everything I need it to.
    • Matt’s response: “getting something done, and getting something done in a testable, maintainable, long-term way, are entirely different”
  • Fallacy: MVC is just a bunch of <%= HtmlHelpers %>.
    • Matt’s response: “HtmlHelpers are 4% of the ASP.NET MVC platform. That’s like saying <asp:Textbox> is all of web forms” – he also points to an article titled Controls Do Not Make You More Productive.
  • Fallacy: Web forms is easier.
    • Matt’s response: “developers every day struggle with dynamic controls and databinding in even slightly-complex real-world scenarios. Mindlessly tweaking code and refreshing the page to see what ASP.NET will render.”

Matt also lists a series of facts, which I agree with:

  • Web forms is black magic
  • MVC enables robust Ajax support
  • MVC is closer to the metal
  • Data binding is confusing, full of indirection and runtime logic
  • MVC lends itself to good design
  • Web forms is miserable without JavaScript
  • MVC is testable
  • MVC allows multiple <form> tags

“I like coding. I hate shipping software.”

Microsoft "Ship-It" award for Sriram Krishnan, who shipped Visual Studio 2005 and .NET 2.0

Trey Stout says that shipping has all the worst elements of development, namely:

  • translating
  • documenting
  • testing
  • DLL hell
  • install scripts
  • customers
  • marketing

Ah, DLL hell, I remember you well. Once, a major customer’s office lost all reporting functionality from software I developed because they got a new printer, whose “install me first” CD added some DLLs which clobbered the ones from my app’s installation.

Trey also says that coding has all the best elements of development:

  • Talking with other developers
  • white boards
  • new tech
  • compilers
  • crazy features
  • jokes in comments
  • feelings of accomplishment.
  • satisfying diff emails

What’s the solution? In my case, it’s to go into developer evangelism. You get to code, and you don’t have to ship (don’t get me wrong – shipping has many rewards). Of course, if you want my job, you will have to pry it from my cold, dead fingers.

This article also appears in Canadian Developer Connection.