A mobile site on a budget

Came across this gem while looking through the code of a random site:

<script type="text/javascript">
       var mobile =
(/iphone|ipad|ipod|android|blackberry|mini|windows\sce|palm/i.test(navigator.userAgent.toLowerCase())); 
       if (mobile) { 
         window.location = "mobile_version/index_mobile.php";
       } 
</script>

While simple solutions are often the best, I’m not so sure about this one.

Creating a Microsoft Project 2013 App that accesses the VersionOne API (and other systems)

This is a strange post to write as the combined topics are things only likely to appeal to a select few people on this planet. Nonetheless, it was an interesting mix of technologies and frustration points, so I'm writing it up in the hope that someone else out there finds it interesting.

Introduction

I'm currently involved in a project where I'm using Microsoft Project 2013 (client only, no Project Server) to help manage things for an external customer. There's a couple of key systems that I need data from to support the project plan, one is our internal timesheeting system (to retrieve hours spent on a particular task), and the other is the customer's VersionOne instance (to retrieve hours remaining on a piece of work).

It became apparent very quickly that constantly flicking between these three systems for the next couple of months was going to end up being very frustrating, so I decided to look at whether there was anything I could do to speed things up.

Creating a Microsoft Project App

Having had some previous exposure to Visual Studio Tools for Office (aka VSTO), that is where I was expecting this journey to start out. However some research turned up something which looked even more exciting: How to: Create your first task pane app for Project 2013 by using a text editor.

A text editor! I'm sold! I was a little surprised that it appeared I'd be doing this entirely with JavaScript, and that VSTO wasn't going to feature at all, but such is progress.

While this is a very broad generalisation, no matter what you're planning on doing with a Project 2013 App, odds are that the sample app found at that link is going to be a really great starting point. The link gives you everything you need to know about the hoops you have to jump to in order to install an app, and the download gives you working code for common tasks that will "run" on any existing project plan (you may also find this link to be useful if you want to start more from scratch rather than editing an existing manifest/HTML file).

The format of these project apps is basically an XML manifest file which points to a HTML file. Both need to be loaded from a "trusted location" such as a network share (the link goes through this in detail), but once loaded you basically have a mini web app running in a side bar inside Microsoft Project. The page is rendered using some flavour of IE, so you're free to use any JavaScript plugins/libraries you want such as jQuery and Handlebars to compliment the methods you'll be using from the Office JavaScript SDK. These libraries can be bundled with your app or loaded remotely (which allows you to use CDNs for common libraries if you so desire).

It feels strange at first, but run with it.

Working with Project data and calling an external system

For my purposes all I needed from the Project side of things was to access a custom text field in the currently selected task. In my project plan this text field stores a unique identifier which is used in both the external systems I wanted to query. The plan was to use this identifier to query my external systems and then do something with the returned values.

It turned out that getting the data I wanted from the selected task was trivially easy. Here's a code sample where I'm getting the currently selected task, reading data from a column I specify, and using that to call an external system to get back some data. The code is run by clicking a button inside my App’s main HTML file:

In the example above I'm grabbing the value in "Text1", which is a custom text field, but you can do this for any field on the task at all. Simply change the enumeration as required from the list provided here: ProjectTaskFields enumeration (JavaScript API for Office). Note that you need to call getSelectedTaskAsync first to give the app some context before you're able to access the task's fields.

For completeness, renderData is a very simple function which uses a Handlebars template defined in the App's HTML file to display the returned data:

When it comes to using the returned values, I'd initially hoped to use them to directly update one of the task's fields, however this isn't possible with the JavaScript SDK (not that I could see anyway, if I'm wrong please let me know). Instead I simply display the values in the App's UI (which as this is simply a HTML page is a div), and can then copy/paste or type the value into the task if needed.

Initially this felt like a disappointment, but on reflection it feels like the right way to do it. It gives you time to look at the value and think if it feels right or not, that momentary pause to look at the old value versus the new one before updating it forces you to think more about the values rather than just mindlessly entering them. It also feels right from a security model point of view - it reduces the risk that rogue apps can violate the integrity of your project plan's data.

It's also worth noting that the debugging options for these apps seem somewhat limited. I didn't spot a JavaScript console, and the debugging choice of champions (using alert) doesn't work either. There may be some debugging tools available, but I simply didn't look that hard, and ended up just setting values in a div with an id of error-output when needed.

Accessing the VersionOne API

I need to start out by stating I'm not a fan of VersionOne. We use it over a VPN where the endpoint is about as far away from NZ as is technically possible, so its combination of countless AJAX calls combined with huge page size footprints has never sat too well with me. It’s sluggish and has always felt convoluted to use. So the thought of leveraging the API to allow me to spend less time using the actual product made me incredibly happy.

The documentation indicates that there's a number of different options for programmatically using VersionOne. I'd played with some of the C# SDK examples before, but in this case the fact that the Project App was very much JavaScript driven made it pretty clear that my only option was to use their RESTful API (which they name "rest-1.v1", because, why not?).

VersionOne has 2 different endpoints you can use - rest-1.v1 and query.v1. Here’s a screenshot of the main table from the page where they explain the differences between the two:

The table makes it sound like if you want XML then you use rest-1.v1, if you want JSON then you use query.v1. I'd tinkered about with the rest-1.v1 syntax in a browser address bar and pretty quickly found a URL which would give me what I needed. Here's an example:

http://yourendpoint/VersionOne/rest-1.v1/Data/Story?sel=Name,Number,Estimate,Status,ToDo&where=Number=%27B-06793%27

(It's worth noting briefly that ToDo is case sensitive and it DOES matter and that the value specified in the where clause needs to be wrapped in escaped quotes, and obviously updated to include the value you’re querying for)

This was giving me the data I wanted, but obviously it was in XML. Which was expected, because the document makes it clear that XML is all you can get using rest-1.v1. This presented me with 2 issues;

  • Working with XML in JavaScript is a quick route to an early death in my humble opinion (although I was pretty surprised to see that jQuery now has some inbuilt XML parsing functionality to let you query an XML document – I was interested in giving this a try, and would have if it hadn’t been for point 2)
  • I established pretty quickly that I was going to need to make my AJAX calls using JSONP, which means that call expects/needs JSON.

I could have worked around the first issue, but the second was non-negotiable, despite what the interwebs said. By that I mean that a number of examples out there seem to imply that you can easily authenticate against VersionOne using 9 lines of jQuery code. Here's a fairly recent blog post that gives a sane looking example: http://blogs.versionone.com/agile-development/2013/02/07/query-the-versionone-api-with-jquery-and-9-lines-of-code/

I tried a number of variations of the code contained in the above link, and it simply didn't work. I'm not sure if there's some VersionOne settings you can tweak to change the same origin policy or something like that, but as I don't administer the VersionOne system that wouldn't have helped much in my case anyway. The example everyone was giving simply didn't work.

At this point I looked into using the query.v1 syntax, and no matter what I tried (and I tried a lot) I always got back an empty JSON string. Again, not having control of the system (there may well be options and settings to enable/tune the query.v1 endpoint) all I could do was frustrate myself to the point where I was happy to say I'd exhausted all possibilities and move on back to the RESTful API.

Back with rest-1.v1 and JSONP, I tried implementing a custom dataFilter and a custom converter inside my $.ajax call. This sounded good in theory – grab the XML that’s returned, translate/convert it to JSON so that the data is in a format that jQuery is expecting. I got hopeful that one of those two options was going to work, but alas, no joy - my $.ajax call wasn't happy getting back XML from a JSONP call, but it needed the call to be via JSONP to satisfy the security requirements.

After a lot of frustration I decided to scale down my efforts. My downscaled plan revolved around having my App generate a clickable link which would take me into VersionOne so at least I could quickly get to the current task, even if I had to switch to another application in order to do it.

However while I was clicking around doing some tests on URL syntax, I noticed something interesting in Fiddler, which I'd left running on another monitor. That was that the VersionOne web front end was calling the REST API, and it was getting back JSON. I took a quick look at the request - apparently, if you add "&Accept=application/json" to the URL of your API calls then you receive JSON. I didn't see this anywhere in the documentation. Maybe I missed it, maybe not. If I’d missed it, I think you could probably forgive me for doing so based on the table describing their endpoints.

With a haze of red (for the time spent so far) mixed with a touch of glee (for realising I had a way forward) I dropped the new URL into my app alongside a chunk of code which is similar to the first example I pasted.

var url = "http://yourendpoint/VersionOne/rest-1.v1/Data/Story?sel=Name,Number,Estimate,Status,ToDo&where=Number=%27B-06793%27&Accept=application/json";

…and it worked. Weeeeeeeeeeeeeee.

Summary

What I've ended up creating here is going to save me countless hours over the duration of this project. It’s amazing how much more focussed you feel when you don’t need to constantly switch between three applications constantly – being able to stay in Project lets me stay focussed and get bored less quickly when updating the project plan.

The Microsoft Project side of things was surprisingly easy, and the sample app gives you exactly what you need to get going. The need to host the manifest and code on a network share is kind of quirky, and the JavaScript API has some security restrictions, however those were things that were easy to work around in my case - maybe less so if you're working in a locked down enterprise environment.

Getting what I needed out of VersionOne was frustrating, but that was expected. The documentation was incorrect, and there were a number of half completed examples lurking on forums. In the end the solution was simple, and I was so pleased when this worked. Anyone who's used VersionOne will know that the less time you spend using it, the more productive you will be.

If you’re one of the few individuals who have found this interesting then please leave a comment below – I’d really like to know if it was helpful.

Some quick Azure observations

Here’s a couple of quick observations and reminders that came to mind while doing some recent work to convert a legacy application from being hosted on a customer’s VPS up into Azure.

Working with Azure places a large emphasis on your DNS registrar of choice

Your domain names are important, you want to protect them and choose a good registrar. Your #1 criteria should probably be security (which I something I’ve talked about before), but you also want a good and flexible user interface.

A number of registrars have UIs that try to hide the complexities of how domain names work from their customers. They don’t provide full zone editing capabilities and instead they focus on making the most common operations simple. This can cause trouble with Azure, as the chances are that depending on what you’re doing, you may need access to the full array of record types.

There are some awful registrar sites out there – when you have to use them to change one or two A name records once every few years then it’s not a big deal to get what you need done quickly and get out of there, but when you need to use that same UI to create a wider range of records (including Azure’s auth records) for multiple application components on multiple domains and then do the same again for a test environment then that same UI can become very frustrating to use.

For all the domains I manage I use a service that gives me full control, unfortunately sometimes you’re forced to use the customer’s registrar, and somehow I’ve got a couple of customers who don’t put a powerful UI on their shopping list when choosing where to host their domains.

Azure really forces you to pay attention to your deployment practices

Web.config transforms have been around for a while, but even when you’re actively using them it can be surprisingly easy to slip into the habit of editing a file on the server for some changes, or not having every single thing handled properly.

That obviously gets a lot harder with Azure, and your transforms become a lot more important. You want absolute certainty that they’re doing what you think they are, because it can be a bit of a painful process if you need to use the FTP credentials to verify whether your app has a problem or if it’s just a slightly messed up transform variable.

Of course, it’s a really good thing that you’re forced to do this, but you need to plan time for it into your project – it can’t be something that’s tidied up after the project when you have time as you can’t deploy without having them sorted.

Won’t someone think of the Timezones

Services such as Azure Web Sites and SQL Azure are all set to use UTC. If your app uses DateTime.Now in C# or GETDATE() in SQL then stop and think about how it’s going to behave when you push it up into Azure.

Remember that working with timezones is hard!

Stop listening to podcasts at 1.5x

Stop listening to podcasts at 1.5x makes a valid point, however there’s an assumption that every podcast is created with “Tension, pacing, and anticipation” in mind. Some just aren’t that well produced or spoken, but have some interesting content, which is where 1.5x speed comes in.

For example, 3:54 worth of uhmmms and aaaaahs justifies 1.5x in my book:

How To Migrate To HTTPS

How To Migrate To HTTPS is a WIP guide from the Chrome team (you can guess what the guide is about from the title). Given that sites served over HTTPS are now receiving a rankings boost, this is something which is bound to be a common task in 2015 and beyond.

Having all the caveats and things to be aware of (such as information about SNI and the devices that don’t support it) in a single document for reference is really handy, both for people who have done this before as well as people who might be doing it for the first time.

Possibly interesting is that at the time of writing, the guide doesn’t contain anything about the deprecation of SHA1, possibly because of an assumption that all certificate providers will be forcing SHA2 as the default (however given the history of some certificate providers, making any assumption like this is a bit dangerous).

The subtle dig to other advertising providers who don’t support serving content over HTTPS at the end of the document is somewhat amusing, but totally fair enough.

Very useful.

On the state of streaming video in New Zealand

A couple of recent articles and events have got me thinking that the next few months are going to be a pretty interesting time in the world of New Zealand SVOD (that's streaming video on demand for those who don't like acronyms).

While I’m by no means a media writer, it's a topic I'm interested in as a media consumer, as a technology fan, and for another slightly obscure reason I can't talk about (yeah, sorry, I know that's kind of a lame thing to say).

With SkyGo, Lightbox (wth Spark starting to push it pretty hard), Quickflix, Netflix from March onwards, Neon (at some point), it’s going to be very interesting to grab some popcorn, sit back, and see how all this plays out.

Sky – late to the race, or not?

It was largely this article in the NZ Herald that got me thinking about the services that are going to thrive versus those who are going to die, and I’m backing Sky to succeed simply because it appears to herald (no pun intended) that Sky TV NZ sound like they’re paying attention and are prepared to do more than just introduce their own SVOD service with Neon (when it finally goes live).

There’s a couple of points which make Sky seem well positioned.

SVOD is an interesting market as it's part technology and part rights acquisitions. The exact split of those two is something I can't comment on, however I'd wager that the technology portion is a lot less than most people would imagine, and this is where Sky has a clear advantage. They already hold rights to a large amount of content and odds are they already have staff who are skilled in the nuances of rights acquisitioning.

On top of that is the fact that their SkyGo service (previously called iSky) was initially so awful, and has now become very usable. If they’ve managed to learn any lessons from this (which they may combine with anything they’ve picked up from watching Lightbox’s experiences), then odds are that Neon won't be plagued with too many teething problems upon their eventual launch.

However, there’s something else that makes me think Sky is going to end up being a winner in this space.

Disrupting Billing Paradigms

Here’s where I think Sky can benefit the most – Neon gives them an easy excuse to disrupt their current billing model without alienating existing customers too much. It gives them an opportunity to solve something that (I think) has been a pretty clear problem for them from a consumer perspective for quite some time – allowing consumers the ability to pick and choose channels without a need to disrupt their existing billing approach.

"If we have a Sky customer who is going to leave us anyhow we would much rather they find value in a $20 a month package Neon and stay with us rather than leave us altogether."

For as long as I can remember, consumers have always found Sky's lack of flexibility of its billing for broadcast channels as an issue – and unsurprisingly, most people also lack an understanding of the complexities of enterprise billing systems which leads to a lack of empathy towards Sky.

"Sky acknowledges the full premier service is not for everyone."

This article hints that they can clearly see a chance to address this with their SVOD service, which I think bodes very well for them. There’s also a chance that it’s not just going to be retaining customers who are going to leave – I’d really expect a ‘choose your own channels’ service to be something that’s attractive to many people who haven’t previously quite been able to justify the cost of Sky. That’s all new business.

Lightbox

I’m not going to write much about Lightbox – yet. I’ve just grabbed a free 12 months thanks to the current Spark promotion, and will be giving it a try before adding my voice to the range of mixed reviews that are floating around.

I will say that I do very much respect the approach of “version 1 sucks, ship it anyway”, and think that they’ve been showing a pretty good level of transparency in the support that I’ve seen on their Facebook page, but on the other hand am not sure whether releasing early without a native iOS/Android app did them any favours.

Spark’s current offer of 12 months free for all Spark Broadband customers also sends an interesting message, and I guess time will tell whether it’s the right one or not.

On Local Programming

The elephant in the room is what the wonderful world of SVOD is doing for local programming, and what the role of broadcast TV will be going forward.

More and more I find myself talking to acquaintances who don't EVER watch broadcast TV. This is completely understandable in this day and age, however if it happens on a wide scale then it threatens traditional models of justifying the creation of local content (that's "ratings" for those who prefer less words).

In the current model, a TV Production must have an agreement with a network that they will broadcast a show before it is eligible for any New Zealand on Air funding (I don’t know how the movie side of things works). It makes sense – there’s no point spending taxpayer dollars making something which isn’t going to be shown to people. However the networks are making their decisions on what to agree to show based on ratings, because ratings equate to potential advertising revenue – it should be pretty clear that SVOD services with no ads, or services like MySky which let people skip the ads mean that this model isn’t going to last for long.

Going forward, is there a role for Sky/Lightbox as a content creator, a la HBO and Netflix currently do in other countries? I really don’t see this happening, as it requires infrastructure of a different kind (such as people who develop and approve the shows and to be involved in aspects of their production), and I'd wager that it's more work and risk for a company like Sky/Lightbox to up skill on this side of things. Plus, the revenue model simply isn’t clear yet – you replace selling advertising space with what, exactly?

SVOD services provide a potentially “easier” way to insert ads (at the beginning, maybe, as is being done by some of the web based on demand sites run by the networks) – obviously if consumers are already paying for a service then there’s no way they’d expect ads, but maybe if it was only for local content then people would understand the necessity (cue Tui billboard, yeah right).

We make a lot of great shows that are important for the cultural identity of the nation (as well as providing a number of jobs), so I really hope that someone comes up with a way to keep this happening in a world where programmed broadcast TV is no longer the primary way we consume our media.

On Ratings

A slight segue on the current approach of measuring ratings. Currently, (AFAIK) it’s the Neilsen ratings that are primarily used to make decisions about TV shows. These are derived from around 400 households of varying sizes, with each household having a ratings box and needing to record who’s in the room at any one time (so they can tell when people give up on a show half way through and so on). These recorded figures are then multiplied to represent the entire TV watching population of New Zealand.

Initially, this sounded like a pretty small sample size to me, however I’m assured by someone with a Maths/Stats degree that it’s actually pretty reasonable. However it still means that a show might be seen to lose 100,000 viewers on a night simply because little Johnny decides to go out on a tagging spree with that $20 he stole from Mom’s purse rather than stay in and watch TV with the family.

It feels like an online world provides a great opportunity to get some more accurate metrics into the mix so that content creators (and bodies such as NZ on Air) can be empowered to make better decisions, however that’s not going to fix the aforementioned revenue issue.

Netflix

While it’s clearly well established globally, it’s going to be interesting to watch how the regional version is received. Many people I’ve talked to are writing the New Zealand version off before it has even arrived, expecting a vastly inferior selection of content compared to the US/Canadian versions that they’re accustomed to accessing via their VPNs.

It’s going to be very interesting to see what the content catalogue looks like, but also to see whether the promised crack down on VPNs and proxies eventuates (and whether we all end up blaming Slingshot and Orcon for it).

May you live in interesting times

All of this should result in better choice for the consumer. I’m genuinely looking forward to seeing how things play out over the next few months, and odds are there’s going to be some interesting stories to be read about the companies that survive versus those who don’t.

I honestly don’t believe I actually wrote “disrupting billing paradigms” in a post

Tags:

Site theme updated

A day or so ago someone (thanks Blair!) pointed out that this site wasn’t being too friendly to mobile visitors – in fact, it was displaying a 404 to every mobile visitor. Ouch. This happened before and I fixed it, however I didn’t fix it in a completely sustainable way.

However “fixing it” again still meant that the site was still serving up the same 6+ year old design to all visitors, and it really wasn’t a pleasant experience on mobile devices.

So I’ve just taken the time to do a very quick skin update to something which should display nicely on mobiles and tablets as well as desktop browsers. It’s a little bland for now, and there’s some fine tuning still to be done, but it’s much more readable.

Please get in touch if you spot any issues, as there’s bound to be some!

On a lighter note, Raygun.io’s Top 10 Developer Related Tweets of 2014

Continuing the theme from my previous post of 2014 round ups, Raygun.io’s Top 10 Developer Related Tweets of 2014 is well worth a read.

Tags:

Some pragmatic end of year roundups that are worth a read

It’s the beginning of a new year, which means that over the past few weeks there’s been a number of 2014 round up posts published out there on the internets.

Reading these can sometimes be inspiring, but sometimes they can have the complete opposite effect – “Wow look at all these people who are hitting all their goals compared to what I’ve achieved this year”. Sometimes it’s possible that this is due to authors only talking about the positives in their year, and presenting a somewhat unbalanced view of things.

Which is why I really appreciate those who approach their end of year round ups honestly, and aren’t afraid to discuss the goals they failed to hit alongside the ones they did.

So here’s a range of reading that match the criteria of being balanced and somewhat pragmatic, which you may find interesting if you’re a software developer / company owner / business type person.

JD Trask's 2014 Year In Review

JD is the co-founder and Mindscape and Raygun.io. I found his end of year round up interesting for a few reasons.

Firstly, he wasn’t afraid to publish his goals for 2014 well ahead of time. It’d be really easy to announce what your goals were while writing your 2014 in review, so actually publishing them ahead of time and being able to reference them is a much bolder strategy!

There’s a mix of personal and business goals in there. Sometimes as a company owner it’s really hard to balance/separate these. Personally, I’ve had years where I’ve felt like I’ve underperformed from a business perspective, but when you stop and take all the personal achievements into consideration it becomes clear that it was actually a pretty successful year. Work/life balance is important, tricky, and is sometimes completely omitted from these roundups.

The post also shows that with some goals it’s not as easy as picking a single win condition, and that the way you measure a goal may evolve over the course of the year. I’m talking about points #3 and #5, where there’s still been good a good level of success, even if technically the exact goal wasn’t achieved.

Kalzumeus Software Year in Review 2014 

Patrick McKenzie’s (@patio11) write-ups and blogging are pretty well known to a lot of software developer/business owners for many reasons. If you’ve not read his writing before, then you should have a nosy through his greatest hits as there’s some really interesting reading there.

I find Patrick’s writing and his story “accessible”, for lack of a better word. I can read about the startup exploits of the likes of Google, Twitter et al and not really feel that I can identify with those stories a great deal. Whereas Patrick’s story (tl;dr – working on stuff on the side, while working a 9-5 job) is one that is one that a lot of people are going to be able to identify with.

He also writes very well, and goes into an insane amount of detail about successes, failures, and everything in between.

The length of his 2014 roundup may put some people off, but it’s worth it.

2014 Year In Review – The year that sucked, or did it?

There’s some good reading from Amy and co over at unicornfree.com, and I came across their end of year roundup while reading some other posts (specifically Why Blacksmiths are Better at Startups than You and Why You Should Do A Tiny Product First).

The title very much implies that the content isn’t going to be 100% positive, and that’s indeed the case. Definitely worth a read.

The idea of giving up is worse than of it killing me: How $150,000 post-it came to be?

This one isn’t an end of year roundup, and it’s not even that recent, however I came across it during my holiday reading and it “kind of” fits in here as it contains a fair amount of looking back on experiences as well as discussing software/business stuff.

It’s a brutally honest documentation of a journey over many years of trying to create a startup company.

Here’s the thing – I really enjoyed reading this, but possibly for all the wrong reasons. It’s well written, funny (in a black comedy kind of way) in places, but the story itself doesn’t really have a happy ending. But for someone like me (who runs a successful services company, however still has a bad case of “SaaS Envy”, and who sometimes feels like everyone else is doing more interesting stuff than we are) it’s a great reminder about the ratio of startup failures to successes, and that there’s something to be really proud of in running a successful company even though you may not have invented TheNextBigThing.com (which probably needs all its vowels removed to sound like a proper startup).

 

If you enjoy reading any of these, or have some suggestions of other posts worth reading then please let me know!

Bye bye Zite - How to Switch from Zite to Flipboard

Somehow I managed to miss the fact that a terrible thing is about to happen – Zite has been acquired by Flipboard and is about to be killed off. I use Zite daily, and find it an invaluable source of articles to read. It manages to recommend content from blogs that I wouldn’t ordinarily read with a surprising rate of relevance.

Given that Zite will be merged into Flipboard, the obvious next step would be to give Flipboard a go, if you haven’t already. If you want to do this, you might want to read about How to Switch from Zite to Flipboard.

I tried Flipboard a couple of years ago and it didn’t really take with me, so I really hope that they manage to use the best parts of the Zite service well or I’m going to be left with something of a gap in my life in the area of recommended reading.