My programming story... so far

Early days When I was 12, I was given a Raspberry Pi. For the first couple of days, it was really fun. After I had browsed the web for a while and played a bit of Minecraft, it sat in it's box for a few months. I really had no idea what to do with it. That was until I discovered that I could build a website with it. Wow, that was cool. I installed Apache and spent some time finding out where I needed to put the code. I started off getting to grips with HTML in nano (using inline styling, of course) until I realised I could write CSS in separate files and load them in. That was continue...

How does my stuff work?

I have a bit of a complex set up with all my sites and services, mainly due to using a multitude of different tools and languages to deploy different things. Currently, I have one main OVH server which most of my stuff is hosted on, including different database engines, Node.js and PHP apps. Static sites The first thing that traffic comes into contact with on my server is Nginx. It serves as an ultra lightweight traffic 'handler', whereupon it routes the incoming request to the appropriate location. I do this by using different Nginx config files for different domains. Here is an example: server { include /etc/nginx/mime.types; listen 80; listen [::]:80; # IPV6 server_name finnian.io; # compress 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...

Raspberry Pi Swarm

A couple of weeks ago, a friend of mine reminded me about Docker. Docker is a containerisation platform which allows you to deploy different systems very quickly and efficiently on the same host machine. Not only that, you can put several Docker hosts together in order to create a swarm. It's like VMs, but cooler. Having followed a fantastic tutorial by the Docker Captain, Alex Ellis, I had Docker running on one of my Pies in under an hour. I thought this was pretty cool, but I soon got bored of firing up containers which ran little Node.js apps for me. I started to wonder what it would be like if I could build a Docker swarm out of continue...

Git directory server vulnerability

Do you use git to manage your site and or server files? In my opinion, this is undoubtably a good way to run things but you need to make sure it's secure. Just try going to yoursite.com/.git/config. If you haven't secured your server properly, you will see the configuration file for your git repository. Not good, huh? Not only could an attacker reveal lots of information about your code base including where the upstream server is, I believe they could possibly get the entire source. This would allow the attacker to see exactly how the site works and be able to exploit it very easily. Now, the good news. It's an easy fix! Here are the two continue...

Gold DoE Expedition

I recently undertook the expedition phase of my Gold Duke of Edinburgh in a Canadian open canoe. The team and I paddled from just outside Thetford all the way down to Cambridge on the River Thet, the Little Ouse, the Great Ouse and finally, the Cam. For the expedition, we needed to have an "aim". This could be anything from photographing the team at checkpoints to measuring the water PH levels. My team opted to photograph wildlife along the way and due to this, I took along my Nikon Coolpix P610 because it featured GPS - something I thought would be useful when it came to showing where the photos were taken! The camera also had a "logging" mode which continue...

Drones, Zeros and Cake

We all love drones. We all love cake. And we all love Raspberry Pi. What better way to spend an afternoon than to kick up at my mate Ben's house, borrow his faster internet and combine all of those things. We started the day by wrapping a Pi Zero and camera module in excessive amounts of electrical tape and sticking it to Ben's 250-class racing drone. Sounds cool huh? Not only did it work amazingly well, it didn't impact the performance of the quad at all. Pretty good for a 1 GHz fully featured Linux box! As you can see from the image above, the camera module was orientated so as to get a birds eye view from the drone's 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...

Cyber Centurion competition at Bletchley Park

Today, the guys at SubjectRefresh and I competed in the Cyber Centurion Security Challenge at The National Museum of Computing at Bletchley Park. The day started with an introduction by the organisers and a brief explanation of how the day was going to work. Then it was off to the marquee to get started securing the machines we were provided with. There were two Windows VMs (server 2008 and 8.1) and one Ubuntu 14.04 image. The team delegated four people to work on the machines in the first part of the day and swapped out two at lunch time. By the end, we'd managed to get 66% of the vulnerabilities on Ubuntu and about 80% on each of continue...