DockerCon 2017 - highlights & experiences

So, DockerCon! It turns out that building cool stuff gets you places. Back in 2016, I built a Docker Swarm from 5 Raspberry Pis by following Captain Alex Ellis’ tutorial and then went on to create two different visualisations for the swarm to demonstrate real time load balancing. This was picked up by Alex who got in touch soon after with the amazing news that Docker wanted to invite me to DockerCon17 in Austin, TX! I was incredibly excited about the prospect and asked if I would be able to give a talk showing some of the things I’ve done with Docker, so it was to my delight that they agreed. What is DockerCon like? DockerCon is the most continue...

Dockering with cardboard

Although the PiGlow visualisation of CPU usage was pretty, we reckoned we could go a couple of steps further and integrate a much more complete tangible solution - a hardware-driven load monitor dashboard. Made of cardboard. This was to be driven by two high torque servos (Ben had them lying around) which would rotate according to whichever performance indicator we chose. Servos are not, of course, very good pointers so with a trusty craft knife to the fore we re-purposed some Pi packaging into a cardboard user interface. On the code side, we particularly wanted to monitor the load across the entire cluster so we ended up writing our own Python HTTP API with Flask and copied client scripts over continue...

Visualising Docker on Pi with PiGlow

In my last post I described how I set up a 5-strong Raspberry Pi Docker swarm. It wasn't long before I realised I wanted some ambient way to see how they were performing which a) didn't involve staring at a screen and b) would wind up the cat. Luckily my friend Ben was round and he's quite into tangible stuff so after rummaging in a few dusty boxes for inspiration we found a PiGlow and wondered if that would do the trick. We stuck the PiGlow on top of the swarm and sure enough, thanks to the great Python PiGlow library from the pirates over at Pimoroni, we managed to get the LEDs to map the CPU usage. As ever continue...

RStudio Server

My father, Ben Anderson plays with numbers. As his Twitter bio says "big data, small data, open data, any data". He works with R a lot and has been persuading me to take a look at it. I've held off until now because I'm all for analysing data in real time (primarily using delightful JS libraries such as Chart.js and D3.js). As far as I understood it, R is geared towards static data analysis and because of that, is able to utilise the hardware it runs on to optimise computations. Dad has an SSD in his Mac which reduces the time to load data substantially, but he also makes use of the R package data.table. This library continue...

Announcing a brand new app - Healthy!

Note: Healthy was launched about 5 months ago but I've only just got around to writing this post. On Nov 3, 2015, SubjectRefresh spent a day in London at the annual Open Data Institute Summit, where we gave two presentations on our Young Rewired State Festival of Code 2015 Refresh app. We were also challenged to create an application using open data that gets people to eat healthier. We came up with Healthy, a calculator that tells you "the time to burn" of a particular food. It's built on top of Node.js and uses Socket.io to communicate with the browser in real time. This means no page refreshing, no Ajax calls and no latency. We use an API continue...

A URL shortener written in ten minutes

Friday night, or more specifically, Friday February 26th 2016 at 19:45:57, I was having a group Skype call with Alexander Craggs, Miles Budden and Tom Emmerson when Alexander started complaining that all the URL shorteners out there were becoming too long. To clarify, URL shorteners were becoming bloated. He suddenly said, "Let's make a URL shortener". The situation escalated very rapidly and within 5 minutes, Miles had bought the domain subr.pw for an astronomical price of £0.60, I had setup Nginx on the server used for the majority of SubjectRefresh's projects and Alexander had setup the codebase and had a Node.js skeleton ready to go. We went with subr.pw for two reasons. The first continue...

Refresh - a revision tool with a difference!

During the YRS Festival of Code 2015, "SubjectRefresh" and I created a revision app called Refresh. It's built using Node.js and works by scraping the exam board website (currently only CIE) for the PDF for the syllabus the user has requested. The PDF is then converted to HTML using a PDF to HTML converter and is then shunted through Node's Cheerio library. We then find out where the relevant information in the HTML is and send that off to TextRazor. We then use the information about the text that TextRazor gives us to construct questions to ask the user. These are in gap fill format because keywords are removed. The reason we did this is because the answers are continue...

Real time PHP applications

I admit it, I've started writing all of my new projects in Node.js. Why? Because most of them are lightweight and I want them to be real time. PHP can be a real pain when it comes to doing anything remotely real time. First off, it's designed to execute as quickly as possible and send a response to the client, which is of course good. However, what is bad about that is that it doesn't stay alive - it does its stuff and then dies. Node.js on the other hand runs in a single process, which stays running all the time. This is perfect for real time applications because you can fire off an event to Node.js continue...