I know it’s been a while since I posted much on my blog here. The coding project I was engaged in at Microsoft took up much of time between January and March, and the focus on coding didn’t leave much time to write about said coding. The //build came along and I’ve been working on Visual Studio feature guides with our marketing team.

I also discovered, in the process of coming back to my blog and updating WordPress, that the MySQL database that you can get through an Azure account (where I host this site), has a 20MB limit on ClearDB’s free tier. While updating WordPress, which does database updates as well, the MySQL file exceeded that limit and so the database got set to read-only. This, of course, meant that the database couldn’t be updated which then got me stuck in the WordPress database update loop-of-death.

Having returned from //build last week (where I spent most of my time in the Visual Studio cross-platform development kiosk talking to developers about Cordova, Xamarin, the Universal Windows Platform, and cross-platform C++), I finally got this sorted out by deleting all the spam comments from the WordPress database to reduce the file size, after which the update worked and I can post again.

[Addendum: the spam comments continue to come in at a frightening pace! Fortunately, the akismet plugin for WordPress does a good job at catching them, and will supposedly auto-delete in 15 days. However, the sheet volume of spam (many of which are 1-2 pages long) and all of akismet’s metadata it saves for each one, generates quite a few MB of garbage data in the database. So I’m having to monitor all this more closely. I hope soon to migrate the whole DB to an Azure database with a much larger quota.]

Speaking of cross-platform development, two other pieces I worked on recently are summary topics for Visual Studio Application Lifecycle Management (ALM) features as they apply to Cordova and Xamarin projects. You can find those topics on the MSDN Library:

In the meantime, our coding project team has been writing up our learnings for MSDN Magazine, so you’ll see those articles later this summer. I’m working on cleaning up my Xamarin client code, which will be the focus of Part 2 of the article.

A few folks have asked, by the way, whether I’ll be updating Programming Windows Store Apps with HTML, CSS, and JavaScript for Windows 10 and the Universal Windows Platform. Because I’m no longer with the Windows team, I won’t have working hours to focus on that project. What I’m looking at, however, is moving to something of an open-authoring model. I’m hoping first to split the Windows 8.1 book into two parts. The first would be WinJS-focused and separate from Windows, as WinJS is now its own open-source library. The second part would be Windows apps using JavaScript without the WinJS stuff.

Then I can put the files on GitHub and invite contributions, serving more in the role of an editor than a writer, though I’d probably still write some. Anyway, let me know what you think of the idea!


Similar to my previous post, but perhaps not quite as fun, is an account from Fighter: The True Story of the Battle of Britain, by Len Deighton, which I just finished.

Any comparison of the Merlin engine [as used in the RAF Spitfire and Hurricanes] and the Daimler-Benz DB 601A [as used in Messerschmidt Bf109’s] must begin by mentioning the latter’s fuel-injection system. …

Fuel injection, which puts a measured amount of fuel into each cylinder according to temperature and engine speed, etc., was demonstrably superior to the carburetors that the Merlins used. Carburetors are, at best, subject to the changes of temperature that air combat inevitably brings. At worst they bring a risk of freezing or catching fire. And with such large, high-performance engines, the carburetor system seldom delivers exactly the same amount of fuel simultaneously to each cylinder. Worst of all, the carburetor was subject to the centrifugal effect, so that it starved, and missed a beat or two, as it went into a dive.

The RAF pilots learned how to half-roll before diving, so that fuel from the carburetor was thrown into the engine instead of out of it, but in battle this could be a dangerous time-wasting necessity.


Engineers–those on trains–in the 1800s got a good start in the art of hacking. This is from The Story of American Railroads, a thoroughly well-written and entertaining book by Stewart H. Holbrook written in the 1940s that provides many quotable passages:

Although neither the Santa Fe [railroad] or most of the other roads were in a hurry to adopt new inventions, the Santa Fe held in high esteem a gadget known as a Dutch clock. This device, perhaps the most unpopular one with railroad men of the day, was set up in the caboose and it noted and recorded on a tape the speed at which the train traveled. The rule was that freights should maintain a speed of eighteen miles an hour, no more, no less. The Dutch clock soon brought reprimands to all freight conductors who tried to make up time for the breakdowns of equipment that were forever happening.

After considerable discussion of the Dutch clock, the boys figured out a method of handling the menace. On the first sidetrack out of the terminal, the crew would uncouple the caboose, then uncouple the engine, bring it back to the rear on the main line, set it in behind the caboose, then use it to slam the caboose into the standing train at a speed of exactly 18 miles an hour. This, it had been discovered, so affected the Dutch clock’s insides that thereafter it continued to clock 18 miles an hour regardless of the speed developed. This fixing the Dutch clock was considered fine sport, and always left the train crew with a sense of immoderate satisfaction.