Softwire Blog

Lightning Talks – A Recipe for Disaster

2 March 2016, by

In October 2015 we ran another Lightning Talks competition where eight employees each had five minutes to tell us something they find interesting – inside or outside the software development world. We had talks this year on topics from SignalR to RSI!

Once again we voted on our favourite talks and the top two won Amazon vouchers.  This is Ben Below’s winning talk about the interesting and humorous world of test data!


Lightning Talks – Langton’s Ant

18 February 2016, by

In October 2015 we ran another Lightning Talks competition where eight employees each had five minutes to tell us something they find interesting – inside or outside the software development world. We had talks this year on topics from Security to Simulating the Sky!

Once again we voted on our favourite talks and the top two won Amazon vouchers.  This is Rupert McKay’s winning talk about the cellular automata and Langton’s Ant!


“Masters of Code” Hackathon

2 December 2015, by

A long time ago, I got a message from one of our clients asking if I wanted to go to the Mastercard “Masters of Code” hackathon: I definitely did, and it finally happened this month.

Hackathons are tihomemes where people from all across the development life cycle get together to make something solving a problem. The catch? It’s in 24 hours. I really enjoy coding and getting something in your hands at the end of it. Hackathons are also a great place to learn loads of different skills (coding, and otherwise) from the wide range of people that attend.

Despite grand plans from a lot of people, we ended up with a target crack team of 2 people. We were challenged to make the day-to-day lives of London Mastercard easier by integrating with a combination of the TfL and Mastercard developer APIs. These are sources of some really interesting data and abilities – letting you plan routes, see the city and make payments with vendors.

24 hours is not a lot of time, and so we set to work straight away on working out what to build. We settled fairly early on using Mastercard’s loyalty offers API, allowing us access to personalised offers of the user that will use the app. All too often, people get these offers but don’t take advantage of them. A higher take-up rate on these offers will benefit both Mastercard and the end-user. The user gets savings, and Mastercard get people using these offers and – in turn – spending more on their card. Win-win.

We used TfL’s journey planner app to help users plan their journey and get advice as to the best route from A to B in London. However, when users change lines or transport routes at various stations, we looked out for opportunities for users to stop off if they had things to do at these interchange points. We went further and advised people how much would be added to their journey if they went out of their way to tick items off their to-do list. If it’s only 10 minutes, then why not make the extra hop and avoid a 2-hour round trip at the weekend?

options2In terms of the technical nature, we decided to write the application in NodeJS, serving a web interface written using KnockoutJS and Bootstrap. It was the technical framework with which we had the most experience – and with only two of us we were working solidly throughout the 24 hours as it was! When we added persistence, I got the chance to play with a new tech I’d been meaning to checkout – Firebase, Google’s distributed Database as a Service platform. It’s lightweight but first to set up and was perfect for our needs!

We were happy with our end product – an MVP and even some of the nice-to-have features that were a pipe dream just 24 hours earlier!

Other applications including a gamified social-media charity app (“Give to charity or I’ll shame you on Facebook”), an app that encourages you to walk by secretly saving the money you would’ve spent on your train fare and eventual winners “All of Us,” – a Night Out as a Service application, that integrates events, journey and tabs across a range friends.

Our product actually came second in the end – which we were happy about (not least because of the $1,000 prize!), but the whole weekend was amazing to learn a lot about APIs and other developers’ mindsets. The clarity of the idea was praised. We’re proud of what we made. We’re going to give the app a bit of distance for a week or so, but we’re excited about the potential of it – we even used it to plan our journey from the venue back home!

Volunteering with Tech City Stars

14 October 2015, by

The tech community as a whole is not as diverse as society.  Thousands, if not millions of words have been written about it trying to explain and rectify this problem. Every one of those words is worth reading, so I’m sorry for throwing yet more in to the mix!

One thing I’ve seen is that people with exposure to technology and programming in their family life or education are more likely to consider careers in the tech sector. There’s no surprise there: it’s hard for people to aspire to something they haven’t seen. My Dad worked in IT, and I always knew it was an option. When I applied for programming jobs, he had advice about CVs and interviews. I’m aware that these all gave me an implicit advantage that many people may not have had.

There’s a lot of thoughts about how to undermine these systematic issues, but one way that we can begin to challenge these effects is introducing themes around careers in tech to many people that may not otherwise see it.

To that end, we’re proud to have been working with Tech City Stars for the last few years.

CATHmZ6WoAAufT3Tech City Stars work with young people from areas that have higher rates of youth unemployment – the eponymous stars. They run ‘reboot camps’ that introduce relevant skills and ideas to the young people before hooking them up with a range of employees to enter apprenticeships. This is tackling the heart of the issue: taking young, motivated people and making sure their background doesn’t hold them back.

Although we’ve not yet had the opportunity to take an apprentice, we’ve worked with them to ensure that their camps and syllabuses accurately reflect the real experience a person may face when entering the technical world.

One area in particular that we find surprise people who aren’t used to the tech sector is analytical questions at interviews. We use these sorts of questions, that look at candidates’ thought processes when faced with an unfamiliar problem, to give us an idea of a candidate’s ability rather than hearing many rehearsed answers.

This is exactly where exposure to our practises can start to undermine a difference in privilege between candidates. Although no candidates will have seen the exact problems we use, having an appreciation of the types of questions that get asked by software companies prevents unnecessary stress in an interview situation and allows candidates to perform at their best.

2684897_origNow, there’s a chance that you’ve stumbled upon this blog post wondering about interview questions that tech firms do actually ask! Naturally, we can’t give away all of our interview problems over the internet – candidates will give us polished answers tomorrow! – but through examination of other companies process, and through aggregation and recruitment sites, we noticed a trend for a number of questions. (Note that we don’t necessarily endorse these questions – but if they get asked often enough, we felt it our duty to teach them.)

We’ve included a few types of questions below, so that anybody can start to think about and prepare for any application – but be warned that this list is not exclusive. The only thing that these sorts of questions will have in common is the need for clear, analytical thought. The advice we give to all the Tech City Stars is to explain your reasoning, keep a clear head, and use logic to break the problem down into smaller steps. Although a programmer’s gut instinct is an important tool in the long run, it’s not going to be impressive to an interviewer if you try and wing every question!

Sample Questions Types

Long-form ‘open’ question: What is the hardest thing that the developers had to, in order to get Siri to work?

Mathematical/Logic question: You have a cube that is made of 64 smaller, identical cubes in a 4 by 4 by 4 arrangement. I paint the outside using paint. How many of the smaller cubes have 0 faces painted? How many have 1, 2, 3, 4, 5 or 6 painted?

Estimation question: How many words are there in total in all seven of the Harry Potter books?

AngularJS vs KnockoutJS – Part 3

15 September 2015, by

In previous blog posts in this series, we examined the motivation behind some of the modern JavaScript frameworks that aim to make front-end code more maintainable. We also examined AngularJS and KnockoutJS as specific examples of how they individually integrate data models with HTML views.

This blog posts aims to compare how well the two work: we don’t want to fall in to the trap of suggesting that they are competing with each other as they both do different things. However, as two libraries that make front-end development easier through attributes, it’s rare you’ll use both and so you’ll often reach a time on a project where you have to make a decision between two.

Setting the Framework Up

Setting KnockoutJS up is as easy as you’d like it to be – you can pull the source file into your project by downloading it, linking to their CDN or using package management tools such as Bower. It works nicely with all major dependency tools such as RequireJS, or can be included globally in your project. All you need to do to get it working is call ko.applyBindings in one place. It works nicely with all of your code, and can be added at any stage in the project as it plays nicely with other libraries.

AngularJS is a bit more of a tricky beast – building a project around it from the beginning is not much more effort than KnockoutJS. There’s slightly more boilerplate at an early stage to deal with modularisation, but these costs are mostly compensated by not requiring the set-up of, say, RequireJS.

Adding AngularJS to an existing project, however, is significantly harder. Because of the opinionated idioms that come from the use of AngularJS, it’s often hard to make it integrate seamlessly with other code you’ve already written. We’ve used AngularJS with other module loaders, for example, but the cost of maintaining that has been far higher than expected.

Conclusion: On greenfield projects, both libraries perform well. KnockoutJS is easier to add incrementally to an existing project.

Browser Support

A minor point, but if you have to support Internet Explorer, then you may have a harder time with AngularJS that has a small number of outstanding issues on all IE builds; and no support for IE versions 8 and under. KnockoutJS goes all the way back to IE6.

Conclusion: If IE6 or 7 support is important, AngularJS cannot be used.

Community Support

One of things that makes JavaScript fascinating (or, if you’re one of the front-end nay-sayers: tolerable) is how fast the community moves. There are now more npm packages than there are Maven Central libraries, showing just how fast people rally behind languages to bolster its features.

We have to be careful about comparing raw statistics of two libraries of differing sizes. In terms of Google Search trends, AngularJS is over 12 times as popular, and exponentially rising. Angular is the second most installed bower package, whilst KnockoutJS doesn’t make the top 100.  The trends certainly suggest that AngularJS has more staying power.

AngularJS’s modular nature makes it a natural fit for community support as people can add directives, modules and services that can be easily pulled in and integrated with your code. This means that if you’re requirements are common, then you can use a large number of off-the-shelf libraries.

KnockoutJS does allow you to write bespoke additions by creating your own bindings, or extending the knockout object itself in an easy and well-documented manner. Although there are some KnockoutJS libraries to add features such as Pager.js for routing, there are definitely fewer. At least a few times I’ve thought “Surely someone’s done this already” when writing features with KnockoutJS.

Conclusion: AngularJS is much more popular, and has more community libraries.

Ease of Learning

The documentation and online tutorial for KnockoutJS are some of the best I’ve seen. Knockout is so simple and light-weight that when new developers see it, they’ve always taken to it immediately and are able to contribute to development teams very quickly.

AngularJS is a much bigger beast. Their documentation is, necessarily, much more heavyweight and bulky to reflect the larger amount of things that people have to learn. Almost everyone who has worked long enough with AngularJS is now happy with how it works and can contribute speedily, but it often takes longer to reach the same depth of understanding.

Conclusion: KnockoutJS has simplicity and brilliant documentation on its side; the larger AngularJS can’t compete.


AngularJS was made with testability at the very front of its mind, and there are lots of guides online about how to set up unit and integration testing on your AngularJS modules. We’ve had great experiences running our JavaScript unit tests on such projects with Karma and WallabyJS giving us instant feedback when things fail.

KnockoutJS is unopinionated about tests – it’s a much smaller library so we wouldn’t expect anything else. If KnockoutJS is used with some modularisation frameworks (which we always strongly recommend!) then good discipline, such as encapsulating all low-level DOM manipulation, makes unit testing no harder than with any other library.

Conclusion: Both libraries are testable, though AngularJS was written with this very much in mind, making set-up marginally easier and more documented.

So, which is better…?

We’ve found in projects at Softwire uses for both frameworks.

We typically favour KnockoutJS on projects that have less need for the larger, more opinionated AngularJS. This could be because there is less complex interactions between the user and the data; or because the project simply runs for a shorter time. For legacy projects, it allows us to use it minimally only where we need to, preventing a large initial investment of effort. A lot of developers here love KnockoutJS and many use it on their own pet projects because of its light-weight approach.

We have, however, used AngularJS successfully on a number of projects. We’ve found that the ramp-up time is slightly higher, as it takes control of more aspects of the code base. However, if there is sufficient complexity or on a project, or the code base is larger, the initial set-up and learning costs on a project quickly repay itself and it becomes our framework of choice on large projects with potentially complex user interactions.

We are, as we are with all technologies that we use, constantly examining the ecosystem for new and maturing options outside of these! For those interested in seeing more frameworks in action, TodoMVC is a great website that codes the same site using multiple different libraries.

David Simons trains developers in High-Quality Front-end JavaScript. Sign up to his next course here.

AngularJS vs KnockoutJS – Part 2

8 September 2015, by

Previously, we looked at one of the most talked-about family of JavaScript libraries: those that follow the MV* pattern to decouple the visual concerns of a web application from the data-driven business logic. This blog post serves to give a brief introduction of two of the most commonly used such libraries – AngularJS and KnockoutJS.


AngularJS vs KnockoutJS – Part 1

1 September 2015, by

In Softwire, we’ve used AngularJS and KnockoutJS on a variety of projects, and have found that this makes web development a lot easier and a lot more pleasant! With this series of blog posts, I’m hoping to share what we’ve found out about these, and other, data-binding libraries along the way by looking at:

  • What groups all these libraries together?
  • How do these libraries work?
  • Which library is the “best” one?


Lightning Talks – Modern IDE Usage

3 June 2015, by

In April 2015 we ran another Lightning Talks competition where eight employees each had five minutes to tell us something they find interesting – inside or outside the software development world. We had talks this year on topics from the Java ecosystem to general relativity!

Once again we voted on our favourite talks and the top two won Amazon vouchers.  This is Suzanne Hamilton’s winning talk demonstrating the power of modern IDEs, where she refactors an example piece of code based on Martin Fowler’s book “Refactoring” without ever typing anything!


Lightning Talks – Juggling Theory

22 May 2015, by

In April 2015 we ran another Lightning Talks competition where eight employees each had five minutes to tell us something they find interesting – inside or outside the software development world. We had talks this year on topics from Node.js servers to learning to commit!

Once again we voted on our favourite talks and the top two won Amazon vouchers. This is Rupert McKay’s second place talk introducing the audience to the surprisingly deep, mathematical world of Juggling Theory

Lightning Talks – How to Build an Orbital Laser Battery

20 January 2015, by

In October 2014 we ran our fourth Lightning Talks competition. The number of speakers this year was sufficient that we ran two sets of talks where eight employees each had five minutes to tell us something interesting about software development. We voted on our favourite talks and the top three won Amazon vouchers.

Here is Harry Cumming’s second place talk from the first round, in which he builds a Orbital Laser Battery… API.