Open Data Internship – Week 7 – In the name of progress

“OK, so the plan is simple, we cut through the vent, squeeze down the air duct, take a left and avoid the IR lasers, before carefully dropping down onto the desk so as to prevent setting the pressure sensors off. Before diving though the door and into the office. So any questions?”

“Yes. Why don’t we just go in through the door behind you, which is wide open?”

The past two weeks have been quiet, and for quite a few days I was the only person in the office and as such have been left somewhat to my own devices. This has meant that I have primarily been working on tools for maintaining the data behind the campus navigation map, which is currently a large JSON file.

Whilst developing these tools I have been considering ways to improve the life span of the programs I am developing. The main way I have been working on this is by trying to keep the application as far abstracted from the data as possible. To achieve this I decided to create a schema for the data being used in the map, which is used to create the interface for the data view/editor that I have been building. A frame for the data is created from the schema into which the data is placed, this allows the data structure to change as a user could change the schema and the data would still display, albeit with holes where new unfilled fields exist.

To achieve this I created a text file which was essentially a JSON file with the ‘{‘ and ‘}’ characters replaced with tabs. Unfortunately at the time I did not realise that was what I was doing and went on to write a not insignificant amount of code to read this file into a python dictionary. Mildly impressed with what I had done I showed it to a friend who pointed out that I was essentially reading in a dodgy JSON file and therefore if I changed the format to JSON I could read the file in using about three lines of code. The following morning I spent a good five minutes trying to justify to myself a way to keep the work I had done in my project, as it felt wasteful to delete it. However, in the end it was axed. This did get me wondering about things such as pair programming, which I usually dismiss as a waste of time and resources, as since only one person can type at a time, and people have the annoying habit of having unique(ish) thoughts, which could lead to conflicts over how to achieve tasks. However here it would have saved me half a day’s work. Eventually I reconciled these two views with a compromise, which I think balances efficiency with… well efficiency, that is with regular code reviews. As you still get two people programming at the same time, but also help to prevent programmers from running too far down the wrong path on how to solve a problem as the reviewer can point out such errors, as happened in my case. This would further help with maintainability of code as if you have multiple people regularly reading the code then the comments on such code should be useful.