Thursday, May 22, 2014

The current state of TV

A couple of weeks ago I decided I needed to get up to speed with GoT, and set about watching series 1-3, so that I could catch up to the latest series as it played out live.

This was my experience.
  1. Sign up to NowTV, Sky's pay-as-you-go monthly streaming service, in order to access the old series.
  2. Watch half of series 1 using Chromecast from Android app - it's a great experience.
  3. Enjoy it so much I fork out for a NowTV box, so I don't even need to cast. Brilliant. This is future.
  4. Sky's licensing window with HBO expires - all episodes disappear from Sky. I am bereft.
  5. Cannot find old GoT on any other streaming service in the UK.
  6. Purchase US VPN to access HBO-Go.
  7. Discover that in the US, you have to sign up via your "TV Provider" - as I live in the UK, my "TV provider" is a metal stick on my roof. It doesn't support oauth.
  8. Send an SOS out on Twitter for solutions. Nothing comes back.
  9. Give in, and download series 2 via BitTorrent. I've already spent about £40 just to watch 6 episodes of first series, so figure I'm owed something.
  10. Wait about four days for torrent to download.
  11. Watch downloads using Videostream chrome app and Chromecast - it too is brilliant, but feel guilty about my crime.
  12. Guilt takes control, eventually finding series 3 available on Blinkbox, from Tesco. This is ironic, given that I spent two years building Tesco's first streaming service, before it was folded into Blinkbox.
  13. Buy series 3.
  14. Find out that BlinkBox's Android app doesn't support casting, so have to watch from laptop. There's a terrible lag casting from a Silverlight app running in chrome, so I switch to mirroring via AppleTV. The Silverlight app threatens to melt my laptop.
So far, I've watched (most of) three series of GoT, and along the way:
  • I've subscribed to two new services (NowTV and VPN).
  • I've bought one new set-top box (NowTV).
  • I've used a further two set-top boxes (Chromecast and AppleTV).
  • I've used two separate device (laptop and tablet)
  • I've downloaded two new apps (NowTV, Blinkbox, Videocast)
  • I've used two further apps (TunnelBlick, uTorrent)
  • I've broken various Terms of Service agreements
  • I may even have broken the law?
This the current state of TV.

It's a clusterf*ck.

**UPDATE**

Despite my best efforts, I wasn't fast enough - so although I have now finished series three, and series four is available via my NowTV subscription - the first three episodes have already expired. And because the series is still in progress, it's not available for streaming anywhere else.

Tuesday, December 17, 2013

How did we end up with this?

I, along with several million other people, got caught up in both the LinkedIn and Adobe account hacks, and I've had "stop using 'password' as my password for every online account" in my to-do list for at least a year.

A couple of weeks ago I decided to do something about it. I activated two-factor auth on every account that supported it, clicked the 'generate temporary password for devices' link on Twitter, and then hit the nuclear button by downloading LastPass and beginning to upgrade my passwords (I don't really use 'password' as my password - I also use 'P@ssword', 'Passw0rd!' and 'pa55w0rd' - I'm always thinking, see).

It was a PITA changing old passwords, but I just about got around to changing the important things (accounts attached to credit cards, and core identity providers) when my new phone arrived (Moto-G, which is fantastic, btw, although I am comparing it to a 2.5 yr old HTC).

What a clusterf*k. Activating two-factor auth and various device checks means that I am constantly being asked to re-enter passwords, only this time I have no idea what those passwords are, as I've changed them from the ones I know to the brilliantly uncrackable long, complex, passwords generated by LastPass.

On the plus side I've discovered that Google Keep is a very efficient way of copying complicated passwords in plain text between devices. On the downside, lots of apps don't support 'Paste' on Android, so I have to write them down instead (hence a pocketful of Post-It notes). I think I'm now technically less secure, as I'm far more prone to social engineering hacks that I was before.

I really hope that those who hold our secrets (no, not the NSA) are working on solutions to the secure login conundrum, because no one outside of the tech industries would use a computer if it was as complicated as the situation I find myself in.

Friday, December 13, 2013

Marketing reality distortion - a case study.

It's a slow day at work (warming up for the Christmas party), so I thought I'd blog about Accenture instead. Actually, this is a rant about marketing departments, not Accenture per se, they just happen to have riled me this morning.

A friend of mine works at Accenture, and this morning retweeted an image from their current recruitment marketing campaign. It's a great pic (see below), and contains a very clear message. They're looking for Big Thinkers, the ambitious, those who aspire to a Better Future. The message itself is literally spelled out, "Future > Present", and visually it taps into something many men (possibly a tad too gender specific, but maybe I'm being over-sensitive) will immediately understand: I want to be an astronaut. That's my dream.



It's a seductive message - and for anyone remotely ambitious just starting out (it's aimed at people just starting their working lives) it makes Accenture look like somewhere you'd like to work. Maybe not quite as cool as Google (who do genuinely have a "Moonshot" division), but a good option nonetheless. So you click through.

And that's when the wheels come off. Apparently the recruitment budget was spent, in its entirety, on the campaign. Having nothing left they got the guy in Accounts' brother to knock up the campaign microsite. He's jazzed it up with a carousel of incredibly happy people in grey suits (and ties - really, who wears a tie these days) - but I'm pretty sure none of them are Felix Baumgartner or Commander Hadfield.



Pretty much everything on this page (font, use of white space, formatting, images) is bad. I imagine it's just the default Sharepoint "Add new microsite" template, but that's not really the point. This page, which is where things get real, also has a very clear message: we're accountants, or possibly management consultants, but either way you're going to spending a lot of your time in front of a spreadsheet, and it's not memorising launch code sequences. In addition, we really don't give a sh*t about design, the process of creation, attention to detail, refinement or finesse. We're robots. With spreadsheets. And sometimes we hand out awards to other spreadsheet-toting robots.

In reality I've known lots of people who've passed through the Accenture machine, and they're not all number-crunching automatons - they're generally intelligent, hard-working, interesting people, with a lot to say, on a lot of subjects.

This is a masterclass of old-school marketing-reality distortion, and rather than making Accenture an attractive place to work, it makes them look desperate ("we couldn't think what to do, so we just made it up"). There are lots of good reasons to work at Accenture - wanting to be an astronaut isn't one of them.

Wednesday, August 14, 2013

Spies stole my laptop. Possibly.

I've bought a tin-foil hat.

I was burgled last month. Nothing dramatic, they broke a window,  stole a laptop. They didn't make any mess (suspiciously neat as it happens, I'd almost claim they vacuumed the place), and it was more of an inconvenience than anything else.

The police came round and dusted for fingerprints - nothing - no blood where they'd crashed the window, no greasy fingerprints on anything. They may have worn gloves (professional thieves, in Stockwell?)

And then I realised that a couple of other things were missing -  principally two other (old, not used) laptops (resale value < £50), and rather bizarrely, and most annoyingly, my v. expensive Logitech wireless keyboard.

At about the same time the Snowden story was unfolding, and I was tweeting and posting occasionally on the subject.

Oh, and I live less than a mile from MI6, the UK's foreign intelligence service (007).

So here's my tin foil hat theory - spies stole my laptops, and more than that, they stole my keyboard as they have backdoor key-logging software installed on popular wireless keyboards. Don't say I didn't warn you.

Over and out - heading off-grid for a while...

Wednesday, April 03, 2013

Status codes are not for humans.

Last week I finally managed to provoke our tech lead into using the 'F-word' in conversation. The trigger for this outburst was none other than HTTP status codes, and my desire to invent a new one. This was clearly beyond the pale.

I have since retreated from my original stance (a custom status code), but have committed a change to our dev branch to use an existing, but rarely seen, status code - 422 "Unprocessable Entity" (more on the situation in which I return this later).

This code is an extension to the base set of codes, proposed as part of the WebDAV extensions to HTTP 1.1 in June 2007 (citation):
The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.
This status code has seen increasing adoption within the HATEOS / REST community, however it's not without its detractors - as the comment thread with this post illustrates.

My particular crime is not just to use this code, but to use it in a classic vanilla HTML scenario - in the event of form POST validation errors.

It has always seemed to me a peculiar anomaly that whilst the PRG pattern and the use of 3xx status codes (albeit typically the 'wrong' code, 302, instead of the code specifically designed for this situation - 303) has become ubiquitous, it is perfectly acceptable to return a 200 OK status when the form POST is rejected (because some validation has failed).

The common argument against this is that form validation is an application specific issue, and therefore not the responsibility of the protocol used to the transmit the data, but I think that's a thin argument at best. Additional, accepted, status codes exist for "Payment Required (402)", and "Forbidden (403)", both of which relate to the underlying application, and not HTTP per se.

The 2xx code block specifically states:
This class of status code indicates that the client's request was successfully received, understood, and accepted.
But what if the request was successfully received, understood, and not accepted. Surely this is a valid use case - in fact I would suggest that it's one of the canonical HTML/HTTP use cases. And whilst the specific rules around acceptance are application specific, the generic concept of 'Request Declined' is ubiquitous - in 15 years of web development I've never seen an application that does not support this scenario. And the rules around this are no more application-specific than the 'Payment Required' example.

It is (IMO) unfortunate that people who are looking to support this as a valid 4xx exception are having to shoe-horn this into the 422 WebDAV extension, but my suggestion for a new 421 code (421 on the basis that it's between 422, which is the closest formal code, and 420, which Twitter appropriated and therefore also made-up) seems to have really upset people, so I'm happy to stand down on that. (And in fact, re-reading 422 now, it is basically what I'm looking for - just would rather it wasn't within the context of a WebDAV submission. My ideal outcome would be to rewrite the description of 422 in a more generic sense, and have it adopted as the de facto response in the event of a request validation error.)

All of which brings me to the real purpose of this post. In researching 422, I have come across endless discussion around the rights and wrongs of HTTP code assignments, but not one post or comment on what, to me, is the main reason for adopting status codes at all (beyond the functioning of the web, of course) - which is to facilitate testing and analytics, i.e. making it easier for computers to understand what is going on without having to read HTML.

Status codes are transparent and invisible to end users, but stick out like a sore thumb in logs, which makes them invaluable for analysis. A log file that includes nothing but 200s or the occasional 404 provides very little insight in to what is really going on.

Similarly, having to interrogate the HTML body of a response to understand whether the HTTP request was "received, understood and accepted" or not is painful at best, and often misleading.
HTTP status codes aren't there for humans, they are there for non-humans, whether that be the routing infrastructure (understanding what to cache), or HTTP clients (understanding what to do next).

And remember, browsers are not the only clients.

(PS - to everyone who disagrees with me, bear in mind that I do understand your objections, I just don't agree with them. I'm trying to make the web more useful, not studying for my Masters.)

[UPDATE]

I found this in the original HTTP 1.1 specification:

HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response MUST NOT be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 status code. In such cases, user agents SHOULD present to the user the entity returned with the response, since that entity is likely to include human- readable information which will explain the unusual status.
You can make up your own mind from this (I have).