Last week, I spent the majority of my time refactoring and restructuring KnowledgeNow with Martin’s help, either pair programming or checking in with him for what I should be changing and how, then going away and coming back when it’s done. Martin left for two weeks holiday at the beginning of this week, but I was under the impression last Friday that there really wasn’t much left to be done, and that I’d be able to polish it off nice and quickly all by myself. It turns out I was wrong, and one week later if feels like I’ve hardly dented my “polishing off” checklist. The missing tests turned out to be trickier to write than expected, and the extra features that needed adding were a lot more involved than I gave them credit for. The team were really supportive, and were happy to help me crack any particularly tough problems, but not having anybody else working full time on this project with me was a bigger shock than I was expecting. Suddenly I was captain of my own ship, and it was a lot more work than I realised. It’s been a really fun experience though, and the satisfaction of having my web application now report feedback back into service now, seeing those results in the ServiceNow web app itself, was fantastic after all those hours of work to make that happen.

Adding the “Was this helpful?” functionality involved adding methods to the ServiceNow api wrapper (originally written for Fast Track Tickets) that allow new items to be posted to the Knowledge Base Feedback table. This now means that users can report whether or not they found an article helpful and are then presented with a comment box to add extra information if they wish to.

The rest of my week was spent cleaning this code up and adding tests, something that I always seem to underestimate in terms of the time and effort required. Crossing the 50% line for test code coverage shouldn’t have been a huge achievement but it felt like it. My plan for the coming week is to keep the momentum going with writing tests and to try to cover the entirety of the project as thoroughly as possible before refactoring again and requesting a code review from the team.

As the buzz of having such a successful meeting last Friday wore off, the reality of turning a mock-up into a fully functional project started to set in. Almost the very first thing I did on Monday was create a code map from Visual Studio for the project. Trying to explain the connections between classes and functions to other members of the team showed me just how little I understood my own work. This was a jumble of lines from tutorials and stack overflow articles that were somehow leaning against each other in such a way that they didn’t crumble to the ground, and in the relatively safe and stable environment of short presentations that was fine, but the real world wouldn’t go so easy on my code so something had to change.

Original code map for KnowledgeNow

The code map that was generated is pictured here, not for anyone to analyse and understand but more to illustrate what a large amount of code needed changing. Attempting to write tests for this mess before digging in and moving things around, I found that badly structured code is naturally harder to test than clean code. The terrible irony in this is the fact that the code in most need to thorough tests is the hardest to write them for. A lot of my classes got restructured and refactored without any underlying tests, we just relied on the fact that we could revert to an older version if anything went terribly wrong, and then we wrote tests for the cleaner code afterwards.

The seemingly insurmountable hill has certainly been an uphill battle, but it’s actually been quite fun at times. The satisfaction of taking something messy and working at it like clay until it’s something clean and logical can’t be underestimated. We’re at the point now where the structure is actually making sense, some tests have been written and a bunch of empty test cases have been set up ready to be filled in. Soon, I can turn my attention to the requested changes to the system and features I hadn’t included in the original mock-up.

KnowledgeNow Newer Code Map

Profiles.soton has also been going along in the background. I attended TAG on Monday, a relatively frustrating experience at first, being told we hadn’t planned this well enough of done a vigorous enough requirements capture. The meeting soon got back to the original purpose though, and architecture options were talked about. Seeing documents I’d created on the TV at the front of the meeting room and having people analysing them there in front of me was a little nerve wracking, but it was really interesting to hear what people thought of the options. My favourite option, of adding everything into the Active Directory database and encouraging people to use that as their go to for information on users, was immediately discarded. My understanding of the purpose of Active Directory was clearly a little off – it seems it’s designed to be a very slim database only used for information such as roles and permissions. The committee seemed to quite like my second favourite option of the three, adding this information on top of IDM and reading it straight out of that system, rather than sending it downstream to Active Directory.

We decided to go away, do some more research into existing profiles systems, and will return next week to present our ideas again. I spent a little bit of time investigating existing profiles systems at the university such as efolio, pure, sharepoint, and even blackboard. None of them quite meet the requirements we’ve gathered, but the idea of building another profiles system on top of the large number the university are using without offering some kind of consolidation across the various platforms didn’t seem right. The plan now is to provide information to these systems and have a central system for updating the information, disabling any editing in the other systems being used. This allows current users of these systems to still display their information there, but centralises the process of updating it, ruling out any chance of discrepancies between systems.

Once I’ve finished working on KnowledgeNow, I’ll be helping with the development of profiles.soton, so it’s been good to keep up to date on what decisions are being made about it.

Coming back from my week away, This is Malware had moved along and was much closer to being released than when I’d worked on it two weeks ago. There were still a few features that needed adding and I got to help out with some of those, mostly on hiding UI elements depending on user privileges. My next small helpful task was to test out some of the online eprints functionality after changes had been made to the plugin structure, reporting bugs back to Patrick who then fixed them.

I also got to help write up the documentation for the profiles.soton architecture options. Profiles.soton is a profiles system that is in the early stages of development. The documents and diagrams I helped put together are going to be taken to TAG, the Technical Architecture Group, on Monday morning. I’m hoping that my diagrams and analysis of the options will encourage the group to go for the cleanest solution in my opinion, which involves the most changes to existing systems and storing more information in the Active Directory but results in a cleaner more easily maintainable overall system. Moreover it will allow for other systems to easily follow suit once that extra information is easier to access all from one source. Systems currently gather this information from various disparate sources that could easily lead to inconsistency.

Next I carried out a small manual data management task for the eprints system. Since updating to Pure, the eprints “shelf” system broke, and instead articles now need to be added manually to a project. This was a simple task of copying and pasting publication ID numbers into the web application and adding the result to a project.

The most important part of my week, however, was preparing to present my proof of concept web application to Service Management on Friday morning. I’ve worked on this web application on and off for a few weeks, and this meeting originally seemed like the final full stop on the project. The original plan was that if Service Management wanted a system like this to be built that they’d request it from the team and have a project added to the pipeline for development in a few months, long after I’ve left.

Presentation Notes

However, the demo was met with a more positive response than I could have ever hoped for, and they asked if we could make this live as soon as possible. Suddenly, the code I’d thrown together in a language I’d not touched in years using technology I hadn’t really thoroughly researched was being added to the team igit, and I began kitting it out with a test suite. In hindsight, I should have designed the system more carefully, and it may be the case that a lot of it gets rewritten to make it suitable for actually going live. I believe by the time I’ve got this project ready for deployment, I’ll have really thoroughly learnt to always keep my code clean and maintainable regardless of it’s purpose and scope. As difficult as it will be to clean this up and get it production ready, I’m thrilled that something I’ve worked on during this internship could be live by the time I leave. My goal is to have it ready in time for Fresher’s Week so that new students adapting to life at the University will be able to take advantage of an open more accessible knowledge base.