Metrics and boilerplate code

Second last week at the office! Things are winding down, and the office is getting ready for us to leave (by which I mean they’re excited about us not eating their snacks all the time). The project the other interns have been working on is drawing to a close, and we’re finishing all our pending work and tying up all our loose ends.

This week, Quinn and I were told to help out Connor with his job. We learned that since we’re moving up into the cloud, and all our servers wouldn’t be physically accessible anymore, that we would have to add metrics to all of our code so that we would be able to track how often it was being run, servers that were being hit more often, the distribution of the load among the servers in the cloud, etc. To this end, Quinn and I were given most of the functional servers that are currently up in the cloud and asked to review them and implement any changes that weren’t already made, such as adding logging and connecting the programs to Firehose so that we would be able to keep track of the logs that the programs were generating, and keep track of all the data that was being sent through to the servers.

We attacked this task with gusto. Quinn was given slightly more responsibilities than I was, as I also has the build to maintain and keep running – with all the changes that keep being made to the build, somebody needed to keep an eye on it to make sure those changes did what they were supposed to do. As the week progressed, it became harder to balance both the tasks, as the build grew slightly more fussy, and had to be run a certain way, and I had also run up against a particularly ancient program that had been running on the company servers for a very long while, and had to make massive changes to so that it was compatible with all the other technologies that we were trying to introduce. The changes weren’t very technically challenging, but I had a hard time trying to figure out exactly how to push them into place so that it would play well with the other code that depended on this.

All in all, it was an interesting week – we were given a lot of responsibility, but the work itself didn’t require us to be very innovative, so to say. There was a lot of boilerplate code that had to be inserted, and we helped with that, but it was very interesting to see this side of the code and the coders as well, and to find out that not all code is just practical problem solving, but that there are other elements to it too. Last week incoming, stay tuned to find out how we end it!

Leave a Reply

Your email address will not be published. Required fields are marked *