CopyExt 2 project post-mortem

Monday’s post on CopyExt 2 turned into more of an advert than a post containing actual information, which I did expect as I was still on that I’ve just finished a project buzz.  So I thought I’d do a post-mortem post of sorts, partly for my benefit so that I don’t forget the things I’ve learned, and partly because I think it might be interesting.  Before continuing I would like to extend my gratitude to a good friend of mine, Dan Abbatt, who donated these cool new icons to replace those I originally used.  Much better!

New CopyExt icons!

Now onto the technical stuff; the following sections aren’t really arranged in any particular order and, strangely, only one of them actually focuses on the coding behind CopyExt.  This post has grown very large actually, so here’s a brief table of contents:

I hope you find it useful, or at least interesting.
Read More — CopyExt 2 project post-mortem

CopyExt 2!

For the past few months I’ve been doing various SpiNNaker related things as part of the BIMPA project.  A lot of the tools I’ve been using are Perl scripts that have been designed with Linux in mind, but (to its credit) I’ve been running them through Cygwin without any issues.  Well, when I say any issues, I mean software issues.  Copying and pasting paths between my Windows and Cygwin environments very quickly became a massive pain.  So in what should’ve been my week off, I decided to resurrect a project of mine I wrote back in 2009!

The ancient version (2009!) of CopyExt runing under Windows XP.

The original version was seriously basic and actually arose out of a similar situation.  I was doing a lot of CAD/software stuff during my final year of undergrad and that involved an annoying amount of copying/pasting of filenames.  It broke when I finally got a 64bit operating system but I decided I didn’t really need it any more.  Until, of course, this week!

Commands added to the right-click menu by CopyExt when at least one file is selected.

I’ve finally rewritten it to work for 64bit Windows!  I haven’t broken backwards compatibility though as I still regularly use a Windows XP machine, but that is now the minimum supported operating system. Read More — CopyExt 2!

PowerPython… or PythonPoint… or something

I’ve been meaning to update this for a fair while now as an uncharacteristically large amount of stuff has happened. Since exams finished I’ve managed to get a job at ECS working for two of my lecturers on two separate projects, which is pretty good because it means my work is varied. Both are IC design projects though, so there is a similar vein running through them.

One of my minor duties on this dual-job is to assemble slides from about twelve people into a large presentation, with cover slides for each speaker, every Friday for a progress meeting we all have. Naturally the first Friday I just did it by hand by importing each one in turn into PowerPoint. However it is a fairly tedious job, and to paraphrase a certain member of staff: why do something by hand when I have a powerful computer under the desk?

So I began to investigate automating the process.

Turns out that Python has an IMAP module in its standard library, which isn’t too surprising I suppose as the Python standard library is enormous. After some playing I managed to write a program that logged into my university email account and downloaded the appropriate PowerPoint attachments.

Read More — PowerPython… or PythonPoint… or something

Twitter Me Xerces!

Following from the spirit of yesterdays post, little victories…

Yesterday I managed to download the front page of my website using libcurl. As good as that was as a learning experience, it wasn’t interesting or useful in the slightest. Today however, I decided to see if I could fetch my status updates from Twitter and display them in a program. So I had a look at the API documentation and it looks quite easy to use, with the exception of OAuth which I’m yet to get my head around. Thankfully, for now, basic authentication is still supported.

The Twitter API uses the REST (REpresentational State Transfer) paradigm which means there’s no concept of a state on the server; i.e. each transaction is considered separately. It also means that it uses HTTP, which is pretty simple to understand. Basically in a REST protocol the URI’s are objects in the system, and the HTTP verbs are how you interact with them. So a GET on a http://server/article?name=REST object would download an article named REST. Simple eh? Check this article if you’re interested.

Anyway, onto the meat ‘n’ taters. Data in a REST transaction is typically stored as XML or JSON. I considered downloading LibYAML and taking the JSON route but a) I already had Xerces, b) I understand XML more than JSON, and c) I couldn’t be bothered to learn yet another new thing.

Read More — Twitter Me Xerces!


I’m finally on holiday after having a pretty brutal year at uni!

I’ve bitten off a fair amount of stuff to do over the summer though. I’m currently nursing my interest in web development by helping to make the website for the unofficial ECS TF2 server. It’s quite nostalgic really, I haven’t done any proper web based stuff since school. I’m quite surprised how much things have changed, for the better thankfully.

A mock-up of my design idea can be found here for those that care. Feel free to vote for a banner. The palette is based entirely on one I found at Fabry Design but I got fed up with constantly using the eyedropper tool to find the colour values so I made a HTML version. That and I wanted to show off. Read More — Holiday!

Term 2 Over

Finally, D4 (our big project of the year) is done and dusted! It was a pretty interesting couple of weeks, despite being filled with stress, aggrovation and late nights. We had to design a fire detection system that could accurately measure temperature, detect smoke and the presence of people from up to four sensors and display that information on a web interface.

The basic design consisted of up to four Sensor nodes that contained a thermistor (measures temperature), smoke sensor from a butchered smoke alarm, and a PIR (Passive InfraRed) detector, and the Central Node which then connected to a PC. Each node had to have a memory to store data in the event of a power or communications failure, and the PC was used to control and monitor the whole system. A database (well, CSV file…) was used to store data from all sensors on the PC and that same file was used by the web interface to display tables and graphs of what was going down.

All in a week…

Read More — Term 2 Over