Softwire Blog
Code Club at Tufnell Park Primary School
25 November 2015, by Tom Bell
At Softwire, we’re firm believers in the benefits of using our technical expertise to make a positive impact on society. As part of that effort, we run a weekly after-school coding club at nearby Tufnell Park Primary School, teaching children aged 9-11 the basic concepts of programming (and having lots of fun along the way!). The prospect of starting up a club was a bit daunting at first, but luckily the whole process is made much easier thanks to Code Club, a nationwide organisation that aims to facilitate the process by putting volunteers in contact with local schools and providing a wealth of teaching materials. Sharing the task of organising and running the club between four of us has also made the time commitment much easier to manage and we’ve found the whole experience to be really rewarding.
Code Club have some excellent resources available, including step-by-step worksheets for projects that suit a wide range of experience levels. For children joining the club for the first time, Scratch has proved to be an excellent tool for teaching basic programming concepts, it conveys these concepts in a fun and visually appealing way. Keeping the children engaged in what they’re doing is crucial, so projects that focus on creating games and animations have generally proven to be the biggest hits.
For those children that outgrew what Scratch has to offer, last year we began teaching HTML and CSS, but this year we’re planning to introduce the more advanced groups to JavaScript instead. This feels like a more natural progression from the visual programming concepts used by Scratch, and should offer the prospect of creating richer and more interactive web pages. While Code Club doesn’t currently provide projects for JavaScript, we’re planning to try out Trinket – an online HTML and JavaScript editor that provides simple code-completion and syntax highlighting – instead, and we’re hoping this will make the transition into text-based coding a much more positive experience.
I’m always amazed by how quickly the children grasp the basic concepts (what is an if statement, a for-loop, etc.) so we also aim to encourage the collaborative and problem-solving aspects of programming, skills that we value highly at Softwire, as well. We’ve found that an excellent way to reinforce those concepts is to go beyond the original scope of the project and ask the children to invent extra features they’d like to add to their game. We then chat with them about what code they might need to add to make it work, then let them explore the ideas themselves. This really helps to fire their imagination and they definitely take more personal pride in the result. We’re also fortunate that Tufnell Park school has a blog page where we’ve been able to highlight some of the great projects that the children have created, and this public recognition really helps to encourage them and reward their hard work.
Overall, we’ve really enjoyed the Code Club experience. We’re constantly struck by how enthusiastic the children are about coding and how eager they are to explore new ideas, once they realise that coding isn’t some mysterious and difficult art form, but really a form of puzzle-solving. It’s especially great to see them take the skills they’ve learnt and use them to create their own games, since programming is as much a creative endeavour as it is a technical one.
We have lots of ideas for new projects to explore this year, and with the success of last year’s effort, we now have enough new volunteers within Softwire that we’re planning to expand, with the hope of starting a new club in another nearby school after Christmas! We hope to give another update on our progress then.
Design & Deliver – Our Most Recent Event
20 November 2015, by Amy Wood
Last week we held our third tech workshop of the year at Shoreditch House. Our most recent area of exploration was the concept of design as part of the software delivery process. During the afternoon event our speakers and guests delved into what it means to design great software and looked at the risks of not designing software properly.
It was our busiest event yet and all of our speakers were well received. We were joined – as is now tradition- by the wonderful Bill Thompson as well as George and Liam from Maido and Jim and Luke from Sketch, both very talented design agencies. Sketch offered the audience a lot of practical design advice whilst Maido spoke about what makes a design good. Tim, Head of Design and UX at Softwire spoke about the cost of bad design and why it’s so important to get user experience just right from the start of every project.
We followed our talks with an open and engaging panel discussion, in which the audience were able to share their views and ask questions. In true Softwire style we welcomed our guests to join us for a drink and more conversation on the topic once the panel discussion was over. The room was a buzz with ideas about design and how we can improve software processes. We’re now looking forward to our next event in March 2016.
A Morale Update!
18 November 2015, by Amy Wood
The festive season is fast approaching, but it’s business as usual here at Softwire which means we’ve been up to plenty of fun shenanigans. We thought it was time for a bit of an update on our recent morale activities.
There really has been something for everyone in the last couple of months. From our regular pampering slots with massages and manicures through to the slightly more unorthodox bubble football trip we had down to Camden.
It’s not all fun and games though, sometimes we do fun and games for a good cause and we did just that at our charity RockStock evening where a number of bands played and sang classic hits in aid of Broken Rainbow and SCI Schisto Control. The performances went down a storm and we raised over £1843 for our charities, which was a great achievement.
We’ve also enjoyed some exciting culinary treats in the form of sausage salad and obatzda (apparently it’s a Bavarian cheese delicacy) at our somewhat tongue-twistingly named Sofctoberfest, where we also enjoyed a range of German beers and learnt a lot about German music. One could have been forgiven for believing you had stumbled through a portal to Munich. It isn’t just German beverages we’ve been exploring recently either. Our whisky club had yet another successful evening of whisky tasting, but this time we paired it with artisanal chocolate from around the world. A delicious and slightly intoxicating evening!
We celebrated Back to The Future day in style with an impeccably planned and timed screening of all three films in the brand new projector room. You can’t beat the classics shown in HD with surround sound and pizza! If all of that excitement wasn’t enough for you we also celebrated Halloween in style, with lots of great activities like haunted gingerbread house decorating and apple bobbing, and the bar was certainly raised by this year’s fancy dressers.
So all in all we’ve been having a great time and we still have plenty to look forward to before the year is out, like our charity pub quiz our Romanian festival and all of the usual festive activities. It’s not a bad time to be working at Softwire.
Quantum computers – What do they do, and how can I get one?
11 November 2015, by Chris Arnott
How do they work?
Hopefully you are already familiar with the fundamentals of a classical computer. You take a load of 1’s and 0’s and combine them using logic gates to do calculations, represent data, etc. Quantum computers take quantum states and use quantum gates to act upon the data. The result can then be read to generate a classical value.
The difference between a normal bit (1 or 0) and a quantum bit, is that the quantum bit is a superposition of both 1 and 0 at the same time. When reading the value of a quantum bit there’s a possibility of getting either 1 or 0, with certain probabilities. It follows from this that classical states are also quantum states, where the probabilities are 1 and 0 of each of the two states.
Why is this useful? Well, if you consider a simple function f(x), in a classical system, if you want to find out if f(0) = f(1), you will need to put both 1 and 0 into the function, measure the output and see if they are the same. However, in a quantum system, x can be a superposition of both 0 and 1. This means that the output of the gate can indicate whether the f(0) = f(1) from only one application of the function. The proof of this is Deutsh’s Algorithm, which is well worth reading about further if you would like to learn more about this.
What can they do?
The above is great, but what practical applications does this have? Well, it turns out there are certain classes of problems that quantum computers are able to solve more quickly than classical problems.
These include:
- Deutsh’s Algorithm (above)
- Period finding. Which is the ability to to find the period,
a, of a periodic function – one that satisfiesf(x) = f(x+a) - Shor’s Algorithm. Which is the ability to find factors of a non-prime integer.
Those of you who are up to date on your security algorithms will know that RSA encryption is based on how hard it is to find factors of large non-primes. This means that a quantum computer would be able to break many modern security systems. Fortunately, the dawn of any quantum age will result in new techniques of security, so all is not lost.
An interesting story of note is that recently security experts have been warning about “Capture now, decrypt later“. This is a method where hackers capture encrypted traffic today, and intend on decrypting it years later when decryption time will be much faster.
Where can I get one?
While technically available, you’ll need a great deal of money, as commercial quantum computers are expensive. In order to build a quantum computer, you need large entangled states (for your input), states that do not interact with the environment (to reduce noise in the computations) and the ability to manipulate and measure individual systems. Common methods for achieving this are:
- Ion traps, which use electron energy levels as the quantum bits. The downside of this method is that interaction between atoms is difficult to control and slow.
- Linear optics, which use polarization (or position) of photons. Unfortunately, it is difficult to generate single photons and detectors often struggle to measure such low levels of light (which can distort results).
- Atoms in an optical lattice, which uses sublevels of neutral atoms as quantum bits. The difficulty of this method is measuring individual quantum bits.
If you really do want to get a quantum computer without doing this yourself, D-Wave might be able to sell you one. The D-Wave Two has 512 qbits, but can only solve very specific quantum problems.
Post-quantum cryptography
When discussing the abilities of quantum computers, I mentioned that they break many common security practices. Fortunately all is not lost; quantum computers are designed to solve very specific problems, and many brilliant security researchers have come up with alternative methods of keeping our data safe that they can’t break.
The core idea is to make a problem that’s difficult to solve for both classical and quantum computers, for example:
- Lattice based cryptography uses a sequence of points in a high dimensional space. A message is then represented by the distance to one of those points. This is difficult to calculate unless you have the required secret key.
- McEliece encryption uses vectors to encrypt messages with intentional errors. The decryption algorithm then uses the inverse of parts of the public key to correct the errors inserted and calculate the message that was encrypted.
Has this piqued your interest in post-quantum encryption? If you’re interested to learn more, a good place to start would be investigating the options listed on wikipedia.
Typing Lodash in TypeScript, with Generic Union Types
5 November 2015, by Tim Perry
TypeScript is a powerful compile-to-JS language for the browser and node, designed to act as a superset of JavaScript, with optional static type annotations. We’ve written a detailed series of posts on it recently (start here), but in this post I want to talk about some specific open-source work we’ve done with it around Lodash, and some of the interesting details around how the types involved work.
TypeScript
For those of you who haven’t read the whole series: TypeScript gives you a language very similar to JavaScript, but including future features (due to the compile step) such as classes and arrow functions, and support for more structure, with it’s own module system, and optional type annotations. It allows you to annotate variables with these type annotations as you see fit, and then uses an extremely powerful type inference engine to automatically infer types for much of the rest of your code from there, automatically catching whole classes of bugs for you immediately. This is totally optional though, and any variables without types are implicitly assigned the ‘any’ type, opting them out of type checks entirely.
This all works really well, and TypeScript has quite a few fans over here at Softwire. It gets more difficult when you’re using code written outside your project though, as most of the JavaScript ecosystem is written in plain JavaScript, without type annotations. This takes away some of your new exciting benefits; every library object is treated as having ‘any’ type, so all method calls return ‘any’ type, and passing data through other libraries quickly untypes it.
Fortunately the open-source community stepped up and built DefinitelyTyped, a compilation of external type annotations for other existing libraries. These ‘type definitions’ can be dropped into projects alongside the real library code to let you write completely type-safe code, using non-TypeScript libraries.
This is great! Sadly, it’s not that simple in practice. These type definitions need to be maintained, and can sometimes be inaccurate and out of date.
In this article I want to take a look at a particular example of that, around Lodash’s _.flatten() function, and use this to look at some of the more exciting newer features in TypeScript’s type system, and how that can give us types to effectively describe fairly complex APIs with ease.
What’s _.flatten?
Let’s step back. Lodash is a great library that provides utility functions for all sorts of things that are useful in JavaScript, notably including array manipulation.
Flatten is one of these methods. Flattening an array unwraps any arrays that appear nested within it, and includes the values within those nested arrays instead. Flatten also takes an optional second boolean parameter, defining whether this processes should be recursive. An example:
_.flatten([1, 2, 3]); // returns [1, 2, 3] - does nothing
_.flatten([[1], [2, 3]]); // returns [1, 2, 3] - unwraps both inner arrays
_.flatten([[1], [2, 3], 4]); // returns [1, 2, 3, 4] - unwraps both inner arrays,
// and includes the existing non-list element
_.flatten([[1], [2, 3], [[4, 5]]]); // returns [1, 2, 3, [4, 5]] - unwraps all arrays,
// but only one level
_.flatten([[1], [2, 3], [[4, 5]]], true); // returns [1, 2, 3, 4, 5] - unwraps all arrays
// recursively
This is frequently very useful, especially in a collection pipeline, and is fairly easy to describe and understand. Sadly it’s not that easy to type, and the previous DefinitelyTyped type definitions didn’t provide static typing over these operations.
What’s wrong with the previous flatten type definitions?
Lots of things! The _.flatten definitions include some method overloads that don’t exist, have some unnecessary duplication, incorrect documentation, but most interestingly their return type isn’t based on their input, which takes away your strict typing. Specifically, the method I’m concerned with has a type definition like the below:
interface LoDashStatic {
flatten<T>(array: List<any>, isDeep?: boolean): List<T>;
}
This type says that the flatten method on the LoDashStatic interface (the interface that _ implements) takes a list of anything, and an optional boolean argument, and returns an array of T’s, where T is a generic parameter to flatten. Because T only appears in the output though, not the type of our ‘array’ parameter, this isn’t useful! We can pass a list of numbers, and tell TypeScript we’re expecting a list of strings back, and it won’t know any better.
We can definitely do better than that. Intuitively, you can think of the type of this method as being (for any X, e.g. string, number, or HTMLElement):
_.flatten(list of X): returns a list of X _.flatten(list of lists of X): returns a list of X _.flatten(list of both X and lists of X): returns a list of X _.flatten(list of lists of lists of X): returns a list of list of X (unwraps one level) _.flatten(list of lists of lists of X, true): returns a list of X (unwraps all levels)
(Ignoring the case where you pass false as the 2nd argument, just for the moment)
Turning this into a TypeScript type definition is a little more involved, but this gives us a reasonable idea of what’s going on here that we can start with.
How do we describe these types in TypeScript?
Let’s start with our core feature: unwrapping a nested list with _.flatten(list of lists of X). The type of this looks like:
flatten<T>(array: List<List<T>>): List<T>;
Here, we say that when I pass flatten a list that only contains lists, which contain elements of some common type T, then I’ll get back a list containing only type T elements. Thus if I call _.flatten([[1], [2, 3]]), TypeScript knows that the only valid T for this is ‘number’, where the input is List<List<number>>, and the output will therefore definitely be a List<number>, and TypeScript can quickly find your mistake if you try to do stupid things with that.
That’s not sufficient though. This covers the [[1], [2, 3]] case, but not the ultra-simple case ([1, 2, 3]) or the mixed case ([[1], [2, 3], 4]). We need something more general that will let TypeScript automatically know that in all those cases the result will be a List<number>.
Fortunately, union types let us define general structures like that. Union types allow you to say a variable is of either type X or type Y, with syntax like: var myVariable: X|Y;. We can use this to handle the mixed value/lists of values case (and thereby both other single-level cases too), with a type definition like:
flatten<T>(array: List<T | List<T>>): List<T>;
I.e. if given a list of items that are either type T, or lists of type T, then you’ll get a list of T back. Neat! This works very nicely, and for clarity (and because we’re going to reuse it elsewhere) we can refactor it out with a type alias, giving a full implementation like:
interface MaybeNestedList<T> extends List<T | List<T>> { }
interface LoDashStatic {
flatten<T>(array: MaybeNestedList<T>): List<T>;
}
Can we describe the recursive flatten type?
That fully solves the one-level case. Now, can we solve the recursive case as well, where we provide a 2nd boolean parameter to optionally apply this process recursively to the list structure?
No, sadly.
Unfortunately, in this case the return type depends not just on the types of the parameters provided, but the actual runtime values. _.flatten(xs, false) is the same as _.flatten(xs), so has the same type as before, but _.flatten(xs, true) has a different return type, and we can’t necessarily know which was called at compile time.
(As an aside: with constant values technically we could know this at compile-time, and TypeScript does actually have support for overloading on constants for strings. Not booleans yet though, although I’ve opened an issue to look into it)
We can get close though. To start with, let’s ignore the false argument case. Can we type a recursive flatten? Our previous MaybeNested type doesn’t work, as it only allows lists of X or lists of lists of X, and we want to allow ‘lists of (X or lists of)* X’ (i.e. any depth of list, with an eventually common contained type). We can do this by defining a type alias similar to MaybeNested, but making it recursive. With that, a basic type definition for this (again, ignoring the isDeep = false case) might look something like:
interface RecursiveList<T> extends List<T | RecursiveList<T>> { }
interface LoDashStatic {
flatten<T>(array: RecursiveList<T>, isDeep: boolean): List<T>;
}
Neat, we can write optionally recursive type definitions! Even better, the TypeScript inference engine is capable of working out what this means, and inferring the types for this (well, sometimes. It may be ambiguous, in which case we’ll have to explicitly specify T, although that is then checked to guarantee it’s a valid candidate).
Unfortunately when we pass isDeep = false, this isn’t correct: _.flatten([[[1]]], false) would be expected to potentially return a List<number>, but because it’s not recursive it’ll actually always return [[1]] (a List<List<number>>).
Union types save the day again though. Let’s make this a little more general (at the cost of being a little less specific):
flatten<T>(array: RecursiveList<T>, isDeep: boolean): List<T> | RecursiveList<T>;
We can make the return type more general, to include both potential cases explicitly. Either we’re returning a totally unwrapped list of T, or we’re returning list that contains at least one more level of nesting (conveniently, this has the same definition as our recursive list input). This is actually a little dupicative, List<T> is a RecursiveList<T>, but including both definitions is a bit clearer, to my eye. This isn’t quite as specific as we’d like, but it is now always correct, and still much closer than the original type (where we essentially had to blind cast things, or accept any-types everywhere).
Putting all this together
These two types together allow us to replace the original definition. We can be extra specific and include both by removing the optional parameter from the original type definition, and instead including two separate definitions, as we can be more specific about the case where the boolean parameter is omitted. Wrapping all that up, this takes us from our original definition:
interface LoDashStatic {
flatten<T>(array: List<any>, isDeep?: boolean): List<T>;
}
to our new, improved, and more typesafe definition:
interface RecursiveList<T> extends List<T | RecursiveList<T>> { }
interface MaybeNestedList<T> extends List<T | List<T>> { }
interface LoDashStatic {
flatten<T>(array: MaybeNestedList<T>): List<T>;
flatten<T>(array: RecursiveList<T>, isDeep: boolean): List<T> | RecursiveList<T>;
}
You can play around with this for yourself, and examine the errors and the compiler output, using the TypeScript Playground.
We’ve submitted this back to the DefinitelyTyped project (with other related changes), in https://github.com/borisyankov/DefinitelyTyped/pull/4791, and this has now been merged, fixing this for Lodash lovers everywhere!
Internships at Softwire
3 November 2015, by Vikki Vile
With recruitment fair season is full flow, we thought it would be interesting to share some of the experiences of our freshly departed Summer interns to give you an idea of what may be in store. Here is what Emily and Stephen thought about their time at Softwire:
Emily: I have wanted to work in software development for a good few years now and coming to Softwire was a big step in that for me. Having done quite a fair amount of research about the company I had come to the conclusion that what with the style of work, the flexibility, the social aspects and the general attitudes of the company (of course I won’t lie, having music lessons and music rooms in the office certainly didn’t hurt!), if I was going to work anywhere in software, then Softwire seemed like the perfect place for me.
At the beginning we had two weeks of training, getting up to speed with C#, Javascript, JQuery, ASP.Net, Bootstrap and AngularJS, amongst other things. Coming from a background of studying computer science at university, I had done a fair amount of Java so C# was a fairly smooth transition, but had no experience with any of the web technologies. We learned quickly though and there was no shortage of support on hand here if you had questions, needed help with something or just wanted some advice from an expert, so it was very satisfying to be looking at so many new things in such a short time.
We then launched our project which I worked on for the remainder of my internship. There were eight of us interns in the team and we were divided into three sub-teams: front-end, back-end and dev-ops. I chose to be in the front-end team in order to put my new found web skills to use and to be able to learn them in a lot greater depth. What I like about working in a team like this is the amount that can get done when you have eight times the mental capacity and coding time of a single person; when everyone pushes their code to the repository at once your program can grow in large amounts very quickly. It’s really exciting to see it coming together with the bits you created working alongside other people’s code.
I think hands down, the things I have enjoyed most about working at Softwire was the friendly, flexible and relaxed environment in the office and the fact that everyone really enjoys what they are doing. They trust you to work smartly and effectively so there’s no chasing you up if you are not in at nine on the dot. I think the general attitude of trust towards employees to just get on with everything as they see fit is a good contributor to the success of the company. Everyone is very happy to be at work, feels relaxed enough to work to their best ability and really cares about the success of their projects without it being forced or artificial in any way.
There’s something to be said about working somewhere that simply doesn’t feel like work because you’re just getting paid for doing what you love. I definitely think I’ve been spoilt coming to Softwire, any future companies I come across are going to have a lot to live up to!
Stephen: I did a 12 week working internship at Softwire after my third year of Mathematics and Computer Science at Oxford. Most of my programming experience had been work I’d done at university, so this was my first proper experience with commercial software development. I always knew it was what I wanted to do, and this summer has definitely confirmed that!
The project I worked on involved extending Umbraco, a content management system used for creating websites in a simple, easy to understand way. We wanted it to be able to create specialised challenges where people could upload scores for various events and be compared against other people on leader boards, in the process, winning awards and trophies for their teams. We added integrated it with other sites such as Twitter, Instagram and Flickr. I started by working on designing a database and implementing an API for it. I really enjoyed doing this from scratch and working out how everything tied together, and I also learned a lot about writing clear, easy to understand code.
Later in the project, I moved on to being the team’s AWS expert. AWS (Amazon Web Services) is Amazon’s cloud storage platform. I spent a lot of my time here understanding how cloud services work, so I could automatically deploy our sites. This was very new to me, as I had done nothing like this before, but it was really rewarding when things started to click into place, and I always had somebody to ask for advice if I needed it.
Softwire really help you improve as you work here, too. We had two weeks of training before we started the main project and over the weeks, our tech lead gave us talks on many parts of software development, including how to use source control and design patterns, which really helped us improve the quality of our code.
Outside of work, it’s been great too. There have been loads of social events while I’ve been here, some of the highlights being trampolining and the company picnic, which have all been a lot of fun.
I’ve really enjoyed my time here, everyone is very nice, and they are keen to help with any problems. It’s also been a great learning opportunity, and the things I’ve learned will definitely have an impact on any programming job I have in the future.