Today, as a little bit of an indulgence, I had a play around with my RFID reader (from the excellent Touchatag starter pack), an old computer we had kicking around, and the Foursquare API. Why? I now have a reader on my desk which, upon me swiping my ID badge over it when I arrive at work, will check me in to the Main Admin Building. I’m planning to expand it to do other interesting things at a later date, such as letting me swipe my mug (I really need a SMUG) over it to turn on the kettle.

The reader, placed next to my phone.

So now, to the interesting bits. The reader is a ACS 122U Tag Reader, plumbed into a bog standard PC running Ubuntu 11.04. On this PC I’m also running the latest version of Ruby and Tender Lovemaking’s NFC wrapper. I should point out at this point that the prerequisite of libnfc can be a bit exciting to install along with all its dependencies, including an awesome bit where you need to compile a load of stuff, package it and then unpackage it all on your local machine. Fortunately instructions do exist to help.

Once that’s all done the Ruby script itself is quite simple to get going. I based mine on something that was previously cobbled together to let us play Harder, Better, Faster, Stronger using OS X’s ‘say’ command, which was based on something that Julian Cheal had come up with, which was based on something that Tender Lovemaking (again) had come up with. Your mileage may vary, as when I tried to do something similar on my laptop (OS X) it transpired that I’d somehow got 3 different versions of Ruby, all working with different gem installations.

Getting the NFC wrapper to read the tags is quite easy, it turned out that I ran into far greater problems talking to APIs to make it do something interesting. I’m using two APIs, one the excellent Boxcar to let me know that things have worked properly (or not) on the headless system, and the other to actually perform the checking in on Foursquare.

A quick swipe, and the world knows I'm here.

Boxcar is a convenient HTTP POST API, which I was able to find some code snippets to steal from with a quick search. Foursquare, on the other hand, is HTTPS. This causes all manner of problems and an awful lot of cursing as I scoured Google for a reliable method of making it work. Once I’d mastered HTTPS, all was good and I was able to effortlessly check in.

The only problem at the moment is caused by the NFC library occasionally seeming to suspend itself for a bit, meaning that it won’t read tags until it comes back. I’m going to experiment a bit on Friday (I’m off to London tomorrow for a chat about SOA) with this to see if swapping thread priorities or using a different polling method will solve it.

I’ve not done a theoretical, academic(ish) blog post for a while, choosing instead to focus on the more technical sides of what I’m doing. However, that doesn’t mean that what we’ve been doing is driven purely by the technology.

What I’m talking about in this blog post is our Nucleus platform – a collection of data stores, APIs and authentication mechanisms which, when put together, allows anybody within the University to interact with data in exciting new ways. Of particular interest is how Nucleus meshes with Student as Producer, our new institution-wide pedagogy. Put simply, Student as Producer is all about empowering students to become part of the production and provision of teaching and learning, rather than just consumers. Students are involved in research, course creation and much more on the academic side. It’s already seen some awesome results, and it’s becoming a massive part of how Lincoln does business.

So, how does Nucleus fit in? The answer lies in the potential to unlock the University’s inner workings for Students to mash up as they like. At the moment if the University doesn’t offer a service, students can’t do anything about it. Want a way to automatically renew books if nobody else has requested them? Nah, can’t do that. Want to mash up room availability with your classmates timetables to find a perfect study session and a room to put it in? Tough.

Understandably, as a former student, this isn’t good enough. So part of our Nucleus platform is trying to open as much of this data and functionality as we can up to anybody who wants to have a go. Obviously it’s still held within an appropriate security framework, but we believe that if a student can come up with a better (or different) way of doing something, they should be encouraged every step of the way.

We’ve got some really exciting stuff coming down the pipeline to help us offer support and resources to students (and staff) who want to explore the possibilities. Stay tuned!

Good question. It’s been a while since I’ve blogged, so here’s a really quick overview of what I’m currently working on, pretending to work on, worked on but haven’t done anything with, or planning to work on.

  1. Linking You, our current JISC project on institutional identifiers. Finishing up next week, and currently causing Alex and myself epic amounts of beating our heads against the desks.
  2. Jerome, our other JISC project on making libraries slightly more awesome.
  3. Zendesk Phase 2, including bits and pieces of integration work to make it smoothly flow through everything else we’re doing.
  4. Nucleus (and assorted fluff), our epic store of everything, being brushed up, pinned down and fully documented.
  5. Authentication being made even cooler, and more reliable, along with support for more stuff like SAML.
  6. GAME, our application management environment, being made more awesome.
  7. Room Bookings will be coming over the summer, allowing people to find and book rooms faster than ever before.
  8. Lots of QR Code goodness all over the place, including on room labels (this hooks up to room bookings for added goodness).
  9. Possibly a bit of hardware hacking in the Library with RFID stuff.
  10. CWD updates to version 3. Faster, lighter, more accessible and generally good.
  11. Total ReCal rollout to replace our legacy Timetable system (we hope).
  12. Replacing the legacy phone book with the new one (we hope).
  13. Data, data, data.
  14. A bit of mucking around with telephony, just for kicks.
  15. Taking another look at our Student Communications project to try and address a few annoyances.

It’s with great joy that I announce a fix for one of the more niggling little bugs in Linking You, a glitch caused by us failing to correctly encode our own strings when we pass them to be minified. What this meant, put simply, was that we’d ignore anything in a URI after the first ampersand or hash symbol.

This is now no longer the case, and all your URIs which are minified in future will work exactly as expected. A friendly reminder to anybody using the API – please make sure you’re correctly encoding URIs when you pass them as a parameter or things won’t work properly.

On a related heads up for API users (including all end users who are using to minify addresses in things like Twitter clients), we will soon be requiring user-specific API keys for these to function. More details next week!

Recently there’s been a lot of noise made about mobile applications for universities and colleges. Apparently what students want to see is a dedicated app for their institution, providing them with bits and pieces of information on just about everything. There are plenty of examples, a quick search of the iTunes App Store reveals several universities which are keen for you to download their slice of application goodness. Entire products have sprung up to address this market, and some places have even gone all out and written their own.

All this is good. After all, who wouldn’t want to be able to check things like their timetable, their library fees and the state of the university’s IT services from their phone? What could be cooler than tapping a button and being told where your nearest free PC or copy of a book is? We like the concept so we’re having a look at mobile stuff, especially given that according to our analytics an appreciable fraction of our users are now trying to access services from their mobile.

However, we’re not entirely convinced about the route of apps. Sure they let you hook straight into things like geolocation and local storage, but with HTML5 so can a website. Apps also need to be made for the whole range of devices out there. iOS and Android are the big players, but you’re then cutting out Blackberry, Windows Phone 7, WebOS and Symbian devices. Apps also have an approval process to go through, or if not then they have a slightly complex installation route. There’s also a requirement either to pay someone a lot of money to make an app, or to spend a lot of money on in-house development.

All this means that we’re steering away from apps as much as possible, but we still want to make sure we provide kick-ass mobile services. “How?” I hear you cry. The answer is amazingly simple – we’re going back to mobile-optimised websites.


In the past few weeks I’ve been dabbling (in between my ‘real’ projects of Jerome and Linking You) with the concept of ‘dashboard’ displays and information radiators. For those of you unfamiliar with the concept they are fundamentally a place which presents information in an easy to digest format. Some are pinboards, some are whiteboards, some are clothes lines with bits of paper pegged to them and some are displays or projectors.

What I’ve opted for is the display method, in no small way inspired by the guys at Panic. However, since between ICT we have what is generally referred to as a metric shedload of information that we want to get hold of I decided that instead of crafting a display for each individual group’s specific needs I would instead come up with a sexy looking framework for rapidly building dashboards. These are designed to live on large screens dotted around the office, visible all day to anybody who happens to look at them.

There’s already an example in use at the Service Desk, where a trusty old iMac is proudly displaying various stats from Zendesk (our ticket manager) to the support team. Initial feedback is that people really like being able to get an overview of what’s going on in one place, as well as any urgent jobs and their feedback averages.

Down in the depths of OST, on the other hand, we’re not massively bothered about our ticket stats in such an immediate manner. Instead we’re far more interested in things like our server availability, response time and load. This means that the modules on our dashboard currently pull data from our Nagios monitoring tool, informing us with the red alert klaxon from Star Trek if things go horribly wrong (causing much turning of heads towards the board to see what’s happened, and everyone else in ICT looking at us in confusion).

Hopefully as time goes on more people will find data which can be represented using these boards, meaning that they will start popping up in more places and exposing data which lets us make faster, smarter decisions about what we’re doing. I’ve already started working on a dashboard for getting the data from the agile development tracker that Alex and I use into a really easily digested format, and I’ll be talking to the Projects team to find out exactly what they want to see with regards to more overarching project management.

Easier? I think so.

Hot on the heels of my Staff Directory Search, I decided this lunchtime to make it even more awesome. “But wait Nick!” I hear you cry. “How can you make it even more awesome than it already is?”

Well, how about avatars for everybody (using the awesome Gravatar system), adding tel: links to phone numbers so users with compatible software can dial with one click, kitting out everything with semantic markup using the microdata spec and adding OpenSearch descriptions?

It is with great and unreserved pleasure that I announce the grand opening of one of ICT’s latest projects, which has been occupying a surprisingly large amount of my time over the last two months and which has led to me wrapping my head around some quite interesting bits of JavaScript.

Zendesk is here. Or, as we prefer to call it, the Support Desk. It’s a one-stop shop for all your ICT and Estates queries and requests, managed by our crack group of support agents and backed by the combined centuries of knowledge and experience offered by the ICT and Estates teams.

It’s been an interesting journey thought the backwaters of the University’s policies and processes, a less than enjoyable romp through bits of law which I didn’t even know existed, and an exhilarating codathon whilst I wrapped my head around slinging JSON across the ether and inserting it into some HTML elements which don’t exist on a page I don’t control using nothing more than a well-crafted bit of JavaScript and a paperclip. All that is behind us now, so it’s time to tell you what’s new and awesome in the world of getting ICT and Estates support at Lincoln.

First of all, we’ve taken the best bits from both, ditched the worst bits and then streamlined the whole process. From the moment you call or email your request it’s placed directly into Zendesk from where we can monitor how it’s doing. Even better, why not submit your query online using our new request form, now with even fewer annoying questions which you don’t know the answer to than before. It’s a simple matter to sign in using your normal University details and skip the whole process of telling us your name, email address, room code, phone number, line manager, inside leg measurement and what you had for lunch yesterday.

As soon as your request is logged you’ll get a request tracking number within seconds, followed up by emails every time we update your request with something you need to know. You’ll never be out of the loop again, and you can even go online and check all your requests to see how we’re getting on. Leave comments, upload files, tell us that it’s solved and more all from right within your browser.

We could have left it there, but we weren’t done. It only took a few minutes of looking to realise that our how-to guides, instruction manuals, FAQs and more were scattered hopelessly around the Portal, Blackboard, paper help sheets, PDF files, student guides, posters and more. This wasn’t good enough, so we decided to bring them all together into Quick Answers. It’s the place to find solutions to your problems both common and esoteric, guides to walk you through getting things done, information on what’s going on and all kinds of other things. Just type your question or a few key words into the search box and see what we can tell you. Think something’s missing? Just drop me an email and we’ll get it added.

At the end of Phase 1 we’re really excited about the changes and we hope that they make everyones lives a lot easier, as well as helping you to get your problems solved faster than before. Support Desk: now open.

I’ve had a couple of people ask how my lunchtime project today actually works behind the scenes, so here’s the lowdown in easily-digestible speak. I should point out that I am relying heavily on two frameworks which we’ve already built at Lincoln. These are Nucleus – our heavy-lifting data platform – and the Common Web Design – our web design and application framework. These two gave me a massive head-start by already doing all of the hard work such as extracting data from our directory and making the whole thing look great. Now, on with technology.


Today on my lunch break I enjoyed a creamy chicken and broccoli bake from the Atrium, and then decided to muck about with code and see what I could come up with.

Turning to the power of Nucleus, our one-stop-shop for data, tying it together with the Sphinx search engine we’ve used previously in Jerome, and wrapping it all up in the CWD I was able to come up with a glossy version of our existing Staff Directory.

Give it a whirl at

Staff Directory v2, complete with Bakelite rotary dial phone.