Is your CPU time there to be stolen?

Or can it be bartered? If you were given the choice between giving up cpu time, giving up privacy, or giving up money, to reimburse a developer for their time, which would you choose?

If you don’t feed us, do we not starve?

RT @ppinternational: uTorrent client is stealing your CPU cycles to mine #bitcoin

The Monty Hall problem

One of these things is not like the other

There’s a bit of a meme going about trying to explain The Monty Hall problem. It’s an interesting statistical problem because the result appears at first to be counterintuitive.

The basic formulation comes from a game show, where the final round consisted of three boxes, and behind 1 is a car, and the other 2 are goats.

If you pick the car, you keep it.

The complication in the setup comes from the host, Monty Hall, who, after you’ve picked a box, opens another box to reveal a goat, then gives you the opportunity to stick or swap. The question is, in a statistical calculation, should you switch?

The naive answer would suggest that as there’s only 2 boxes left, there’s a 50/50 chance that you’ve chosen the car. But that formulation misses the important facts that you choose a box first, and you are always shown a goat. There’s a lot of descriptions that show how the possibilities collapse with numerous branches to show that in 2/3rds of cases, it pays to switch.

There is a simpler way of thinking about the solution. In 2/3rds of cases, you choose a goat. Since Monty had to reveal a goat, changing your mind guarantees you a car in those cases. In the other 1/3rd, you picked the car in the first case.

Sometimes statistics is unintuitive because you have the wrong model, and users can’t see the wood for the decision trees. There are good reasons for some faulty models to exist, but these should be corrected and challenged.

Can’t patch, won’t patch

As a software developer, I take a keen interest in the platforms I am developing on, as that’s often the one thing I have least control over, given that the customer will ultimately be installing in their environment in most cases.

As a Windows developer with an Android phone, this story particularly interests me from a security perspective. I don’t want to have to target a moving platform, but equally I don’t want my software compromised by the security of the system it runs on, so having developed and supported projects under WIndows (mainly web via IIS, and IE on intranet) and Android, the recent spat between Microsoft and Google over security exploits and Google’s “Project Zero” has been of big interest to me.

Patching my thumb with gauze
Patching my thumb

The Microsoft bugs mentioned in the posts show how responsive a company needs to be to stay on top of security. For a product as big as Windows, 90 days is not much time to implement and test a fix. Microsoft obviously want to make their job as easy as they can to get those fixes out quickly, so they officially only support patches for users running up to date versions, including service packs. Their support for Windows expires if you haven’t updated for 2 years, and for most of their consumer software if you haven’t updated for 1 year. (note that Windows 8 is supported well past 2018, but only if you’ve been installing the free service packs).

Google’s problem with Android is that it has been open for OEMs to adapt for their platforms, at which point it is no longer Google’s Android. Whilst Google has worked to minimise the things that OEMs can control, including moving the WebView component at the heart of the flaw into Google Play in Android 4.4 and higher, the platform is still reliant on OEM support as much as, if not more than, Google. That is pretty much Google’s position, that the handset manufacturers need to update to a more recent platform, or submit a patch for Google to distribute to all the OEMs.

So if you’re stuck on Jelly Bean, you now have to either rely on the support commitment the manufacturer has to a handset that is no longer making them money, or use the open nature of the platform to install an alternative Android, not provided by the OEM.There are workarounds using other browsers, but they rely on users understanding what webview is (and potentially disabling WebView in all the apps, like Facebook, that use it).

Google seems to care deeply about server-side security and was seemed genuinely angry about the NSA breach between their data centres, but their record on the client side isn’t great. Android permissions, and Chrome passwords are two key examples. Microsoft’s “Scroogled” campaign attempted to cast to same doubt on Google’s cloud security, and was partially successful, although Microsoft’s successful certification of Azure to ISO-27018 is a far better card to play in this battle.

Google’s Project Zero is definitely a good way to set a rising tide of security, and is an essential part of the response we need to the Heartbleed and ShellShock exploits from last year, and the ongoing revelations about back-doors that spy agencies around the world have discovered. Google is not immune from the rising tide, and has fallen foul itself in meeting good practice. Microsoft seems to be their biggest critic in this area, but it’s been firing blanks, whilst open source vendors have been busy patching and moving on.

As a user, I know hackers are working to find exploits, so any exploitable discover has to be disclosed, to those who can fix it first, and to the rest of the community in a reasonable time, so that users can protect themselves. The problem with disclosure only comes where there is no possible means for the average user to defend themselves, which is precisely the problem with the above exploits. Usually, “Open Source” is given as the answer to empower users, but in this case, open source isn’t enough to get Android fixed. That’s still no reason to hide the exploit however, as users need to know if they need to protect themselves, especially if the solution is to avoid certain apps or websites.

Do you think Project Zero has demonstrated responsible disclosure?

Keep it Simple, John Sonmez

I’m trying to build a better blogging habit, after following John Sonmez’s blogging email course. I started following him, and his Simple Programmer blog, after I saw a review of his Soft Skills book on Christos Matskas’ blog and thought it was something I needed to know more about.

I’ve been presenting and blogging for a while, since I realised that my technical skills were a necessary but not a sufficient condition for a fulfilling career, because the soft skills open the doors to the greater challenges of customer and team relationships, and greater responsibility. Communication and explanation are becoming more important right from the start of a developer’s career however, as more companies move towards adopting portions of the agile manifesto and encourage greater interaction between the technical and the business owners, as well as expecting a much higher degree of collaboration within teams,

For those of you just starting out, or those looking to jump things up a gear, the course lays out some great motivation and practical steps to get you set up, and start building up your soft skills by communicating.

Blogging may not be for everyone, but I don’t have much faith in a software engineer who can’t clearly communicate their ideas. So if you don’t currently blog, vlog, present or attend Guided Conversations, today is a great day to start.

If you’ve just started, please feel free to include a link to your blog, YouTube channel, or other communication forum below. Part of the soft skills are about collaboration and sharing.


I’ve been thinking about productivity a lot recently, s you may have seen if you’ve been following me on Twitter.

It strikes me though that the most important thing that generalises a lot of the tips is this: Avoid multitasking.

Humans are notoriously bad at multitasking (and not just men, for those women sniggering smugly at the back), so a lot of the tips are about focussing on one thing and ignoring everything else. Things like working through a to do list, setting aside a specific time to deal with emails and setting one main goal, are all about the same thing.

One of the reasons multi-tasking is unproductive is there is a time cost associated with switching tasks. Think about your email. To check it, you open up (or switch to) your email window, you may need to log in, you then have to orient yourself to the last e-mail (which is easier if you have an empty inbox when you end your email tasks), and then get into the mind set of what you do with each email, remember what folders/tags you’re using, and so on. The more you do a task, the shorter the switching time can get, but it is always there, and if you’re multitasking, you’re actually wasting a lot of time during the switching.

Of course, sometimes switching is inevitable, networks go down, sometimes you have to wait for other people, so you need other tasks in the pipeline so you have something to do when you can’t work on your main task, but the longer you can concentrate on one task, the more you’ll get done on that task. And if you set yourself a deadline to complete it, that’ll help your concentration too because it will stop you thinking “Oh, I’ve got a week to finish this, I can check my email now” and start you thinking “I’ve got to get this done by 3 or my plan’s down the drain, so I’ll get this done now and then check my email”.

Well, it’s certainly helped me :-)

Thoughts on Node.js

Focus on the flow
Focus on the flow

In my post about developing in the cloud, I started promising a few nuggets about the project I was working on, and following my diversion onto talks and security, I’m ready to start discussing it again. The project itself is fairly straightforward. It was an excuse for me to try a realistic project in Node.js using cloud development tools, to see what was possible, and to decide if I wanted to use Node.js for anything more substantial.

Partly, I wanted to immerse myself in a completely callback-driven, “non-blocking” model, so that I can see how it affected the way I thought about the software I was writing, and also to see if I could see the benefits. I’ll expand on some of these thoughts as I talk more about it, but I wanted to start with my initial impressions.

What Node.JS does well

Firstly, from looking at a test example based on graphing data from this great read about green energy, it was clear to me that the promises of Node.js lie very much in the I/O performance side, rather than anything else. If you’re trying to do anything more complex than throwing as many bytes at the response buffer as possible, Node.js is probably the wrong tool. It’s not built for complex business logic. It is good if your server is a thin layer between a JS front-end and something specialised on the backend (or a series of specialist pipes on the backend – the web services support is top notch, as you’d expect from the language that gave us AJAX and JSON).

One of the reasons I started to enjoy using Node.js was the ability to run the same code on client and server, which meant that I could write tests for my JavaScript logic that would run as unit tests in the server context, and then ship the exact same JavaScript to the client, knowing that the internal logic was correct, even if the performance wouldn’t be. This was greatly helped by the fact that I could use Require.JS to bridge the gap between the client and Node’s extensive NPM package repository, which isn’t as easy to search as the apt-get and NuGet repositories I’m more used to, but is fairly comprehensive, although it does suffer from the apt-get problem of having a lot of packages for doing the same thing, and it can be hard to choose which one to use. There are definitely popular options that bubble to the surface, but I get the feeling I’d need to try a few of them to really start to feel which was the right one to use, especially as a few of them have APIs that feel quite alien to the core libraries, and feel like unthinking ports from other languages, or at least non-callback philosophies.

In the end, I got a proof of concept up over a weekend, which is about as long as I’d normally spend on The Mandelbrot Set, which is a nice quick result, and I got multiple users up on the site, which is more of a testament to Cloud 9 as it is to Node, but the resultant code had fewer features and messier code than the alternatives I’d written in other languages. It certainly felt more as if I was fighting against the flow than in previous incarnations, despite the refactoring tools and examples I had available, and it was a lot harder to keep the program flow in my head, since I had to ensure I understood the context that the callback was operating in : which paths could lead to the current code being executed and what I could rely on being set. I tried to trim the code back as much as possible, but I was still debugging a lot more than I was used to in other incarnations, despite more testing.

What Node.JS does to make you grind your teeth

At this point, I’ve written two proofs-of-concept in Node.JS, and whilst I think the 2 projects I tried weren’t the optimal projects for Node.JS, I’m getting a feel for what is can and cannot do. I can see places where I would use it if I was doing streaming or similar low-latency, high-throughput tasks that were just about routing bits, and I have watched it updating several clients at once, but it’s very easy to write blocking code that will slow the server, and has an instant impact on all clients, making them all hang until the blocking operation is completed. That type of error is not unique to Node.JS, but I found the chain of callbacks increasingly more difficult to reason about, making that type of error more likely. It feels like writing GOTOs.

At this point, I can’t see myself using Node.JS for anything other than a very thin layer to some business logic, and at that point, it seems odd to use a thin layer of web services just to call other services in another language. That’s what I’d do to start migrating out a legacy app, but I wouldn’t start a design that way. If I wanted to build a web service backend, there’s no benefit in Node.JS that I couldn’t get in WebAPI. However, I’m wondering whether my next project should be to re-write the backend in Go, to see if that’s any easier.


Node.JS is fun to play with as a proof of concept of callback-driven code, but I’ve seen the basic idea of a stripped back, high performance web server delivered far more elegantly in Erlang, Go, and other places. Node.JS throws out threads, and doesn’t offer enough in return to justify the switch for me. It’s fast, but not the fastest, and my productivity is definitely lower in Node.JS than it was in my first program in C#, or Java, or Python, or even my first work with client-side JavaScript. It’s an interesting experiment but I’ve got better things to do with my time than reason about which callback failed to trigger. For the right project, I’d give it another run, but the right projects for Node.JS are very specialised.

Rough Copy

media analysis / with added swearing

Simple Programmer

Making The Complex Simple

How To Tutorials

PHP, ASP, .Net, Linux, SEO


My eBooks are available at Amazon Worldwide

James Radcliffe, Musician. Music, Blog, Pictures, Live, News...

The Code Club Blog

Adventures in Teaching Kids How to Code

The Inner Donkey Sanctuary

Taking care of my inner donkey since 1977

Stack trace ramblings

Just another weblog

The DIEM Project

Dynamic Images and Eye Movements

Voidspace - Cyberpunk, Spirituality, & Python

Just another weblog

the HabitForge blog

Simple Accountability. Positive Change.

James Wiseman

Mainly programming, with a bit of science thrown in


on making software

Don Charisma

because anything is possible with Charisma

Kendall F. Person, thepublicblogger

original performance art with an imagination to change the world


Discover a new song every day

Scottish Games Network

The home of the Scottish Games Network

UK Constitutional Law Association

affiliated to the International Association of Constitutional Law


Get every new post delivered to your Inbox.

Join 1,547 other followers

%d bloggers like this: