Tuesday, November 24, 2009
Peer Review: Take 2!
With the recent project that we're been working on, we have been doing a peer review after the completion of version 1. So now, after completing version 1 of our OscarWebApp "greenometer", we are once again task to review another group's project. As for me, I was task to review the Ecologineer project. Please click on the link to see my full report.
Monday, November 23, 2009
Wicket + Wattdepot = Green web
This week, we were introduced to a java web application framework called Wicket. We were task to use wicket and our wattdepot project to create a web page that shows and classifies the carbon intensity for a given day(24 hours), similar to the Ecotricity UK Grid Live website. The goal of this task was to introduce us to the simple web application development using wicket, to further our experience with the use of Software ICU, and gain experience with using Google Issue system.
At first, Wicket seems really complicated considering that I wasn't that experienced with HTML and was a bit rusty in java. But after reading the first few chapters of Wicket in Action and doing some of the examples in the book, It started to look less complicated.
As we start this project, communication was a bit of a problem. I guess it was a bit hard to get 4 people together with different time availabilities. So most of our communicating was thru email, google chat, and AIM. Kelvin, one of our team member took charge and design the ground work of the project while everyone help to edit and improve it. We didnt really use the google issue system because with only 4 members, it was easier to just send email or instants messages to keep everyone updated but i think we should begin to use it so we can get use to it for larger projects with more members. For improvements, we could have a better communication methods and distribution of task. But we manage to accomplish all the given tasks.
To get a copy of the our greenometer, Just click on the link and select either the Zip file or Jar file to download. You can follow the User Guide to install the program and get it running.
Below is a screenshot of the Software ICU data for the last 7 days...
At first, Wicket seems really complicated considering that I wasn't that experienced with HTML and was a bit rusty in java. But after reading the first few chapters of Wicket in Action and doing some of the examples in the book, It started to look less complicated.
As we start this project, communication was a bit of a problem. I guess it was a bit hard to get 4 people together with different time availabilities. So most of our communicating was thru email, google chat, and AIM. Kelvin, one of our team member took charge and design the ground work of the project while everyone help to edit and improve it. We didnt really use the google issue system because with only 4 members, it was easier to just send email or instants messages to keep everyone updated but i think we should begin to use it so we can get use to it for larger projects with more members. For improvements, we could have a better communication methods and distribution of task. But we manage to accomplish all the given tasks.
To get a copy of the our greenometer, Just click on the link and select either the Zip file or Jar file to download. You can follow the User Guide to install the program and get it running.
Below is a screenshot of the Software ICU data for the last 7 days...
Monday, November 16, 2009
Wattdepot-CLI take 2
This week, we were given a second chance to fix whatever bugs we have with my Wattdepot-cli project in addition of adding 3 new commands to our existing project. This was a great opportunity for us to used what we've learned from the peer review last week and apply it to our project. I think the our project satisfies all the requirements given in Command Specification page.
As for fixing all the problems that was raised by our reviewers, we did not fix the console bug in using eclipse but we will inform the reviewers that I must be ran in the command prompt. This week, we focused more on designing higher quality test cases and overall improvement of the design.
As a result, posted below is our emma coverage report:
[concat] Emma Coverage summary
[concat] class: 100% (27/27)
[concat] method: 96% (74/77)
[concat] block: 86% (3538/4098)
[concat] line: 78% (668.4/860)
We communicate with each other mainly through email and instant messaging with the occasional meetings before and during class. We tried our best to distribute the work load evenly, but my lack of java programming has made my partner carry more of the wieght.
To help us monitor our work progress, we have installed the SoftwareICU which is a tool to help monitor our progress. It also display infomation on coverage, complexity, coupling, churn, and more. posted below is a screenshot of our last 7-day
In testing to see if our commands are working properly, we were tasked to answer a few question:
What day and time during the month was Oahu energy usage at its highest?
Nov 28th 02:45:00.00-10:00
How many MW was this?
995 MW
What day and time during the month was Oahu energy usage at its lowest?
Nov 26th 20:00:00.00-10:00
How many MW was this?
496 MW
What day during the month did Oahu consume the most energy?
Nov 28th
How many MWh was this?
995 MW
What day during the month did Oahu consume the least energy?
Nov 26th
How many MWh was this?
496 MW
What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)?
Nov 4th
How many lbs of carbon were emitted?
29,959 lbs
What day during the month did Oahu emit the least carbon (i.e. the "cleanest" day)?
Nov 7th
How many lbs of carbon were emitted?
22,908 lbs
To download a copy of our project, please go to this page and download the wattdepot-cli-umikumakahi-2.0.1116.zip file.
As for fixing all the problems that was raised by our reviewers, we did not fix the console bug in using eclipse but we will inform the reviewers that I must be ran in the command prompt. This week, we focused more on designing higher quality test cases and overall improvement of the design.
As a result, posted below is our emma coverage report:
[concat] Emma Coverage summary
[concat] class: 100% (27/27)
[concat] method: 96% (74/77)
[concat] block: 86% (3538/4098)
[concat] line: 78% (668.4/860)
We communicate with each other mainly through email and instant messaging with the occasional meetings before and during class. We tried our best to distribute the work load evenly, but my lack of java programming has made my partner carry more of the wieght.
To help us monitor our work progress, we have installed the SoftwareICU which is a tool to help monitor our progress. It also display infomation on coverage, complexity, coupling, churn, and more. posted below is a screenshot of our last 7-day
In testing to see if our commands are working properly, we were tasked to answer a few question:
What day and time during the month was Oahu energy usage at its highest?
Nov 28th 02:45:00.00-10:00
How many MW was this?
995 MW
What day and time during the month was Oahu energy usage at its lowest?
Nov 26th 20:00:00.00-10:00
How many MW was this?
496 MW
What day during the month did Oahu consume the most energy?
Nov 28th
How many MWh was this?
995 MW
What day during the month did Oahu consume the least energy?
Nov 26th
How many MWh was this?
496 MW
What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)?
Nov 4th
How many lbs of carbon were emitted?
29,959 lbs
What day during the month did Oahu emit the least carbon (i.e. the "cleanest" day)?
Nov 7th
How many lbs of carbon were emitted?
22,908 lbs
To download a copy of our project, please go to this page and download the wattdepot-cli-umikumakahi-2.0.1116.zip file.
Wednesday, November 11, 2009
Peer review: Having more sets of eyes
After doing the peer review, it made me realized that I need to change the way that I write programs. As I've notice from the two other systems that I've reviewed, there wasn't any testing done at all and require a bit more error handling. Maybe because we're still in school and the first thing we think about is completing the required task first to do what it's intended to do. Since a program that is incomplete will receive a worser grade. We will definitely have to change this mentality once we get into the real working world.
During the meeting, I felt a bit of awkwardness when it came to giving critiques to peers face-to-face. As I'm not sure how they would take my critiques and they probably think the same way. But once we got the ball rolling, it went really smooth as each team was eager to hear how they can improve their codes. It's almost like a teaching and learning experience all in one.
Majority of the critiques that we received had the same issues. They were able to get it to work with the Eclipse IDE, so they couldn't test the codes.We did all of the testing for our program in the command prompt so we didn't know it couldn't compile in Eclipse. When I try running it in Eclipse, I received a NullPointerException, it have to do with us using the "console.readline" to read user input. Other critiques were that we needed more comments to make our code easier to understand. We will be working on these issues and hopefully get it all fixed back this week.
Over all, This peer review was a great experience and an eye-opener for the ways we program.
During the meeting, I felt a bit of awkwardness when it came to giving critiques to peers face-to-face. As I'm not sure how they would take my critiques and they probably think the same way. But once we got the ball rolling, it went really smooth as each team was eager to hear how they can improve their codes. It's almost like a teaching and learning experience all in one.
Majority of the critiques that we received had the same issues. They were able to get it to work with the Eclipse IDE, so they couldn't test the codes.We did all of the testing for our program in the command prompt so we didn't know it couldn't compile in Eclipse. When I try running it in Eclipse, I received a NullPointerException, it have to do with us using the "console.readline" to read user input. Other critiques were that we needed more comments to make our code easier to understand. We will be working on these issues and hopefully get it all fixed back this week.
Over all, This peer review was a great experience and an eye-opener for the ways we program.
Sunday, November 8, 2009
Code Review: Help yourself by helping your peers
After working a week on creating the command line interface for the Wattdepot project, we now begin a process called "Code Review". Our code review is an informal peer review consisting of peers examining each others source codes to find mistakes and possible improvements to their quality of their work, thus improving our own skills as a developer. We were each assign 2 other team's code to review. I will be doing my review on team "Umi" and "Umikumalua" codes which can be found here.
Team Umi:
Team Umi's system was well design with all commands working as intended. There were only a few minor error which could be easily fixed. Their javadocs were a bit brief but descriptive. One major thing they can work in is making test cases for each command. Here is my full review on Team Umi's system.
Team Umikumalua:
Team Umikumakahi's system competed most of the commands with a few not working as intended (chart, source summary). The javadoc were good but might have to work on some consistency between different authors. Things they can work on is making the remaining command work as intended, add more error messages, and make test cases for the commands. Here is my full review on Team UmiKumakahi's system.
Team Umi:
Team Umi's system was well design with all commands working as intended. There were only a few minor error which could be easily fixed. Their javadocs were a bit brief but descriptive. One major thing they can work in is making test cases for each command. Here is my full review on Team Umi's system.
Team Umikumalua:
Team Umikumakahi's system competed most of the commands with a few not working as intended (chart, source summary). The javadoc were good but might have to work on some consistency between different authors. Things they can work on is making the remaining command work as intended, add more error messages, and make test cases for the commands. Here is my full review on Team UmiKumakahi's system.
Wednesday, November 4, 2009
Wattdepot: puts you in command
As you all know, we got a new task this week for our Software Engineering class. We started our new project working with WattDepot, a program that collects and stores data on power consumption. With this tool, we are capable of retrieve the data, analyze it, and output it to a chart. This program would be extremely useful for smart consumers to monitor their power consumption. (But for this project, we are currently working with simulated data)
This was our first task that was done in a group. The task was to create a Command Line Interface for this project which will allow users to issue commands listed on the CommandSpecificationpage. Programming has never been one of my strong points. Working in a group has allowed me to learn better programming from my partner and improve my java programming skills. I was lucky enough to a partner that was knowledgeable in Java and patient in helping me to understand the codes. My partner contributed a lot more than I have in this project, Which mean I definitely have to improve on my programming skills to catch up with everyone.
Major problems that we're encounter were satisfying Checkstyle, PMD, and FindBug. To satisfy these criteria, we had to change a lot of the codes to codes that we're less familiar with, which was quite frustrating but a good learning experience. Unfortunately we were unable to create test cases to test each command due to time constraints.
If you want to take a look at our code for the Command Line Interface, you can find it in this list. Our group is umikumakahi...
This was our first task that was done in a group. The task was to create a Command Line Interface for this project which will allow users to issue commands listed on the CommandSpecificationpage. Programming has never been one of my strong points. Working in a group has allowed me to learn better programming from my partner and improve my java programming skills. I was lucky enough to a partner that was knowledgeable in Java and patient in helping me to understand the codes. My partner contributed a lot more than I have in this project, Which mean I definitely have to improve on my programming skills to catch up with everyone.
Major problems that we're encounter were satisfying Checkstyle, PMD, and FindBug. To satisfy these criteria, we had to change a lot of the codes to codes that we're less familiar with, which was quite frustrating but a good learning experience. Unfortunately we were unable to create test cases to test each command due to time constraints.
If you want to take a look at our code for the Command Line Interface, you can find it in this list. Our group is umikumakahi...
Monday, November 2, 2009
Hudson, a continuous secondary check...
If you wondering what Hudson is, it is a a popular open source continuous integration server. We were introduced to Hudson for our first group project in creating a command line interface for the WattDepot project. Continuous integration is great for group work where you want to ensure that the code quality and standards are consistent throughout the whole development process. It can assist teams with software build automation, continuous automated build verification, build testing, and post-buuild procedure automation.
When we began to setup the job in the Hudson server, we were having some connection issues. It was really slow in connecting and there were time where I couldn't load the page up at all. But when it was back up and running, creating the job as a cinch. We were enabled to sync our project with the Hudson server through the use of SVN. So now whenever a member commits new code, Hudson will do a verify test just like the ones we do with ANT, and if it fails the build, it's setup to send emails to the whole discussion group. Isn't it a nifty tool to have? I was quite impress with it. The only drawback that I've experience with this tool so far is the connection problem. As I'm typing this blog, I'm not able to connect to our Hudson project page to get a screenshot of it. I'm not sure what's causing this issue but I hope it'll get resolve soon.
When we began to setup the job in the Hudson server, we were having some connection issues. It was really slow in connecting and there were time where I couldn't load the page up at all. But when it was back up and running, creating the job as a cinch. We were enabled to sync our project with the Hudson server through the use of SVN. So now whenever a member commits new code, Hudson will do a verify test just like the ones we do with ANT, and if it fails the build, it's setup to send emails to the whole discussion group. Isn't it a nifty tool to have? I was quite impress with it. The only drawback that I've experience with this tool so far is the connection problem. As I'm typing this blog, I'm not able to connect to our Hudson project page to get a screenshot of it. I'm not sure what's causing this issue but I hope it'll get resolve soon.
Subscribe to:
Posts (Atom)