Eco-Depot Code Review

We are once again tasked with doing a code review. Each time we do this, we are hoping that it gets easier. This time we are reviewing a web application based on our Wattdepot clients. We will be using it in conjunction with wicket to develope page that users can use to determine when we can defer electrical usage.

Today I will be reviewing the Eco-Depot system.

My review can be found here.

The eco-depot system fulfills most of the basic requirements of the system. The quality of the code is good and is designed properly. The only part of the system that requires improvement is the testing and overall group process. Some members are doing a vastly greater amount of work than others. Suggesting that the project issue manager should be used to delegate tasks properly.

Wicket Good: Web App Development Using Wicket

No longer are we working in small pairs, but now we are a quartet of different people with different abilities. Will having a larger group with more responsibilities hinder our progress or will it be smooth sailing with that much knowledge on board. With our combined knowledge we are Greenometer!

After completing our Wattdepot clients last week, our group was paired up with another group forming our quartet and were assigned to create a web application that displays a table of carbon emissions for an requeste

d day. The table has a color code that will tell the user the carbon intensity of the grid at that hour to help them decide how to better manage their electrical usage.

One of the first things we did have was two group members clearly taking charge. Having a project manager to keep the work delegated and in track was very useful. Each part of the overall project was able to be laid out and each member was assigned a task base on their ability.

Those with more understanding of how to build a Wicket application did most of the development of the web app. While those who were more unfam

iliar were assigned to doing more menial tasks like gathering test data and documentation while looking at the development of the application to get a good understanding of wicket.

With one of our more knowledgeable members, Kelvin Green, we took an ambitious route and did more than the basic specifications. We took it up a level to add a better visual representation of the sampled data to give users a graphical layout of the data rather than a simple table format. One downside to this layout was that it is difficult to users to view the actual numbers from the sampled data.

Overall I believed we worked well together. Members were there to keep each other in check, and although we had varying schedules and were unable to meet face to face, the quick relay through email and online instant messaging was an acceptable substitute.

Here is a view of our HackyStats ICU data.

Many of the ares are pretty good. I would say it is an overall healthy system. We had a mild start with some development time and builds, but it really got going over the weekend which is expected for students.

Big Brother is Watching: WattDepot v2 & Software ICU

In this assignment we were tasked with writing the commands of a command line interface for the WattDepot client. We were paired up with a partner and given our first real software engineering task.

In the second version of this assignment, three new command specifications were added to an updated WattDepot client and we were again working with our partner. The only difference this time was that we were being watched. Using hackystat, our project branch's health was continually being monitored for commits, coverage, work by each member, etc.

This pushed everyone a step further since you couldn't slack off and complete the assignment the night before it was due anymore. But it was also a very useful tool for monitoring your progress throughout the assignment. I had found myself

going to the hackystat project browser to check on our statistics every now and then to see the improvement.

What started off as a minimally functioning system, we designed into a well organized implementation that addressed much of the issue if not the only issues for our previous designs from the reviews. We separated methods that w

ere stored in one class and added many test cases to raise our coverage of the system. We had been lacking any test cases from our initial implementation and have now raise it to around 62% line coverage at around 80% class coverage. Though we chose to have a well designed system with good coverage over completing the three new command specifications. We were only able to complete two out of the three.

I believe this time around the group dynamic was a lot better. We had much more communication between each other, and I believe although we did not finish, we accomplished more than our initial implementation. We were not able to meet regularly, but through online contact we were able to discussion implementation and delegate tasks efficiently.

Here are some comparisons of our progress using the ICU.

Before

After

It could use a bit more work, but there is a huge improvement. Overall I believe it is a pretty healthy project with commits from both sides and improving coverage.

Using our project, we are required to answer the follow questions. We will be doing 4 out of 6 questions because we were unable to complete the last command.

Here are the questions we will be answering:

1. What day and time during the month was Oahu energy usage at its highest? How many MW was this?

2. What day and time during the month was Oahu energy usage at its lowest? How many MW was this?

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

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

Answers: To be completed when I figure it out, math and problem solving aren't my strong point.

And The Results Are In: Wattdepot Review

I just finished reading the reviews of my groups Wattdepot project and I have to say I am pleasantly surprised. They were mostly all positive. One the exception of course of our group not having any real test cases so that was one thing that everyone commented on.

I believe that the better your system is the easier it is and yet the harder it is the review. When I looked at the reviews for my group's system, many of them were a short and precise: This system works, the described checklist item works and is in order. But from my experience when it is good, it is harder to break or find something for the group to improve on.

One of the strategies I tried during the review, since we had to review two systems, was first trying to break the system and then reviewing the code. After that I tried reviewing the code first and then trying to break the system. I found the latter a lot after and easier to do. The reason being is that when you review the code, you can see which of the specifications were not implemented, and immediately you can see problems. I was able to see which exceptions were not caught and immediate knew how I could break the system. It is a lot faster than trying to think up of ways and then testing all possibilities on how I can break a system.

All in all, I believe that taking different approaches that work well next time can speed up the reviewing process, I found it not so bad and gave me a lot of insight into potential problems and even fixes and ideas on how to improve me own project.

Your code has good Feng Shui: WattDepot Code Reviews

All these parentheses and semicolons really ruin the feng shui of the code!

Although it can often be a very good thing, a lot of programmers hate to do code reviews. So this week we get a hard learned lesson is code reviews.

I have been tasked to review two other groups WattDepot project mentioned in our previous blogs. Watch as I tear it up.

The reviews for these two groups were assessed based on the checklist found here.

To read my full review of the code refer to the links below:

Eolu (eono)

Ehiku

Summary:

Eolu

Not all the commands were completed. Overall the design could use work, the methods can be split into there respective classes and the javadocs require updating. Comments need to also be added to many methods, it is inconsistent.

Ehiku

All but the chart command is completed and functioning. The design for the system is very good, all methods are separated into their own class. Commenting and naming conventions need to be more consistent across the different programmers. Overall well programmed.

Ten Specifications Down for Team UMI: WattDepotCli

So we have just completed our first team project and everyone could use some sleep. It is three in the morning and only four out of the ten teams have submitted their projects as of yet.

At the beginning of the project, I believed that it would not have been so bad. Working with partners has proven to be an effective was of learning and increasing productivity. So I'll share some of the experiences I had with my partner.

Unfortunately for us, my partner and I were unable to meet everyday since we both has busy schedules. Unfortunately again that this project be over the Halloween weekend where everyone likes to party away. With my schedule being so full, I was hoping to try finishing up small easy parts during my spare time. Though that didn't work out as well as I had planned.

Luckily for me, my partner is quite the diligent worker and before I could really step in a do much work, most of the project was already complete. I was left to review some code and add in a part of the remaining Cli. I do wish I could have helped more though, but the delegation of tasks were not as clear with each person working on something and then moving on to the next one that is not yet taken.

With proper delegation of tasks I believe that the project could have flowed smoother, but differences in schedule and does not often allow for that. Even with many people with a single goal, I learned that it takes a lot of communication between these people to get the job done. It wasn't until we sat down and talking about the task as hand were we able to really get it flowing.

Integration With Hudson

For the rest of the semester we will be grouping together with a partner or other people. We've already touched upon using a version management system such as SVN to allow us to have a centrally distributed build. So now that we are working with partners it's a good time as ever to get into the practice of using this newly found knowledge.

Last week, we were introduced to Hudson which allows us to automatically run repeated jobs and auto build/test our systems. This automated process is connected to our google repository. This is a very useful tool for us to use now that we are working with a partner/s. When one of us breaks and build on uploads a new build it will automatically test it and send out a report by email to us.

Most of the setup was done by my partner but from what I could tell, the Hudson system was very quick and easy to set up. It only took a few minutes to get our program up online and have it start building. I'm sure it will continue to become a very useful tool throughout the rest of the semester and probably our future career.