Review of GreenSmart 1.0

We are reviewing other groups projects again for our ICS 413 class. I was assigned to review GreenSmart's project. When I first visited their project site, I was very impressed with their home page. It looked very professional with the screen shot of their system, and also a good description of what the project accomplishes. They had good wiki's that explained what needed to be done to run the system as a client or as a developer.

I was not able to break their system as error messages were produced whenever there was bad input or there was no output. The only problem I had with the error message that I didn't like was that it said "Error:" for each error message. I would rather like to have seen something like "Invalid input, please only input integers." or something in the nature that tells the user what is wrong. This is the only negative I found with their program.

Looking at their actual java code, I could not tell that the program was written by more than one person. The code was easy to follow and I found nothing wrong with their documentation. I think that they could have setup two different packages, where one package was the wicket and another package has the wattdepot commands.

My full review can be found here.

Ecologineers 1.0

Imagineer that! We are embarking on a quest to improve the life of the entire world. When I speak of we, I am talking about me and my 3 other ecologineer group mates. We are writing a program that uses the WattDepot system, which I talked about in my previous blogs, to give indications of when there is a high amount of carbon being emmited. This new system uses the Wicket system which allows for html to run complicated java programs almost effortlessly. Using the Wicket platform, we are making a webpage that indicates the amount of carbon being emmited at a certain time of the day.

Learning the Wicket language was very difficult at first. Extending the Webpage and Webapplication classes were very confusing at first, but I slowly got the hang of it. One thing that I still do not understand after working with wicket is exactly what the 'serializable' class does. I hope after I read more up on it later that I will understand the serializable better.

I was very pleased with the way our group worked together. We all got along great and also are able to get things done when needed. The only bad part was that we started working on the project a little late which caused us to spend long nights getting the program up and running by the due date. I am okay with the design of our project. I think that we could have made the program a little more efficient at getting the thresholds, but other than that small kink, I am pleased with our implementation. Some kinks in our program is that we didn't get all of the validations to work and some input causes the program to crash. For example, putting extra 5 digits in the year field will cause the program to crash. We didn't figure out a way to fix that bug yet and will have that bug fixed by version 1.1. We also were not able to get the rows of our table that we generated to output the corresponding colors. Instead we just put a column called 'Intensity' that has a text output of what the row color should be. We should also have that fixed by version 1.1 of our system.

The picture above is our hackystat ICU chart. This chart indicates that we do not have adequate test cases, and also that we have uploaded a lot in a small amount of time. Our coverage report is small, since we didn't test any of our wicket code.

A distribution of our project can be found here.

Revamping to WattDepot 2.0

In this blog, I will talk about upgrading our team's WattDepot User CLI to version 2.0. This was a very tedious task since it required a lot of refactoring of our code. The majority of our groups effort was put into refactoring our code since we implemented an interface and used a Hashmap to call our commands. We made the mistake of finishing all of the commands from 1.0 instead of getting the hashmap to work. This made us take a few more hours than it should of since we just added more code to refactor. There were also a few new commands that was added into the new version of WattDepot. The new commands can be found here. The three new commands were a lot easier to implement now that we were more familiar with the API. Also, the commands were changed from version 1.0, which were easy to fix after we implemented our Hashmap and interface. I am glad that we have finished the assignment and got everything working.

I thought that my group partner and I worked well together. I felt that we each held our own and did the tasks that we assigned for each other. We met regularly about 2-3 times a week in sessions of about 3-6 hours at a time. This gave us plenty of time to work on the assignment.

I believe that our system wasn't the most efficient way to implement the user CLI, but we were able to get the job done. Having the refactor the code created some problems, but we were able to workout the details and get all of the commands up and running. We tried to take care of as many of the issues raised by our reviews of our system. The reviews were very helpful since it gave an outside perspective on our system that we were not able to see ourselves. Our design of the system still has some kinks, especially after we broke up the commands into their own classes. To get all the commands working, we had to extend the UserCommandInterface class since it held some key methods that could only be accessed if we extended the class. This was a design error by us since we were not able to access the client information from the main class since we didn't ever pass it as a parameter. To summarize this, we have each of the classes in the command package having to extend the UserCommandInterface and the UserCommands class. The names are a little confusing since the UserCommands class is the interface and the UserCommandInterface holds the CLI menu methods.

We did not write tests for every class which tells me that we do not have good test cases. This was a pitfall because we did not write test cases at the same time that we were writing code. We tried to write out the test cases at the end of the code for the old commands from version 1.0, but again we ran out of time. We were only able to cover 76% of our class, 63% of our method, 44% of our block and 46% of our line code.

Looking back on the assignment, I feel that the goals of this assignment was to give everyone in the class group experience, which is something that was lacking in previous ICS classes. We were also introduced to some pretty cool tools that helped the group project go along smoothly. Using subversion was a big help since we were just one click away from updating and commiting our changes to the project. The new tools that I was introduced to were Hudson and Hackystat, which were both interesting tools. Hudson was a good tool that helped our group keep our project healthy and not let it stay broken for long. Hudson was a build tool that is very useful since it verifies the system all the time with helps when either me or my partner forgets to verify. Hackystat was another interesting tool which told us all about our code. Here is a printout of our code. This printout told us that we needed to write more test cases to help cover more of our code. Also, since our design of the system was pretty bad, our code is very complex.


What day and time during the month was Oahu energy usage at its highest? How many MW was this?
November 2-6, 9-13, 16-20, and 23-27 all had a usage of 995MW

What day and time during the month was Oahu energy usage at its lowest? How many MW was this?
November 2-6, 9-13, 16-20, 23-27 all had a usage of 493MW

What day during the month did Oahu consume the most energy? How many MWh was this?
dunno how.

What day during the month did Oahu consume the least energy? How many MWh was this?
dunno how.

What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)? How many lbs of carbon were emitted?
4th, 5th, 16th, 17th, and 30th of November. 29,959 pounds of CO2 were emitted.

What day during the month did Oahu emit the least carbon (i.e. the "cleanest" day)? How many lbs of carbon were emitted?
7th and 8th of November. 22,908 pounds of CO2 were emitted.

Our distribution file can be found here.

Giving and Taking Criticism

Doing peer reviews of other people's implementations of the User Command Interface for the Wattdepot project was very interesting. Both projects that I reviewed had implemented their systems very differently. Both groups split their programs up, but one group implemented their program using an interface, while the other group implemented their program by extending their classes from the main class. Anther interesting aspect of the two implementations was the fact that one group hadn't used any methods in their different classes, but just used System.out.println() within a constructor. I guess I am saying that it took some time getting used to each group's coding style before I was able to review each group. One of the most important things that I have learned from looking at other people's code is the importance of Javadoc comments. I was able to easily read through the code that had good documentation of what was going on.

It was interesting reading other peoples review of our system. The 5 reviewers of our system had similar critiques of our system. Basically each of the reviewers talked about our lack of test cases and having too many methods within one class. These are very true comments and I agree with their review. While working on the project I made the stupid mistake of trying to write in all the test cases for my code after finishing my code. I also need to organize my code better and not put everything into one class. Something I learned that helped a lot when looking at reviews of our system, was when reviewers would write in exactly what command they inputted that failed to work while they were testing our code.

The most helpful reviews were the reviews which contained constructive criticism. Most of the reviewers review of our system were constructive with the exception of one. While reading the reviews, one comment about my group's projects was that we have written our code in "spaghetti code." This is a very harsh comment that did nothing to help our group improve our system since the comment ended there. This reviewer did not specify what parts of our code was "spaghetti code." Writing comments without giving evidence just confused me because I didn't what what exactly made our groups code hard to read. Besides having one long file, I thought that our groups code was easy to follow.

Reviewing other people's WattDepot-Cli

This week for ics 413, we get to review other people's implementations of their User Command Interfaces. Each member of the class was assigned to review two other group's projects, not including their own of course. We were also assigned to base our reviews on the criteria given by our professor. A copy of that review sheet can be found here. I was assigned to review two groups: Umikumakahi and Umikumalua.


Umikumakahi
Umikumakahi's system was very tricky to review, since I was not able run their system in my command prompt or in the Eclipse IDE. I was not able to test whether commands worked or not therefore my review was based more on their javadocs and their design of the system. My full review can be found here.

Umikumalua
Umikumalua's system worked well, but had many issues where bad input would crash the program. Also, commands were case sensitive which cause me problems when trying to test out the commands on the system. For example, 'list sources' would work where 'LIST SOURCES' would not be recognized. There were also a few commands that were not implemented which need to be before their next version comes out. My full review can be found here.

Creating a WattDepot CLI

For my ICS 413 class, we are writing code for the WattDepot-Cli program. WattDepot is a new program that helps people regulate accurate power usage of power plants and homes throughout the island. More information can be found about the WattDepot program here.

In class, we were paired up with another person in our class to create a CLI(Command Line Interface) for the WattDepot program. I was paired up with Shaun Ramento. This assignment was very hard to start off. It took a long time just learning the API of the WattDepot. Just getting simple functions like client.getSource() was troublesome, since the Source class also had many other methods nested in it. After learning the basics of the API, we had to figure out how we were going to implement the CLI(Command Line Interface). We decided to create a new class, that would hold all of our methods in it, and also figure out what commands the user is inputting. The 10 commands that we needed to implement can be found here.

After getting the two simple commands, 'help' and 'quit' done, we started working on the next set of commands. We decided to split up the work on commands 2.3 and 2.4 so we would be able to help each other get used to the API. We then split up the work by the type of commands we will need to access. I took commands that dealt with sensordata and shaun took the commands that dealt with power. Finally, we split up the last two sections of the assignment where I took section 2.9 and Shaun took section 2.10.

After getting about half way through the assignment, our professor told the class that he did not like the way that a certain group was deigning their code. This group had all their methods setup in one java class file. Our professor told the class that these people need to rewrite their code by splitting up their methods and to use an interface. This was a problem, because my partner and I had decided early on to do the commands the same way that he lectured about, which meant that we also needed to change the design of our implementation of the project. Also, the group wrote their code using a lot of System.out.println() which we also did. Rewriting the code to not have these System.out.println() statements caused much time to be wasted since we had to rewrite a good portion of our code to fulfill the standards of the program.

We made a mistake by not writing junit tests while we writing our java code which caused a lot of time to be wasted since we would write code, run the program, then enter code to see if it works properly. This was a huge mistake. Too much time was wasted in this process. We ended up writing our junit tests late, which caused us to waste more time since we had to look over our code to remember what we had to test.

After finding out that we needed to change the design of our project, we decided to finish all of our methods then work on moving the methods around. Unfortunately, we were not able to setup our project in the way that our professor wanted us to, since we had problems finishing the rest of the methods by the Wednesday deadline. So we did not move the methods into their own separate classes and implement an interface. I wish I had more time to understand this interface and creating separate classes. I will most likely look at how other people have implemented this portion of the assignment, since it seems like it is very useful and essential to learn writing code in table-based dispatching form.

Here is the distribution to team eha file.

Continuous integration and Hudson

For my ics 413 class we were just introduced to continuous integration. We were introduced to this topic because we are going to be working in groups on this upcoming assignment. In groups projects, big changes to software can lead to problems since those changes may not be compatible with other group members code. Continuous integration is an idea where programmers of software projects make small changes to projects then committing those small changes. The continuous integration environment that my 413 class is using will be Hudson.

Hudson is a system that helps software development by continually building and testing projects. Hudson will monitor my groups SVN repository by building and testing new project updates. Anytime a group member commits something new to the SVN repository, Hudson builds and verifies the project. If any build or test fails, an email would be sent out to everyone working on the project saying that the project failed to build. Anytime there is a failed build, it should be immediately fixed. The Hudson system is very useful since it verifies a project just in case one of the group members forgot to.

Hudson was very simple to setup and use since most of the instructions were given to us in a webcast. If I were to do it on my own, I think that it wouldn't be too hard since there are instructions all over the internet. The only problem that I had while setting up Hudson for my group was that I didn't set the automatic build field, so Hudson looked for a file in a folder that didn't exist, so the build kept failing. Other than that user error, everything else in the setup was straightforward.