Improvement

            Few weeks ago my team (Pichu) had the chance to cooperate together to create an command prompt application that allows users to retrieve energy data from the Hale Aloha dorms; more information can be found about the previous project at this site Pichu. Then later on we had a chance to review another team’s application, which allowed us to learn how other people implemented and what other ways to implement the same application. More information about the team’s project that we reviewed is available here Teams.

            For this particular project we had to modify the application that we reviewed previously by adding the following three features.

·         set-baseline – sets the base energy consumption in a 24 hour period for each hour

·         monitor-power – monitors the source’s current power consumption

·         monitor-goal – monitors the power consumption to see if it met its base goal (set
                         in set-baseline)

These three features improves the existing application by modifying it into one that allows user to see actions instead of just typing in command and have the application return an message related to the command. For instance, the monitor-power command allows user to monitor the current power by having data printed in an interval (in seconds) supplied by the user. Another command that does actions is the monitor-goal, which also prints out messages to indicate if the source met its power goal base on the baseline; the baseline command sets the date to retrieve energy consumption for each hour in a 24 hour period.

            The most challenging about this time’s cooperation with my team was not communication. We were able to correct the problem this time by having more communication of checking on progress of the group and meeting at our free time. The main problem was trying to understand the code since style was different, and adhering to the original while coding the additional features. One of the rules is in software engineering is to adhere to the original when we pick up a project from the original author(s). Adhering to the original is not only about implementing the code to behave like the original; it also involves implementing the methods that would return the same type of output.

            I happen to implement the feature call set-baseline; my original idea was to return an array of 24 values of the energy consumed. However, the other classes that represented the original features returned an output of type String. Therefore, I had to adhere to the original by returning a String made up of the 24 values and split it into an array of type double in the class that processes the command (Processor).

            Besides same type of output, the other thing is the variable names. Since we want to keep it consistent with the original we had to name the variables as close to the original and make sure it is meaningful. As stated from “Elements of Java Style”, we have to use meaningful names for variables, methods and so forth.

           

            Through the course of adding the features to the application we encounter problem with both monitor-power and monitor-goal. The feature was to have the data print out continuously with each line of data being print out after certain interval (in seconds) and it quits when user presses the “Enter” button. We did try implementing to have it quit with any button but we weren’t successful. Initially the application would print out data for monitor-power and monitor-goal after we pressed “Enter”. In the end we were able to have it print out data base on the interval entered by the user.

Overall, this time the cooperation with my team has improved over these few weeks (since the very start when Team Pichu established). As mentioned before, this time we were able to meet at our own time instead of just contacting by email, phone, or Skype. Meeting up not only let us check on each other’s progress but also helped out with implementing the code. During the meeting one of my team members kept having trouble with PMD and FindBugs errors so we worked on what could be the issue. Although it took a little while, but it was worth it because team members should help each other out; helping each other is another factor in a successful team. We also checked on the progress of the team to ensure that we were meeting the deadline of each issue (decided by the team). This project not only allowed the team to learn from our communication mistakes, but also how we organize the issues at hand (e.g. who would implement which feature).

Teams Performance

For these past few weeks I was in a group implementing a console base program to retrieve data from the Hale Aloha dorms at UH. It was a great experience working in a group because not only have I learned new skills in Java coding, but also learned to communicate with people; more information can be found at this post Pichu.

This time my group members and I have a chance to review another group’s project which behaves same as ours when user inputs a command and parameters, but differently in error handling. The project we had to review had a simple name of just “teams”. Their program had the following features:

·   Current power – retrieves the current power consumption of a tower

·   Daily energy – retrieves energy consumption of a tower from a particular day

·   Energy since – retrieves energy consumption from a range of days (e.g. 2011-11-23 to

    2011-11-25)

·   Rank towers – ranks each tower’s energy consumption from least to greatest and display data in a list

Before I get into talking about the features and defects about this project I would like to talked about where my group members and I obtained the project from. This project was obtained from this website, http://code.google.com/p/hale-aloha-cli-teams/, on the first click I of the link I was redirected to their introduction page and first thing I see is a brief explanation of what the program is and the features, mentioned earlier, being supported. It was simple enough to understand what the program does, but it would be an enhancement to show an image of how the program would look like after the user installs it and uses it. Otherwise their Wiki pages are very well written that I can follow the steps of how to install the program and run the program, which is to just download it and then invoke java –jar hale-aloha-cli-teams.jar.

            Feature wise it is pretty well featured with the commands in this current version of the program. The help feature was pretty useful to give descriptions of what each command does and what input it accepts to retrieve information from the server. During testing I did had parts where I forgot what a certain command accepts for input, with the help feature I was able to accomplish it in no time. The messages returned for each command after the data has been retrieved were pretty informative. For example, one of the commands I entered is as follows: current-power Mokihana and it returned the following message “Mokihana’s power as of 2011-11-30 6:52:40 was 31.1 kW. The message is not too long, but simple and straight to the point of what I should expect when I invoked the command. Here’s a picture of what messages are printed for the other commands.

           

 Although, the features and data messages are good and informative, but the error messages being returned isn’t as informative as I (or my group members) expected. For example, I deliberately typed in the following: daily-energy Mokihana 2012-11-23 and the error message returned was “For input string: “Error: An error occurred in the XML from the server”. At least the error was caught and a message is shown, but it doesn’t relate to what the error really is. What if an user haven’t heard of what XML is, then this message would be confusing to that particular user. It would be better to have the message indicate the date is too far in the future or something. Practically, the same message was printed out for incorrect date entry for other commands as well. However, it does show this team was trying to be consistent with the error messages for the same type of input error.

Reviewing a program by just installing and executing it alone is not enough to tell if the code is well written. Another part in reviewing a program is to actually view the source code(s). Before I get to review this team’s code, the initial part is to read up their Javadocs. I was able to build the Javadocs by using the ant –f javadoc.build.xml. This will create a directory call javadoc (located in the build directory) which contains all of the html files that we can access to view the Javadocs of this project. Their Javadocs are pretty consistent with the method names. In the methods that retrieve data for each command they have their method name as getData follow by a description of what it does base on the command. They did follow the rule to comment their comments so we know what they are doing.

After reviewing their Javadocs it’s time to talk about their source code. Their code did follow the rules in Elements of Java Style such as commenting their code, use of verbs to name a method that does some kind of action and many more. Although, their code did pass the test of CheckStyle, PMD, and FindBugs, but there are some parts that aren’t errors but more associated with bad style. In their method call help() they were printing the messages with System.out.println() and some had the .println part skipped to a new line (see snippet of code below)

They could’ve completed the System.out.println() and then concatenate at certain parts of the string to meet the requirement of no more than 100 characters per line. Also, in the class call ManualTestProcessor there were some redundant comments. The parts of code is already described of what it does with the System.out.println() line of code. An example would be as follows

   To conclude, this project did meet the requirements of the Three Prime Directives which is the system accomplishes a useful task, user successfully installs the system, and external developer is able to understand and enhance the system. Due to the well commented code it was easy to understand what each class performs. Besides some bad styles and some message problems from invalid input, this program does what it is suppose to do. If it has a chance to become a real software product this would be a successful and easy to use product to let user monitor their energy consumption.