Softwire Blog

Currying in Node.js

29 April 2015, by

Having been doing a lot of functional programming recently, I discovered myself wanting to curry functions while doing some work in Node.js recently, but the question arose as to how?
Currying a function is providing some of its parameters now, and the rest later and is very common in Functional languages:


def add(x:Int)(y:Int) = x + y
def add2 = add(2)
add2(10)     // 12


let add x y = x + y
let add2 x = add 2
add2 10      // 12

But how can you do this in javascript when you have to provide all of the arguments to your function?
Well here are a few options:

  1. Get the extra variables in scope (not really the point, but will work in some situations).
    val y = 2;
    function add2(x) { return  x + y; }
    add2(10);    // 12
  2. Return a function from your function.
    function add(x) { return function(y) { return  x + y; }; }
    var add2 = add(2);
    add2(10);    // 12
  3. Use bind to perform partial application instead.
    var add = function(a, b) { return a + b; }
    var add2 = add.bind(null, 2);
    add2(10);    // 12
  4. Extend Function.protocol.
    Function.prototype.curry = function(){
      var slice = [].slice,
          args = slice.apply(arguments),
          that = this;
      return function() {
        return that.apply(null, args.concat(slice.apply(arguments)));
    var add2 = add.curry(2);
    add2(10);    // 12
  5. Use the curry library.
    var curry = require('curry');
    var add = curry(function(a, b){ return a + b });
    var add2 = add(2);
    add2(10);    // 12

The curry library is doing something very close to 2 behind the scenes. It will however also let you do partial application as well if you want.

var sum = function(){
  var nums = [];
  return nums.reduce(function(a, b){ return a + b });
var sum2 =, sum);
sum2(2)(10);      // 12

Millennials in IT – Softwire’s first event of the year!

27 April 2015, by

Last week Softwire held their first external event of the year at Shoreditch House, focusing on how to attract and retain the best developers. During our 15 years as a company, Softwire have always placed a great emphasis on attracting the most talented developers to the company and we’ve learnt a lot about how to do this. So we decided that it was time to share some of our knowledge with other tech leaders in the industry.

Zoe our talented MD joined our expert panel with Bill Thompson from BBC Radio’s Click and Daria Taylor co-founder of Talented Heads, to offer some input and advice on how to get the attention of the best developers from the Millennial generation. Softwire are fortunate enough to enjoy a 95% year on year staff retention rate so Zoe was well equipped to offer advice on keeping developers engaged. Daria, who heads up Talented Heads offered input on how to attract newer graduate developers in an increasingly competitive recruitment market, whilst Bill Thompson spoke about what the BBC are currently doing around encouraging younger people to take an interest in careers in technology.

The first of four software development related events this year, the afternoon went well with IT Managers from a great variety of sectors offering their input on the topic. The next event will focus on Project Management and how to create efficient teams of those developers everyone works so hard to attract in the first place. 

Explaining a security vulnerability: the IIS Range Header attack (CVE-2015-1635)

21 April 2015, by

Last week Microsoft have announced a patch (MS15-034) fixing a major security vulnerability in IIS, Microsoft’s Windows-based web server. This is a big problem for almost anybody running IIS, allowing any user on the internet to crash their servers with extremely little effort, or potentially take complete control of them.

If you’re running an unprotected IIS you should go and either update right now, or disable IIS Kernel Caching (note that this has some serious performance penalties).

Once you’re not, read on and we’ll take a look into how this works and how it’s happened.

The Attack

Information at this stage is limited, and a full exploit for the remote code execution attack isn’t yet available online, but exploits that immediately crash the whole server are. For now we’ll examine the server-crashing exploit, but it’s likely the full exploit is using very similar principles. Example exploit code is very simple and widely available, and is shown below:

wget --header="Range: bytes=18-18446744073709551615" http://server-address/a-file.png

This attack fundamentally works by sending a request containing a ‘range’ header for a large range of a file on the server. Range headers are used by browsers to request only part of a piece of content, not the whole. This is often used when loading sections of a video when streaming video online for example.

The key point is that the end of the range given is the exact maximum value that will fit into a unsigned long (64-bit) value: 18446744073709551615 (2 to the power of 64, minus 1). The first value of the range appears to be only somewhat relevant: if it’s 0 an unpatched server will return a ‘Requested Range Not Satisfiable’ response, rather than outright crashing. Any value greater than 0 but less than the size of the file however will crash a vulnerable server completely.

Over the past few days software engineers have been examining the changes within Microsoft’s patch, to see why exactly this issue occurs. Definitive answers are hard to come by, but it appears that when receiving a range header, memory is allocated to hold the output of the request, at the right size to hold the response for the browser, and during calculation of the size 1 is added to the upper end of the range. Unfortunately, as this is already the maximum value a long can have, it overflows: for an unsigned long 18446744073709551615 + 1 = 0. Until now Microsoft’s code was not checking for this (a big no-no), resulting in a wildly wrong value, which when used later crashes the process (unclear where, but likely to allocate memory). This is not good.

This is made worse still because this code is part of a windows subsystem called HTTP.sys. HTTP.sys is a Windows driver, running a part of the core system itself with unlimited privileges, which is responsible for interpreting HTTP requests and responses, included in the core of Windows for maximum performance.

When HTTP.sys crashes the whole computer comes with it, the machine blue-screens and is broken until you completely reboot it. Game over.

Further Reading

Mattias Genier has an initial write up of the issue at

The Beyond Trust team have released details of their investigation into the patch itself at

Risk Log Zero: How to keep your risk log empty and your mind free of worry

17 April 2015, by

Today I’m going to share with you my Risk Log Zero strategy – an attempt to do for my risk log (and risk management) what Inbox Zero did for my inbox (and self-management)

What are risk logs really for?

Risk management can be defined as the stuff that PMs never quite find the time to do. You’re haring around doing the things that obviously need doing on your project, and it’s easy to ignore the nagging voice in the back of your head that says “what if this happens?” Risk logs are intended to make this voice harder to ignore. A good risk log will ask you every week “what are you worried about?”, and will remind you about the risk at the point when you can do something about it. I claim that your risk log does neither of these things.

A bad risk log

Let’s have a look at a risk log I wrote as a young and naive Project Manager, and pick holes in it:
An old risk log

Not a bad start – day 1 and I’ve identified 5 major risks on the project. However, the next Monday, I got a calendar pop-up telling me to update the risk log. So I looked at this table, and checked for the following:

  • Can I close any of the risks? No
  • Have any of these vague transition indicators definitely occurred (definitely enough that I can’t justify leaving it until next week)? No
  • Do I need to perform any of the mitigation actions? …No

This isn’t a very useful exercise. There are some major issues:

  • It’s easy not to take any actions, and just go back to the comfort of my more tangible (and very long) to-do list.
  • If I’m worrying about all these, then I’m not worrying about them enough (or alternatively, I’m living in a perpetual state of worry).
  • Most dangerously, because this exercise gives the illusion of risk management, and because I can see lots of pretty risks in my table, I don’t feel any imperative to think up any new, more relevant risks.

Risk Log Zero – the blank page

The principle behind Inbox Zero is that if your inbox is nearly empty, it means you’ve done something sensible with nearly all your emails, and you can now attend properly to the remaining ones. Applied to risk logs, my strategy has more emphasis on addressing risks immediately.

An empty risk log is a great reminder to ask the question “what’s worrying me about the project right now?” – much more incentive to fill it up, compared to the incentive to leave a full risk log as it is.
A blank risk log

Now I’m forced to ask myself what I’ve been worrying about this week:
A risk

Actions and checks

Here’s the important bit – the part that enables you to stare at a blank page again next week and identify the newest risks. We are essentially going to ask ourselves this questions for each risk: “what do I need to do right now so that I can stop worrying about this?”.

It turns out that the things you need to do will generally fall into three categories:

  • Something you can do right now
  • Something you can ask someone else to do
  • Something you should check on a certain date in the future.

The middle category can be converted into the other two (right now: ask someone to do something. Later: check they’ve done it.) So we just need to add spaces for Actions and Checks to our risk log:
Risks and actions

Emptying your risk log again

All I need to do now, to get back to an empty risk log, is to:

  • Add this risk log snapshot to my status email, so the customer / my boss knows what the major risks are.
  • Add the actions to my to-do list (or delegate them to others).
  • Delete the risk!

When I come back next Monday, I will need to very quickly check if any of the dates in the second table have passed, and answer the question if so. And then I can get on with staring at the blank first table and deciding what to worry about next.

What this doesn’t help you do

This is all very well, but remember it doesn’t help you do any of the following:

  • Knowing what you should be worried about. But it does remind you to ask the question! And you should get into the habit of asking everyone else too. Your team, your boss, your customer – everyone.
  • Knowing how to mitigate the risk. But I’ve found that if you publicise your risk log (again, to the team, your boss, your customer) then half the time they’ll sort it out for you anyway.
  • Actually carrying out the actions. Although it might shame you into doing so – especially if you make it public!

Please do let me know how you get on with Risk Log Zero.

We’re in the top 20! – Sunday Times Best Small Companies to work for

10 April 2015, by

2015 Best Companies LogoFebruary was a good month for Softwire. Not only did we celebrate our 15th birthday, but we also found out – for the fifth time running – that we’d been named one of the Sunday Times’ top 100 small companies to work for! This year Softwire jumped up three places to claim to 20th spot on the list, which we’re very proud of.

Softwire’s three founders set out in 2000 to build a company where developers would be happy to come to work, with a learning culture which allowed employees to grow and thrive. Fifteen years we still strive to have that ethos shine through in everything the company does.

Some of our developers have been with us from the very beginning and some are just getting started! So we asked everyone what the best thing is about working at Softwire:

Matthew (At Softwire since 2001)

‘Every project I’ve delivered. It’s a great feeling successfully delivering software that solves real problems for real people’

Antonia (Here since 2013)

‘I have tried more new things since starting work here a year ago than I did in the previous decade!’

Clinton (Joined in 2014)

‘Softwire cares about employee development, so you keep growing rather than stagnating.’

Dan (One of our Founders)

‘Multiplayer video games every lunchtime – with shouting.’

Zoe (Our managing Director)

‘Learning how to set my own career plan and following it to become MD.’

Java: auto-generated POJO builders

6 April 2015, by

Any of you that have worked for a while with Java have undoubtedly come across code similar to this, usually in unit tests:

public SomeEntity createEntityWithFoo(String foo) {
    SomeEntity entity = new Entity();
    return entity;

public SomeEntity createEntityWithFooAndBar(String foo, String bar) {
    SomeEntity entity = new Entity();
    return entity;


How would the internet work on Mars?

2 April 2015, by

Maslov's Hierarchy of Needs - updatedThe news is full of big hopes that Mars will be colonised soon, with reality TV show MarsOne suggesting that we could have people there in under 10 years.

Scientists are grappling with the challenges of providing air, water (for a swimming pool, obviously), food and shelter. Here at Softwire we’re concerned with a more fundamental issue. How will we get access to the internet?

The communication time delay is reported by NASA to be 20 minutes. This might not be too much of a problem for some internet services, but for watching YouTube and browsing BBC News? Worse than dial-up.
The most sensible way to build a functioning internet is to build a data centre on Mars. This data centre would hold a copy of all websites and all regular website traffic from Mars would go between the Martian and the new data centre.

Anything that needed to be communicated to Earth (for example if you placed an order with Amazon, they’d need to check stock back on Earth) would be done in an off-line process after you’ve finished your action e.g. after you’ve placed your order it will remain as “unconfirmed” until the website hears back from Earth. Delivery times may also be slightly extended.

Luckily NASA is one step ahead of us. They have already designed an Interplanatery Internet. This is an internet structure specifically designed to cope with the long delays and fragile connections that we can expect in space. NASA has tested this new internet by sending “space pictures” to a spaceship 20 million miles from Earth.

So if you’re one of the lucky contestants who win a place out on a one way trip you might not see your family again, but you can see their holiday snaps.