Ubiquitous Connectivity & Time-based Internet Billing

I am currently sitting on board the Dawn Princess with anchors down in Akaroa. I am half way through a two week cruise around New Zealand with my family. It’s a good break from our busy lifestyle back in Melbourne.

The timing of our family holiday is a little awkward because I am missing the excitement around the announcements made at BUILD 2014 last week. Or I would be if I wasn’t able to connect from the Internet from the ship as the details unfold.

Aboard the Dawn Princess is a ubiquitous Wi-Fi network which is available in all the staterooms and most of the common areas. The Wi-Fi network routes through a satellite connection backed by MTN Satellite Communications. When using the Internet I pay at a rate of approximately $0.30 to $0.80 per minute depending on the package.

Having cruised before I was aware of these pretty steep charges so we organised a local SIM card for mobile data access when ashore. The mobile data plan is of course tied to data volume usage rather than time. Time-based billing for Internet access to be strange in this era of mobile computing. The thing that I miss most about not being connected all the time is the absence of casual interaction with my information sources (e-mail, social media, news headlines, browsing etc).

I certainly can’t afford to be online all the time to receive these notifications, so for BUILD 2014 content, I logged in to get a quick synopsis of what is being discussed and disconnect. When I was ashore I set my various mobile devices to download content (such as the keynote videos).

The whole experience has left me pondering why satellite access (at least in this instance) is charged on a time based model. Surely the ship maintains a constant satellite connection so why not allow passengers to be constantly connected and then bill a lower rate for actual usage. The administrator of the ship-based network could apply QoS to the traffic to ensure essential traffic is given preference.

Another curious aspect of the setup here is that I can’t access OneDrive or OneNote (which is backed by OneDrive). I can understand that the ship might not want passengers syncing their local content across the link (especially with all the high resolution photos captured) but it sure is a pain when I want to access one of my Notebooks from OneNote. This makes me think that the critical resource is indeed bandwidth, but by charging for time the ship ensures that passengers don’t accidentally set their devices syncing constantly.

Overall I have been pretty impressed with the strength of Wi-Fi connectivity on the ship (kudos to Princess Cruises for that). I just wish that the route to the Internet didn’t have such a big toll gate in front of it. Is there a cruise ship out there that caters to geeks wanting to be constantly connected?

Maybe someone from MTN Satellite Communications could explain why satellite communications might be billed on a time basis.


Partnership Vacuum

My role at Readify is pretty diverse. One day I can be up to my elbows in technical detail and other days I can be focusing on business relationships. I’m pretty sure that my technical background influences the way I look at business relationships.

I tend to look at relationships in terms of mutual benefits. The best partnerships are formed where both parties can put something into the relationship that the other really appreciates and can benefit from. Every so often I talk to organisations where the benefits don’t align to a great need on one or both sides of the relationship. In this situation the potential partners should agree to part ways and invest no further but keep the door open to future collaboration, but what can happen is a kind of “over politeness” where neither side are willing to admit that they see no benefit in a formal partnership. The result is the creation of a partnership with no activity at its centre, creating a kind of partnership vacuum.

Moving forward I’m going to try to be better at calling this out when I see it. The cost of not avoiding partnership vacuums is exertion of effort trying to create artificial value where no natural genesis exists.



OneNote vs. Evernote vs. Google Keep

Comparing OneNote and Evernote might be missing misreading Microsoft’s intent behind recent announcements.

OneNote has gotten lots of attention this week when Microsoft release OneNote for Mac. Microsoft also made OneNote free for Windows users and is opening up a cloud API for integration.

This recent activity has prompted many to compare OneNote to Evernote. Evernote is a popular third-party note taking tool with great support on most platforms.

While the effects of the announcement may impact Evernote, I suspect the real target is Google Keep. Google Keep is part of a much larger ecosystem of productivity tools by Google, including Google Drive.

All three products exist within an important category that I call “memory augmentation”. They are distinct from traditional productivity tools such as word processors and spreadsheets. They allow for the capture of unstructured (or lightly structured) detail.

I have been a OneNote user for years, and enjoy the pen input capabilities on Windows. But that power is useless without ubiquity of access, and that is what the OneNote announcement provides. Google needs to step up here and start providing access to their services on Windows Phone and Windows if they want to compete.

Writing Engaging Yammer Posts

The first sentence of Yammer posts should capture the essence of your topic to better engage your audience. If you don’t, summary representations of your post risk having their message hidden below the fold.

I work in an organisation that is taking advantage of Yammer. This tool can help lift the burden on e-mail volume and increase collaboration by being more open.

When I make an internal announcement I prefer to make it on Yammer because I can see feedback and dip in and out of the conversation.

Posts on Yammer lack a dedicated subject field. This might seem to be a critical flaw in the service, but I have come to appreciate it. When a Yammer post gets displayed in summary form only the first few chunks of text are visible. This is true of e-mail notifications and digests, mobile applications and the Yammer Inbox.

This means that posters to Yammer need to capture interest in the first sentence of their post. If you waffle you risk having the message missed in the stream of content on the enterprise social media tool.

I have found this constraint to be a blessing in disguise. My flowery writing style has begun to change as a result. This teaches me that constraints aren’t always negative. Sometimes they have positive consequences as the following articles can attest.

  1. Embrace Constraints in Getting Real by 37signals (now Basecamp)
  2. Why Innovators Love Constraints in HBR by Whitney Johnson
  3. Constraints Drive Innovation by Jim Highsmith

Recently one tool that has helped me deal with this constraint is Hemingway, a simple web-based app. Hemingway analyses text and reports what grade level you are writing and other characteristics. The following screenshot is an earlier version of the text in this article. You can see for yourself how the content has evolved.


Perhaps one of the lessons I need to relearn is brevity, and with that I will end my post.

Remotely Debugging Web Jobs on Windows Azure Websites

Yesterday I posted up some thoughts about how to streamline deployment of .NET-based Web Jobs along with your web-application. Continuing on with Web Jobs I thought it might be interesting to figure out how to debug them once they are deployed. With Windows Azure it is now possible to remotely debug a web application via Visual Studio when it is running in Windows Azure Websites.

Using the same mechanism it is also possible to attach to a running Web Job process which can help you dig into problems in Web Job execution during development (I wouldn’t recommend attaching a debugger on a production site). Unfortunately the process is a little kludgey right now so I’m not sure how effective this would be as a “normal-case” debugging scenario, but it’ll work in a pinch.

Before your start, to help you with the timing issue you might like to insert a Thread.Sleep(…) into your job just to give you enough time to attach to the process. Once you’ve got that updated Web Job code deployed start the debugger by attaching to the Windows Azure Website via the Attach Debugger menu option in Server Explorer.


Visual Studio will then spin away loading symbols etc. Once that is done go into the Windows Azure management console and start the web-job. At this point you need to work fast (depending on the value of the Thread.Sleep(…) that you put in.

Go into the “Debug | Attach to Process” menu item and select the web-site you are debugging from the Qualifier drop down (this is the remote debugging session that is currently supporting your web-app debugging). What you should see is your web-job executable in the list of available processes.



Once the debugger is attached any breakpoints that you have set within the web-job code will be hit and you can step through line by line.



Bingo! So now you know how to debug Web Jobs remotely via Visual Studio. I’d really like to see this process streamlined a bit so that when you attach a debugger to the web-site it automagically will hit breakpoints in the web-jobs that are part of the overall deployment.


Deploying .NET-based Web Jobs to Windows Azure

I was very excited when I learnt about the new Web Jobs preview feature on Windows Azure Websites. The ability to run separate background processing jobs alongside a web application is one of the critical features of any complex web application.

Amit Apple has a really good article covering the various deployment options for Web Jobs which I would recommend reading. If you are deploying a Node.js (or other script-based) application the convention based deployment model works very well but you might be wondering how you can streamline the deployment of a compiled binary along with your web application.

Managing Web Job Files

Let’s say that you have a .NET solution consisting of an ASP.NET web app and a simple console application. What we want to do is execute the console application as a Web Job, pretty straight forward.


In order to deploy a .NET-based Web Job you need to first compile your .NET code and then drop the executable or its dependencies into the App_Data/jobs directory structure. You could manually compile the files and then copy them into the directory but you are likely going to want to do this 100s of times as you build out the jobs, so you need something a little bit more productive.

One approach that you can take is to edit the *.csproj file for the web job console application itself. If you right mouse click on the console app and select Unload Project, then again to edit the file you can scroll down the bottom and update the AfterBuild build target as in the SimpleWebJob.csproj example below (contents removed to keep the file brief).


In the sample above I’m pushing the executable into the executable into the appropriate folder in the ASP.NET project. A more complete example might include copying configuration files and dependencies as well. You also need to make sure that you include the files that are being copied in the ASP.NET project itself so that they can get pushed up to the server.

Even though the web app isn’t directly referencing the console application, the console app is actually a dependency of a web-app, so you might want to do is right click on the web app project and select Build Dependencies | Project Dependencies to explicitly specify that SimpleWebApp (in my example) depends on SimpleWebJob.


Once this is done you should be able to just publish your project from Visual Studio and the web jobs should automatically be created.

Room for Improvement

The Web Job feature is still in preview so I think it is fair to expect some further evolution in what you can do with Web Jobs. As a .NET developer I hope that the deployment process can be streamlined somewhat for .NET-based executables. Another thing that I would like to see is the ability to deploy a *.webjob file along with everything else in the directory which is used to provide additional metadata about the web job (such as being specific about what file is the entry point along with scheduling data).

Overall though I think it is a welcome improvement to Windows Azure Websites!

Death of the Start Screen Exagerated

It seems like the online media is foaming at the mouth about Windows 8.1 Update 1 supposedly making the move to boot by default to the desktop. The first article I came across was by Steven J. Vaughan-Nichols over at Computerworld followed by an article at Mary Jo Foley over at ZDNet (who gives the topic a much more balanced treatment).

Where Mary Jo Foley stops at reporting the news, Steven’s opinion piece is vitriolic which is typical of his previous articles. I mentioned to one of my co-workers the other day that I was disappointed in the state of tech journalism these days. Alas, there is only so much news to go around which means that content ends up being rehashed – so the only way to stand out is to write an opinion piece, the more bitter the better.

With that out-of-the-way, I have to acknowledge that where there is smoke, there is fire. So what about the rumour that Windows 8.1 Update 1 will boot straight to the desktop. If the rumour is true it is worth stepping back and thinking practically how this might work.

When Microsoft introduced Windows 8.x, the Start Screen didn’t replace the desktop. Rather the Start Screen replaced the Start Menu. The Desktop was always there in the background, it was just as if immediately after login that the Start button had been pressed and a full screen start menu was being displayed.

I suspect that Microsoft might ideally want to just boot to the desktop by default for devices that don’t have a touch first experience (desktop PCs and laptops) leaving touch first devices to boot to the Windows 8-style Start Screen. This would give users balance the best possible experience on their particular devices form-factor.

Some of the press has pointed out that if you boot to the desktop, then how will users know to launch metro-style apps? Well, remember that the Start Screen did not replace the Desktop, it replaced the Start Menu. So when a user presses the start button on the desktop (or on their keyboard) the Start Screen would still be displayed. If this continues to be the case then metro apps would still be discoverable in a desktop environment.

As Mary Jo Foley pointed out, leaked screenshots of the Windows 8.1 Update 1 UX reveal that users will be able pin metro-apps to the start menu. This means that users could quickly switch between legacy desktop apps and modern apps. I suspect that Microsoft has more plans for blending the metro and desktop environments.

I speculate that in a future release (not necessarily Windows 8.1 Update 1) we’ll see metro apps being able to run in floating windows on the desktop along with API support to make apps intelligently respond to this environmental change. Windows Runtime (or WinRT) is the underlying platform for modern metro applications, but that doesn’t mean that you can’t produce a UI in it that is more optimal for a mouse/keyboard user.

The second change we MIGHT see is a Start Menu / Start Screen hybrid. So far the best concept of how this might work I have seen is this start menu/screen transition video which was posted recently (and received great reviews).

What this video hints at is that the theme for phone, tablet and PC operating systems moving forward is convergence. Microsoft has pretty much confirmed this to be the case for Windows and Windows Phone, but I suspect this will also happen with OSX/iOS. Google is an interesting case because they have two quite different approaches to apps in Android and Chrome OS.

For Windows the key ingredient to convergence is Windows Runtime. Not only does Windows Runtime expose the UI building capabilities, but it also surfaces other OS features, file system, networking, sensors etc. WinRT modernizes key aspects of the existing Windows API (in Win32) in a way that is suitable for desktop, tablet and phone.

In summary, I don’t think that booting to the desktop on desktop-style devices spells the end for either metro, or the Windows 8-style start screen. Rather I think it’s just a continued fine-tuning of the user experience to support as broader range as users as possible. Indeed this kind of UX spread is a necessary feature of a single operating system running on a multitude of devices.