More Development!

Today we revisit the program from the last blog-post, except this time instead of just looking at the program and evaluating it, we're actually taking their code and adding more features to it.  This was a first for me, editing other people's code and writing in their style, that is.  Though I guess that this sort of thing is pretty much standard in the tech industry, for everyone to build upon each other's code.

Anyways, let's get to it! In addition to the four commands that were present in the first version of the code, we are now responsible to add three additional features to the code base. They are:

• set-baseline: Takes consumed-power levels for each hour of a certain day and uses these as a baseline, or a set that can be used for comparisons. There is an optional date parameter, and if it's blank, by default the day before the current day is used to generate the baseline values.
• monitor-power: Monitors the current power of a certain location, generating results every-so often, depending on the value entered. Values keep showing up until the user exits out.
• monitor-goal: This takes the current power and compares it to the baseline value generated using the set-baseline method. Compared to the baseline value, this command prints out a number 1-99, which is the percentage of how much energy is being saved. In order for the goal to be met, the current-power must be 5% less than the baseline value.

So having come off with some experience as to how to go about creating commands, we set off to build the next set of commands with another group's code. We split up the commands, so that one person did each command.  Taking dependencies into account, the set-baseline command would have to be completed before the monitor-goal command could be implemented. The monitor-power command, on the other hand, could be implemented without the need for any prerequisites.

It took a while to understand the way that the other group made their code, which was different from the style we chose. For one, their code was admittedly more complex and elaborate than our own, taking into account such things as time difference, manually coding date-validity checkers, among other things.  After a while though, I managed to get the hang of coding in their style, and went on to code my part, which was the set-baseline command.

I came across some problems when coding. One, A lot of JUNIT tests were failing when I was running them.  These were tests written by other members that had been verified to work on other computers, but for some reason I was unable to run them. As such, during the verify process I would be unable to check for bugs in my code, because the process would stop after a JUNIT test did not pass. I was able to temporarily solve this by removing the JUNIT files from the codebase, and then I was able to run my own code and testing.

Another problem I came across was that subversion was not working properly for my computer. When I finished my code, I was unable to commit to the server.  After hours of troubleshooting, I had to send my code to my group members, who got it to commit just fine.

Now during this whole time the group was all occupied with studying for finals, thus finding time to work on this project proved to be quite difficult.  I finished rather late, and as a result, the person who was doing monitor-goal, which is dependent on my code, had a late start to finish their code.  Eventually, we all got our individual pieces into the group build. However, depending on whose computer we ran the code off of, some features would work, while some features would not.  After going at it for hours, and the deadline for the project being less than a day away, we were still unable to figure out why some things would only work part of the time.

Eventually it came to the point where continuing to dedicate time to this project would jeopardize our ability to study and perform well in our other final exams, and thus we had to prematurely cut-off development of the project. The code is added and online, though it needs some tinkering before it can be functional as intended.

Adding code to the project became a real-test to see whether or not this code fulfilled the three prime directives, as evaluated in the previous post. There was sufficient documentation both on the wiki and in the code itself, so adding commands proved to be a doable task, save for the time taken to get acquainted with the code. Overall, I'd say that this code fulfills the directive of being able to be built upon by external users quite well.

This time around, I think our group had a better idea of what needed to be done, but as far as being able to get things done on time, I think we still have some work to do. Granted, final exams were a major factor in our general inability to get things done on time, but in other ways, I think we all are still adjusting to working in a group and being accountable to other members.  This entire project has been a learning process, and I'm sure that all of us are now a lot more familiar with the benefits, as well as the challenges, that come in group work, and with working on other people's code.