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!
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:
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 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!
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!
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.
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.