Monthly Archives: August 2017

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!

Finished Logging!

I finally finished the logging for the build! It wasn’t easy, and I kept running into one challenge after another, but ultimately I was able to finish it.

QA and I set a goal of Thursday, by which I was to try and finish the logging for the build, so that we would be able to do a test run on Friday, and have it all good by the weekend. Chip was out this week, so we also decided that we would surprise him with the whole thing done when he got back. With this in mind, I sat down on Monday, trying to get at least the morning segment of the build done by the end of the day.

The morning segment was fairly straightforward, all I had to do was make sure all the steps for two of the daily collections had been run. The early afternoon steps were slightly more problematic, as I had to dig into huge blocks of code to find out exactly which functions were being run for which menu call, and then had to time those functions and log their occurrences to HipChat. Though this initially seemed to be a tedious task, I eventually figured out that this was teaching me how to find certain segments and be able to link it to all the functions that it calls/are calling it, which can be really useful for when the code crashes (which it occasionally did while I was trying to compile my changes. I then progressed to the late afternoon build, which is the most complex segment of the build, and has multiple concurrent processes, which all need to be tracked, as they are interdependent. This was pretty challenging, as some of these processes also collided with processes being run at other times of the day, but with different inputs. This led to a few complications, but as previously mentioned, once I figured out which methods depended on variable inputs and how they functioned with the inputs, I was able to connect them to HipChat with relative ease. All it then took was finishing the job, which just required more of the same thing, and making sure that the logs didn’t collide and the build didn’t crash.

That’s all for this week, I’m not really sure what I’m going to be working on this coming week, but if the last few weeks are any indication of it, then I’m sure it’s going to be challenging as well as informative! Keep following to find out what I end up doing with my upcoming week!