David's Tech Space

Electron.js (@reverentgeek)

Electron is a framework that creates desktop applications by running an embedded browser. David Neal rightly pointed out the advantages - you get to write your familiar HTML/CSS/JS - and the disadvantages - being forced to write in your familiar HTML/CSS/JS. Electron looks very powerful and very cool, especially because it means that it means that your desktop applications can be written cross-platform. Such successful tools at github’s text editor Atom have already been written on this and it looks like a cool tool that anyone likely to write desktop apps should add to their arsenal.

Graphical CLIs (@patrickkettner)

Patrick is a Product Manager at Microsoft Edge, but was talking about his experience migrating pet project Modernizr from a web app to a command line app. Not just any command line app, though, one that masquerades as a desktop app, and one that was written in node. Honestly? I’m very unlikely to ever use this but it’s amazing to see just how prevalent node can be these days.

Cellular Automata (@_Irina)

Irina had an infectious enthusiasm for analysing the complexity that can quickly arrive from very simple rules. The most famous cellular automaton is Conway’s Game of Life: you put live and dead cells (or koala and turtles) and based on how they appear near each other, they evolve into future generations. Visualising these patterns in JavaScript looks amazing, and made me want think about where else something like this could be relevant.

Debugging with Chrome Debug Tools (@MattZeunert)

Slides: http://www.slideshare.net/DavidSimons5/statistical-programming-with-javascript

The reason I gave this talk is because there’s a lot of misunderstanding in the wider community about what statisticians actually do. Fundamentally, they look at data - which is fundamentally any piece of information. That said, the kind of data that capture statisticians attention is data that comes in large amounts. By looking at data that comes in regularly from the same place we can start talking about trends and patterns rather than wondering if an abnormally high amount was a one-off occurrence.

I looked at Montevideo climate data for the talk itself, but this was to add a bit of local flavour. There’s probably a lot of data on your project you can - and should! - be analysing. As well as the data that appears functionally in your app (price, object counts, large text ripe for NLP pickings), there’s also non-functional data such as page load times and performance. Even if you’re unaware of it, there will be something for you to analyse.

Once you’ve got a lot of data from the same source, you may be wondering what to do with it? These days, the automated manner of data collection means that there’s just too much to try and pick through it by hand, which is why we try and summarise our data at a higher level. 

Averages such as the mean, median and mode give us a sense of where our data is likely to lie, but two data sets having the same average doesn’t mean we expect them to behave the same. If we had two sets of page load times such as {100, 100, 100, 100, 100} then the ‘location’ statistic is the same as a set of load times {50, 50, 50, 50, 300} - but the latter clearly represents a different performance profile, suggesting perhaps poor performance when the site is uncached or a particularly poorly performant query. If we rely purely on simply location statistics, we may bury these sorts of discoveries.

This is why we need to start thinking about statistical distributions. These are ‘shapes’ of graphs that random variables will expose if sampled often enough. These vary from the simple (a coin toss will elicit a graph with two columns of equal size), to the more complex (heights follow a symmetric ‘bell’ curve) to the downright fancy (wages follow a ‘Pareto’ distribution due to the existence of a minimum wage.)

At this point, we’ve descended deeply into the mathematical so it’s right to start thinking about why we’re talking about this again. There are a number of functional use cases in my career where I’ve looked heavily into statistics, including analysing financial stability. However, there have also been more surprising areas where stats played a role:

We reworked some UI ‘slider’ inputs to follow distributions instead of linearly increasing, which gave people a more intuitive experience

We could analyse user account ledgers to see whether their first digit violated the expected (logarithmic) distribution and hence suggested higher likelihood of fraud (e.g. caused by people submitting more fraudulent expenses that they would expect to be more uniformly distributed within an order of magnitude)

We were able to create more realistic stubbed network data to ensure performance tests worked as expected

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?

In 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 pipedream 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.

What am I trying to teach?

The main reason I set training exercises was to isolate the one item I wanted the trainees to focus on. Every other aspect of the challenge should be something they are already familiar with, or otherwise given to them so they don’t get distracted. This is true both during their coding and during the feedback you give them during and after.

For example, if you are teaching JavaScript, then don’t fuss over perfect styling. And if you are setting a styling challenge, then don’t require knowledge of JavaScript to fulfil it.

It’s the single responsibility principle for challenges.

There has to be enough support to make progress and learn.

When you first start to learn coding, it can be frustrating, because of the high barrier to entry. You need to know a lot of boilerplate and syntax before you can start making good on the promises to make something impressive and interactive.

Coding challenges need to be interesting and compelling, but take users across stepping stones to ensure they are always aware of what to do next. The first few steps should involve understanding and manipulating existing code, and slowly the scaffolding should fall away to give coders more control and flexibility over what they do.

There has to be enough room to experiment and fail.

Despite the support and scaffolding providing a trail through the problem, there has to be enough breathing room to learn.

You don’t learn by ruthlessly copying, and though some people take to concepts like a duck to water, more frequently people may know what they’re using without knowing why they’re doing it. One of the best ways of showing a coder why a concept is helpful is to let them realise their own mistakes - and a challenge too simple or too guided creates a superficial knowledge of the topic, rather than an appreciation of the meat of it.