Considering that an internet connection is now deemed to be a human right you'd think that ISPs, that generally seem to rip us off anyway, would've managed to make their connections nice and reliable, especially when you take into account that the internet has been round for a good few years now and they've had plenty of time to get it right. Unfortunately this isn't the case & I decided that I wanted a way to make sure that I wasn't getting (too) ripped off by my ISP.
To this end I decided to make the use of the tools I already had available, a Raspberry Pi that I've been running as a home server, the Munin monitoring tool that I use to keep track of it & the always reliable Speedtest to test the connection.
(The following is entirely Debian & Munin 2 biased, you may need to tweak it for your particular setup.)
The first job was to find some way to run Speedtest from the command line, fortunately while I was stumbling around the internet I came across speedtest-cli which makes life much easier. So first we need to get a copy of the script and put it somewhere;
(You'll probably be needing to make sure you have a copy of Python installed too, for more info check out speedtest-cli's GitHub page.)
Then we need to get some useful numbers from the script, we do this as a cron job because the script can take a while to run, use a lot of bandwidth & tends to timeout when run in Munin directly.
Create the file
/etc/cron.d/speedtest containing the following (modifying the speedtest-cli path to suit your needs of course);
Finally we need a Munin script to create the graphs, the script below should go in
/etc/munin/plugins/speedtest, don't forget it make it executable too, or it might not run (
chmod +x /etc/munin/plugins/speedtest);
Finally, restart munin-node (probably something along the lines of
/etc/init.d/munin-node restart), give it an hour or so and enjoy your new statistics.
Check back soon.
Tagged: Bash, Munin, Raspberry Pi, Tutorial
Published by digitalpardoe on Monday 29 April 2013 at 01:20 PM
As part of the project I'm working on at the moment I wanted a way to automatically update a targets build number in Xcode. My preferred setting for the build number is the current SCM revision, the script below automatically updates the build number in the Info.plist file each time the application is built.
Just add the script as a 'Run Script' build phase for your chosen target in Xcode. The script is only designed for Git, SVN & Git-SVN as they're all I use at the moment.
Check back soon.
Tagged: Bash, Objective-C, Script, Tutorial, Xcode
Published by digitalpardoe on Wednesday 9 May 2012 at 02:58 PM
And while I remember, you can also find out a little more out about.me at alexpardoe.co.uk.
Check back soon.
Published by digitalpardoe on Sunday 30 October 2011 at 07:29 AM
As I never seem to have anything interesting enough to write a blog post of any length about it seems like a good time to mention all the other (far more frequently updated) places that you can find me on the internet.
The popular places (where I'm known as digitalpardoe);
If you must;
There's probably a lot more places you can find me that I've forgotten about, but if you haven't already realised, my username tends to be digitalpardoe so just try a search on your 'social' site of choice.
Strangely, in putting this together, I seem to have thought of something longer to write about.
Check back soon.
Published by digitalpardoe on Sunday 23 October 2011 at 08:17 PM
I’ve finally gotten around to it, writing another blog post, almost one year since the last post containing any meaningful content. Rather than apologising for the hiatus and promising to blog more I will instead move on to something more interesting.
Last year I took the decision to open source two of my main projects, iSyncIt and Set Icon. I didn’t make a big deal about doing it, in fact, I didn’t make any ‘deal’ at all, I just set the GitHub repos to ‘public’. Consider this the (6 months late) announcement of their open sourcing.
The iSyncIt repository contains almost the complete history of iSyncIt development. Unfortunately I started development of iSyncIt before I discovered version control and as a result some of the history is only available as source code bundles in the downloads area.
Fortunately Set Icon development started after I had discovered the advantages of version control so its full development history can be seen in the GitHub repository.
Both of the projects have a fairly non-restrictive license, you can read it in either repository. The downloads section on GitHub for both projects also contains all of the versions of the applications I have ever publicly released.
Now for something a little more current.
This afternoon I flicked the switch that open sourced my final-year university project, Chroma32 (under the same license as the other two). The original idea was to create a (dissertation-grand sounding) ‘photographic asset management system’, the scope eventually morphed into creating a document management system that was as extensible as possible.
The whole project was built around alpha & beta versions of Rails 3 and the alpha-version gems that go along with it. Overall I ended up with a themeable system with reasonably tight integration for complex plugins.
If you want to discover more, clone a copy from its GitHub repo and hack away.
Check back soon, go on, it might actually be worth it from now on. I promise.
Tagged: Cocoa, Objective-C, Open Source, Ruby on Rails, Software
Published by digitalpardoe on Sunday 13 February 2011 at 05:33 PM