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.

Technical Review of hale-aloha-cli-jcev

Continuing on our group project work from my last blog post, we have now moved into the technical review stage, which is looking over written code and evaluating it to determine it's strengths and weaknesses.  We will be doing this, however, with code written by another group, team-jcev. The functionality of their software is the same as the one my group came up with, but they chose to take a different approach in order to get to that functionality.  For the purpose of this evaluation, we will be using a standard called "The Three Prime Directives", as used in my first post. Basically, these are three things that a program or system must accomplish in order to be considered "good" or "usable".

1. The system successfully accomplishes a useful task

We will define 'useful task' as being able to successfully deploy all required functionality of the system as specified in the class assignment page. The following is an evaluation of the functionality provided in the group's code:

    current-power: returns current-power in kW of location

        -runs as intended, throws error if input is wrong

    daily-energy: returns power in KW used at location for specified date

        -runs as intended for valid dates

    energy-since: returns power in KW used at location during specified interval

        -runs as intended for valid dates

    rank-towers: returns energy-usage of towers from lowest to highest during the specified time interval

        -had problems running certain dates that should have been valid. for example, entering in (2011-11-27 2011-11-28) yields a message that says "dates overlap or are beyond current date", even though these should be valid dates. Worked for dates in December.
    help: shows list of available commands

        -runs as intended

    quit: exits program

        -runs as intended

As detailed on the assignment page, this code exhibits most of the required functionality, with the only one I was unable to run being the 'rank-towers' command. Upon testing, some issues came up with regards to input.

-The names of the locations were case-sensitive. If the user entered in the correct name but forgot upper-case, the function would not run

-In the case of out-of-bound dates, the program displays all of the error code, which probably shouldn't be seen by the user.

-Although this is more due to uncontrollable issues, functions that include dates that were within the period of server down-time last week did not return proper results.

Overall, while one of the functions did not seem to work on my computer, the rest was able to run rather well. The program was able to relay important information about energy usage in the freshman towers to the user, so I'd say that it fulfills the first directive of serving a useful purpose, although there are improvements that could be made for it to better fulfill this directive.

Directive 2: An external user can successfully install and run the system

In order to evaluate the system in regards to this directive, we will be looking at the site for the project, which can be found here. Within the project-site lies the wiki, which contains two articles, one for users, and one for developers. Within the user guide, there are explicit instructions for installing and running the program on a user's computer.  Sample input is also provided for the setup process, more specifically the command needed to launch the program from command prompt.

In the 'downloads' section of the project site, there contains a zip file containing the source code, which also includes an executable jar file for running in the command prompt. Version number is included for user reference. Also included in addition to the group's own code is an executable wattdepot .jar file for user and developer usage.

Since I was able to successfully download and run the program on my computer, I'd say that the instructions given in the wiki were useful. The following is a list of input to the program and their respective output:

>current-power lehua

Error: Source "lehua" does not exist.

>current-power Lehua

Lehua's power as of 2011-12-02 23:37:7 was 33.81kW

>currentpower Lehua

Error: "currentpower" is an invalid command! Try "help" for a list of valid commands.

>help

(shows help commands)

>daily-energy Ilima 2011-11-27

Lehua's energy consumption for 2011-11-27 was: 582.7kWh.

>daily-energy Ilima 2012-11-27

400: Range extends beyond sensor data,...

>energy-since 2011-11-27

Bad input: Less than 2 arguments.

Correct syntax: energy-since [tower | lounge] [date]

>energy-since Mokihana 2011-12-27

Bad input: Date 2011-12-27 exceeds the current date.

>energy-since Mokihana 2011-11-27

2011-11-27 00:00:00 to 2011-12-02 23:38:07 is: 3789.84 kWh

>rank-towers 2011-11-27 2011-11-28

Bad input: dates 2011-11-27 2011-11-28 overlap or are beyond the current date.

>rank-towers 2011-11-27 2011-12-01

For the interval of 2011-11-27 to 2011-12-01,energy consumption by tower was:

Mokihana 3140 kWh

Ilima 3170 kWh

Lehua 3179 kWh

Lokelani 3700 kWh

>quit

Quitting...

The program seems to have all of the basic functionality required, with the only functions I had issues with being daily-energy and rank-towers. There also seems to be a rather robust system of input error checks, and shows a consideration for a variety of possible user mistakes. However, there are spots here and there that could use fixing, like the error message for out-of-bound dates, acceptance of non-case-sensitive locations, and the fixing of the rank-towers method for valid dates. Despite these issues, I'd say that the program fulfills the second directive of an external user being able to successfully install and run the program.

Directive 3: An external developer can successfully understand and enhance the system

For this directive, we will look at the developer wiki on the project site. There seem to be detailed instructions for every step of the way from installing ant, an automated build system that is necessary to run the project build, to detailing the coding standards, to outlining the development process. As far as modifications and additions to the code goes, the way of doing so seems to be clearly laid out. The approach that the group has been using is issue-driven project development, which entails splitting up the project into individual problems, or issues, which are then worked on until they are fixed.  A new issue is to be created for each new addition to the code, and set to "fixed" when it is good enough for addition to the code. JUnit tests must also accompany each new addition as well. A link to the Continuous Integration server is also provided, which serves the purpose of compiling uploaded code and returning an error message if the code fails to compile. 

Also, instructions for compiling javadocs, or the documentation of the code that can be compiled from the comments within the code itself, are also provided.

Upon compiling of the javadocs for the group's code, all parts of the code seems to be documented, and they give useful information as to the inner workings of the program. Since the commands are fairly segregated from the rest of the code in other sections of the program, information hiding seems to be implemented effectively in the system.

Building the system using ant resulted in no errors, and took around a minute or so. It was clear how many JUnit tests there were during compiling. Looking through the JUnit test files, it seems there are many tests in place to test many different aspects of the different commands.

Looking through the source code, there is ample explanation regarding the workings of the code, and instructions on modification and augmentation to the code itself. comments seem to be present when necessary.

Back on the issues page, it is clear which member of the group worked on which part of the project, and if a problem stemmed from a certain area, it would be apparent who worked on it, based on the information from the issue page.

The CI page for the project, which shows the success or failure of the commits for the project, showed that the project was regularly worked on, save for the Nov.22-24 server outage.  When faulty builds were uploaded, they were swiftly resolved, based on the times of the commits.  It looks like most of the updates were based around particular issues that needed addressing.

Although for a new user, getting accustomed to using all of the tools would take some getting used to, there seems to be adequate explanation and walk-through present on the project site of this project, as well as within the code itself. Overall, I'd say that an external user could very well adapt and add-on parts to the system. Thus this system fulfills the third prime directive.