Friday, December 18, 2009

Greensmart v2.1

Our project, named Greensmart, is a webapp which displays simulated data of the electrical grid of Oahu, Hawaii. It provides a user useful information in a way that is easy to digest and gain something useful. We have two pages which give different data to the user: a stoplight page and a grid info page. The stoplight page presents the user with a stoplight with either the red, yellow, or green light lit up. This represents the current level of carbon emissions. The user is given an explanation of the data presented and a recommendation if it is a good time to be using energy. The grid info page is a page where the user can enter in data to get the information that they want displayed in a google chart. The user can choose from a source and the start and end date.

There were two big things that I gained from this project. The first one is working in a group. I had only once before worked in a group for programming. The methods that we used in class like Hudson and HackyStat were very helpful in giving me a taste of what I can expect a professional setting to use. The second thing I learned was about the user interface and creating an interface that would be user friendly. There was a big emphasis placed on making the webapp as user friendly as possible and I learned a lot about what things we can do or avoid to achieve that goal.

Thursday, December 17, 2009

Software Engineering

This semester I took ICS 413, Software Engineering. This was the hardest, but most rewarding ICS class I have taken. I learned much more about software engineering than I thought I would. I really feel like I am coming out of this class as a much better software engineer. We implemented many things that are used in the professional setting. Now that I have some experience using some of the tools, I feel more confident.

The best part about this class was working in groups. It was a very valuable experience that I haven’t gotten in my other ICS courses. Learning to work in a group, I think, is something that is very important to learn before to get out into the professional space. There are many things that I learned about working with other people and what you need to do as an individual and as a group to be successful.

This course also was set up in a way that was different than the other ICS courses I have taken in the past. The lectures were placed online and the time in class was used to work on our assignments. I felt that this was very effective and I wish that more courses would implement this same style of teaching. The hardest thing is the self-discipline to watch the videos online. Since the videos were necessary for the next class, if you don’t watch the video, you’re not going to be able to utilize the time in class productively.

Tuesday, November 24, 2009

Eco-Depot code review

I was tasked with reviewing Eco-Depot, A web application to provide information on the energy use of the Oahu power grid. It was able to fulfill the requirements of the project, and at the same time creating a useful site for someone looking to use energy while it is at its cleanest. The design and implementation of the system were very good. It was easy to follow and understand. Based off the Software ICU, the group seemed to be working very well together, but there was one member whose data was not being updated into the ICU. The code review can be downloaded below.

Download here

Monday, November 23, 2009

Team Greensmart

My group, team name greensmart, implemented a system to let users see the current carbon emissions on the island of Oahu. Using this information, users will be able to decide when the right time is to use their heavy electicity using electronics. When the webapp says the carbon emission is low, it is the time when the energy is the "cleanest"

I think that this first stage of the project went well. There was a lot of getting used to since this was our group's first introduction to Wicket. But from reading "Wicket in Action" and looking at the example programs provided, I was able to gain a better understanding on how to use Wicket. We were able to share our experiences and tips with each other.

We designed our system the way that the Cheesr system was designed. We utilized sessions and a base page which make make it easier to include more pages down the line. Using this method, our system is easily expandable.

I feel that our group worked very well together. We were able meet on 3 separate occasions which really helped in keeping ourselves on the right track and helping each other if we got stuck. We split up the tasks between us and worked on the system both on our own and as a group. The following is a screenshot of our Software ICU.

Monday, November 16, 2009

Wattdepot-cli-elima Version 2

The goals of this assignment are to improve upon the previous implementation of the Wattdepot command line interface client while also adding some new functionality. We added 3 new functions on top of the commands already available in the previous 1.* verion.

Our 2.* version of the software satisfies most of the requirements of the assignment. We fixed most of the issues that the reviewers brought up during the code review process. Our system utilizes the interface-based design pattern which makes it very easy to add new commands to the current system. We have JUNit tests that test the basics of each of the commands. The coverage from the results of emma are below:

[concat] Emma coverage summary
[concat] class: 92% (24/26)
[concat] method: 90% (52/58)
[concat] block: 60% (1677/2812)
[concat] line: 57% (338.8/591)

Me and my partner, John Mack, communicated regularly to see the status of each others developments. We were able to seperate the work equally so taht we could each work on the system as much as we could. We both contirbuted equally to our implementation of the Wattdepot-cli command line system.

During this version of the system, we implemented a ICU with a Hackystat server. We had trouble with making it work correctly. My data was not displayed in the project, but rather in the default area. A screen shot of our software ICU is below:





With the data that is available, it is easy to see that most of the development time was later in the cycle.

We were also tasked with answering some questions to utilize the commands we had written. They are as follows:

1. What day and time during the month was Oahu energy usage at its highest? How many MW was this?
The following days had the same max amount of energy usage: November 2, 3, 4, 5, 6, 9, 10, 11, 12, and 13 at 8:00pm. 9.95E8.
2. What day and time during the month was Oahu energy usage at its lowest? How many MW was this?
The following days had the same minimum amount of energy usage: November 2, 3, 4, 5, 6, 9, 10, 11, 12, and 13 at 4:00am. 4.93E8.
3. What day during the month did Oahu consume the most energy? How many MWh was this?
The following days had the same max amount of energy consumed: November 2, 3, 4, 5, 6, 9, 10, 11, 12, and 13. 1.475569888888889E10.
4. What day during the month did Oahu consume the least energy? How many MWh was this?
The following days had the same minimum amount of energy consumed: November 1, 7, 8, 14, and 15. 1.408044888888889E10.
5. What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)? How many lbs of carbon were emitted?
The following days had the same max amount of energy consumed: November 4, 5, and 13. 2.9942736666666664E7.
6. What day during the month did Oahu emit the least carbon (i.e. the "cleanest" day)? How many lbs of carbon were emitted? The following days had the same max amount of energy consumed: November 7 and 8. 2.2895116928888887E7.
We got these answers from writing a program to run the respective commands for each of the days.

Monday, November 9, 2009

WattDepot Code Review

Code review is an important aspect of code design and the review process. It is very effective in finding problems with the code that automated tools wouldn't be able to find. Developers also gain a lot of knowledge in seeing other peoples implementations and having their own work critiqued. We each had 2 branches of the command line interfaces for WattDepot to review. I reviewed the Ehiku and Ewalu branches of the WattDepot.

Ehiku branch:
The branch wasn't separated into a command and processor subpackage. This branch had all of the commands working except for the chart command. It wouldn't save to the specified filename and the result file wasn't a html file. There weren't any test cases. Overall a very good job.
Download Here

Ewalu branch:
Again, this branch wasn't separated into a command and processor subpackage. This branch had all of the commands working. All of the commands were located in a single class, Command.java. The test cases were mostly happy path tests. This team also did a very good job.
Download Here

Wednesday, November 4, 2009

WattDepot Command Line Interface

We wrote a client to provide a command line interface to WattDepot. WattDepot gathers eleectrical data from different meters. Using the API, we were able to access the information and use it to give a user meaningful data on the energy use of different power plants in Hawaii.

I worked with John Mack to implement the command line interface for WattDepot. We were able to integrate the interface-based design pattern, which at first was more difficult to do, the benefits were evident later on. We were not able to implement the list source summary and we dont have data integrity checks or tests.

One of the biggest problems with working with another programmer on a project is the sharing of code. Luckily, SVN provided us with a solution that helped to lessen the hassle of collaboration. Working with a partner sometimes makes it difficult to do as you would like, for fear that you may confuse your partner. Most times when you make a change you need to explain to your partner what you did so that they can understand and utilize the changes that you made. We broke up the work by just working on our own things until we got stuck. Then we would work together to solve the problem before moving on.