Here is my reveiw for Project Ekolugical Carbonometer following our professor's checklist.
A. Build successfully
B1. The main functionality is implemented.
B2.
1.When I put 2009-12-04 and submit, it returns a list. However, if I put 2009-12-05, 2009-12-06, 2009-12-07...
and submit, it does not change. It looks like there is no data but the no data error does not show up.
2.When I put 2009-11-2g 2009 and submit, it returns error fail to convert to timestamp. However, the error message
should be "Please enter a date with the following format: YYYY-MM-DD."
B3.
1.The interface is not self-explanatory.
2.The system require unnecessary scrolling to see the data.
3.The style is not standardized. "Enter a date" compare with the "Maximum and minimum"
C1.Description included. No explanation how packages relate to each other.
C2.Description included. No explanation how classes relate to each other.
C3.Description included. No sample code for clients of the class.
C4.Description included.
D1. Most names are properly named. RESULT, RESULT_DAY_ONE, RESULT_DAY_TWO should not be capitalized since they are
not constant.
D2. Internal name looks Ok.
E1. Emma test coverage is good 86% lines of code.
E2. There are two tests have the same comment. Not test for the WattDepot query.
F1. I think the Thresholds class should be inside the WattDepotCommand class because the calculation of threshold heavily
depends on the WattDepotCommand class.
G1. I think WattDepotCommand class's instance "RESUTL", "RESULT_DAY_ONE", "RESULT_DAY_TWO" is not appropriate. They are
too detail.
H1. Methods look OK.
I1. The code is implemented consistently.
J1. Well documented for both UserGuide and DeveloperGuide.
K1. I cannot view the hackystats for this project.
L1. I think the planning is too general. There is no issue for implementation of the application.
L2. The task is evenly distributed.
M1. The system is regularly built due to commits,
M2. The builds failed states on Nov 21 lasted 2 hours.
M3. There is a daily build job.
Overall Comment:
I am not sure if Ekolugical Carbonometer project's threshold calculation make sense or not. However, I think the interface of the web-application definitly need improve. The idea of having a rolling threshold is very good.
Tuesday, November 24, 2009
Monday, November 23, 2009
WattDepot WebApp Project
In the past week, I worked on a new project about WattDepot service with George, Aaron and Dean. For this project, we named it "e-hoomaluo" which means "conserve" in Hawaiian (I heard from George). It is to retrieve the hourly carbon content data from the WattDepot server for a given date. Also it analyzes the data and displays the hourly data in different colors so that people know when is the best to use energy.
-Red means the carbon content is pretty high and you should try to use energy as little as possible at this time.
-Yellow means the carbon content is at a medium level. You may use some energy but it might not be the best timing.
-Green means the carbon content is low and if you want to use some energy to do something, now is the best time.
Unlike the WattDepot Cli project, "e-hoomaluo" is a web application. Again, unlike the most web applications I worked on before(I mostly use javascript to do the programing), this time we used Apache Wicket, which is definitely a challenge for most of us. Luckily, our professor posted 5 example web applications that using Wicket, so that I can play arround and help me to get use to Wicket.
Frankly speaking, I am still not good at Wicket. As far as I know, you have to have an html file paired with a java file. For example, you have a page called testPage.html. If you want to use Wicket, you need to have a file called testPage.java. Also you need to assign a special attribute called "wicket:id" in the html file. It is the name that will be recognized in the java file.
In this project, I didn't do anything with the web programing. I was assigned to implement the class that creates the connection to WattDepot server and retrieving the carbon content data. Aaron and George worked on the implementation of the web page. Dean worked on the setup and the documentation. Since Dean was outside the island for this week, George, Aaron and I met almost everyday. I think our work went pretty smoothly. In the first meeting, we decided the design of the web page and split the work. Later I just worked on my own part. Finally, George merged everything together and created the distribution. The only challenge during the development is to use Wicket to change the CSS of the hourly data. I and George spent couple hours to solve that. I think the group project gives me a lot of motivation.
Here is the software ICU screenshot for "e-hoomaluo":
Unfortunately, we do not have a good coverage of our project. I think it is because that none of us is familiar with how to write test for Wicket. Probably in the next version, we can find a way to write junit test for Wicket program. Another issue is that the score for Churn is kind of low, again I am not sure how this score is measured. However, I think we did have a continuous development for this project.
Anyway, here is the link to get to the google project hosting for "e-hoomaluo". In this page, you can find the source of "e-hoomaluo" project and also the user guide and the developer guide.
-Red means the carbon content is pretty high and you should try to use energy as little as possible at this time.
-Yellow means the carbon content is at a medium level. You may use some energy but it might not be the best timing.
-Green means the carbon content is low and if you want to use some energy to do something, now is the best time.
Unlike the WattDepot Cli project, "e-hoomaluo" is a web application. Again, unlike the most web applications I worked on before(I mostly use javascript to do the programing), this time we used Apache Wicket, which is definitely a challenge for most of us. Luckily, our professor posted 5 example web applications that using Wicket, so that I can play arround and help me to get use to Wicket.
Frankly speaking, I am still not good at Wicket. As far as I know, you have to have an html file paired with a java file. For example, you have a page called testPage.html. If you want to use Wicket, you need to have a file called testPage.java. Also you need to assign a special attribute called "wicket:id" in the html file. It is the name that will be recognized in the java file.
In this project, I didn't do anything with the web programing. I was assigned to implement the class that creates the connection to WattDepot server and retrieving the carbon content data. Aaron and George worked on the implementation of the web page. Dean worked on the setup and the documentation. Since Dean was outside the island for this week, George, Aaron and I met almost everyday. I think our work went pretty smoothly. In the first meeting, we decided the design of the web page and split the work. Later I just worked on my own part. Finally, George merged everything together and created the distribution. The only challenge during the development is to use Wicket to change the CSS of the hourly data. I and George spent couple hours to solve that. I think the group project gives me a lot of motivation.
Here is the software ICU screenshot for "e-hoomaluo":
Unfortunately, we do not have a good coverage of our project. I think it is because that none of us is familiar with how to write test for Wicket. Probably in the next version, we can find a way to write junit test for Wicket program. Another issue is that the score for Churn is kind of low, again I am not sure how this score is measured. However, I think we did have a continuous development for this project.
Anyway, here is the link to get to the google project hosting for "e-hoomaluo". In this page, you can find the source of "e-hoomaluo" project and also the user guide and the developer guide.
Monday, November 16, 2009
WattDepot Cli Version 2.0
Since we have developed the WattDepot Cli project in last two weeks, this week we are assigned to add some more features to WattDepot Cli and make it Version 2.0.
Last week, two other groups reviewed our project, they provided lots of feedback to us which I mentioned in my previous blog post. Therefore, we decided to modify our existing WattDepot Cli project before implementing new commands. First, we simplified the class names for all the commands. Then we added more error messages to represent different exceptions. Also we fixed some bugs that found in existing project. Then we start implementing the new commands.
George and I didn't meet this time. Since last project, we have known each other pretty well. So we decided to communicate by email. We email each other almost everyday to check out status. I implemented two commands and George setup the hackystat for our project and implemented one command. Therefore, I think the work is partitioned equally.
Here is a Software ICU screenshot for our project.
I think our project's health is kind of OK. We have a pretty good coverage for the junit test. Also we contribute to the project almost everyday. However, I am not so sure why the complexity is high because WattDepot Cli is a pretty simply project. I don't think we have a lot of loop or condition statement. The Churn value is kind of high because I kept having some strange problems in some junit tests and I didn't commit until Thursday. So once I commit, I introduced a lot of new lines. With these experience, I hope we can do better for the next project, which is coming soon.
Finaly, we need to find the answers to some questions that asked by our professor. George implemented two additional commands to answer these questions. So I used his new commands: "energystat" and "carbonstat". Here is the answer I got.
>energystats generated SIM_OAHU_GRID from 2009-11-01 to 2009-11-30 daily
Max: 14764.0 MWh at 2009-11-03T00:00:00.000-10:00
Min: 14089.0 MWh at 2009-11-02T00:00:00.000-10:00
Average: 14571.1 MWh
>carbonstats SIM_OAHU_GRID from 2009-11-01 to 2009-11-30
Max: 29959472.0 lbs at 2009-11-04T00:00:00.000-10:00
Min: 22908808.0 lbs at 2009-11-07T00:00:00.000-10:00
Average: 27141379.3 lbs
Last week, two other groups reviewed our project, they provided lots of feedback to us which I mentioned in my previous blog post. Therefore, we decided to modify our existing WattDepot Cli project before implementing new commands. First, we simplified the class names for all the commands. Then we added more error messages to represent different exceptions. Also we fixed some bugs that found in existing project. Then we start implementing the new commands.
George and I didn't meet this time. Since last project, we have known each other pretty well. So we decided to communicate by email. We email each other almost everyday to check out status. I implemented two commands and George setup the hackystat for our project and implemented one command. Therefore, I think the work is partitioned equally.
Here is a Software ICU screenshot for our project.
I think our project's health is kind of OK. We have a pretty good coverage for the junit test. Also we contribute to the project almost everyday. However, I am not so sure why the complexity is high because WattDepot Cli is a pretty simply project. I don't think we have a lot of loop or condition statement. The Churn value is kind of high because I kept having some strange problems in some junit tests and I didn't commit until Thursday. So once I commit, I introduced a lot of new lines. With these experience, I hope we can do better for the next project, which is coming soon.
Finaly, we need to find the answers to some questions that asked by our professor. George implemented two additional commands to answer these questions. So I used his new commands: "energystat" and "carbonstat". Here is the answer I got.
>energystats generated SIM_OAHU_GRID from 2009-11-01 to 2009-11-30 daily
Max: 14764.0 MWh at 2009-11-03T00:00:00.000-10:00
Min: 14089.0 MWh at 2009-11-02T00:00:00.000-10:00
Average: 14571.1 MWh
>carbonstats SIM_OAHU_GRID from 2009-11-01 to 2009-11-30
Max: 29959472.0 lbs at 2009-11-04T00:00:00.000-10:00
Min: 22908808.0 lbs at 2009-11-07T00:00:00.000-10:00
Average: 27141379.3 lbs
Tuesday, November 10, 2009
Code Review for WattDepot Cli - Part 2
After reviewing two WattDepot Cli projects that implemented by different teams and their comments of our WattDepot Cli project, I learned some lessons.
First thing I learned is that error message is very important. When I wrote my code, I saw there are some many exceptions to catch if I need to retrieve data for a source. I thought it is kind of tedious to compose the error message one by one. So why don't I just send one same error message "connection error". However, when I read the comments, both team criticize on this irresponsible error message by saying the error message should be more specific. In both their projects, they handle all kinds of exceptions separately. I think they are right. Error message is very important for users. If it is not very informative, user would never know why the program is not working.
Second thing I learned is that declaring instance inside a loop is not efficient. Before, I like to create a temporary instance in the loop to hold some value. This is very inefficient because I keep creating new object in the system which is not neccessary. Instead, I can declare it outside the loop, and in the beginning of the loop initialize the value of that instance. In this way, the performance of the program can be improved.
Third thing I learned is that reviewing the project that created by other people is not a easy task. Even though for a small project like WattDepot Cli, it still takes me some time to understand other teams' structure, global instance, and test cases. Therefore, programmers should try their best to code in a readable way so that future reviewers can catch up quickly.
Overall, I think review other people's code is a not a bad thing to do. Although it might be boring, you can always learn something that you never know.
First thing I learned is that error message is very important. When I wrote my code, I saw there are some many exceptions to catch if I need to retrieve data for a source. I thought it is kind of tedious to compose the error message one by one. So why don't I just send one same error message "connection error". However, when I read the comments, both team criticize on this irresponsible error message by saying the error message should be more specific. In both their projects, they handle all kinds of exceptions separately. I think they are right. Error message is very important for users. If it is not very informative, user would never know why the program is not working.
Second thing I learned is that declaring instance inside a loop is not efficient. Before, I like to create a temporary instance in the loop to hold some value. This is very inefficient because I keep creating new object in the system which is not neccessary. Instead, I can declare it outside the loop, and in the beginning of the loop initialize the value of that instance. In this way, the performance of the program can be improved.
Third thing I learned is that reviewing the project that created by other people is not a easy task. Even though for a small project like WattDepot Cli, it still takes me some time to understand other teams' structure, global instance, and test cases. Therefore, programmers should try their best to code in a readable way so that future reviewers can catch up quickly.
Overall, I think review other people's code is a not a bad thing to do. Although it might be boring, you can always learn something that you never know.
Monday, November 9, 2009
Code Review for WattDepot Cli - Part 1
This week, I was assigned to review two other team(Ekolu, Umikumaha)s' source code for WattDepot Cli project. To conduct this review, each of us followed a review checklist that was provided by my teacher. After reading through other's code, I finaly understand how important the Javadoc is. Javadoc will show the structure for the project and it provides a easy way to access the code. Although it is not a fun thing to review code, I had some good time when I tried to break other teams' program.
Anyhow, following is my review for team Ekolu:
A. Verify passed. Build successfully.
B. All commands are working correctly, but there are a number of problems.
1."list sensordata SIM_KAHE_1 day 2009-11-10T23:30:00.0000" works the same as "list sensordata SIM_KAHE_1 day 2009-11-10".
2."list power generated SIM_KAHE day 2009-11-01 sampling-interval 0 statistic max will break the system and no command can be processed after that.
3."list power generateds SIM_KAHE day 2009-11-01 sampling-interval 60 statistic max" works fine. There is no check for string like genterateds.
C. The Javadoc for this project is pretty good. It does not explain how packages and classes relate to each other, but it is still very helpful.
D. Some class names are not very clear. For example, PowerTimestamp is not as good as CommandListPowerTimestamp. Some internal names are not informative too. For example, "fos" is not a good name to represent FileOutputStream.
E. The testing coverage is ok. However, there are some cases do not have test.
1. No test for correct intput for every command.
2. No test for help.
3. No test for sampling-interval value.
4. No test for "list power consumed", "list total energy" and "chart power consumed" command
5. No test for "statistic min" and "statistic average"
F. Overall the package level design is good.
G. The class level design has some problem.
1. SourceListing class is not used.
2. The block of condition: "" equals to sourceName in "list summary" command is a dead block.
H Most methods in the system accomplish only a single task. Some methods need refactor. For example in SourcesInformation class, the if statement in listsources method should be refactored. Overall, most methods do not have side-effects.
i.The consistency is not very good. For example, the error message for "list power consumed SIM_KAH timestamp 2009-11-01T00:00:00.0000" should be the same as "list summary SIM_KAH". Also sometimes stringbuffer is used to concatenate strings and sometimes just use + to concatenate strings.
The review for Umikumaha is still on-going.
I hope my comments can help them to improve the quality of the project.
Anyhow, following is my review for team Ekolu:
A. Verify passed. Build successfully.
B. All commands are working correctly, but there are a number of problems.
1."list sensordata SIM_KAHE_1 day 2009-11-10T23:30:00.0000" works the same as "list sensordata SIM_KAHE_1 day 2009-11-10".
2."list power generated SIM_KAHE day 2009-11-01 sampling-interval 0 statistic max will break the system and no command can be processed after that.
3."list power generateds SIM_KAHE day 2009-11-01 sampling-interval 60 statistic max" works fine. There is no check for string like genterateds.
C. The Javadoc for this project is pretty good. It does not explain how packages and classes relate to each other, but it is still very helpful.
D. Some class names are not very clear. For example, PowerTimestamp is not as good as CommandListPowerTimestamp. Some internal names are not informative too. For example, "fos" is not a good name to represent FileOutputStream.
E. The testing coverage is ok. However, there are some cases do not have test.
1. No test for correct intput for every command.
2. No test for help.
3. No test for sampling-interval value.
4. No test for "list power consumed", "list total energy" and "chart power consumed" command
5. No test for "statistic min" and "statistic average"
F. Overall the package level design is good.
G. The class level design has some problem.
1. SourceListing class is not used.
2. The block of condition: "" equals to sourceName in "list summary" command is a dead block.
H Most methods in the system accomplish only a single task. Some methods need refactor. For example in SourcesInformation class, the if statement in listsources method should be refactored. Overall, most methods do not have side-effects.
i.The consistency is not very good. For example, the error message for "list power consumed SIM_KAH timestamp 2009-11-01T00:00:00.0000" should be the same as "list summary SIM_KAH". Also sometimes stringbuffer is used to concatenate strings and sometimes just use + to concatenate strings.
The review for Umikumaha is still on-going.
I hope my comments can help them to improve the quality of the project.
Tuesday, November 3, 2009
WattDepot Client and Continuous Integration
These days, I learned about continuous integration, which automatically download the code from the repository and try to built it and run all the tests. In the beginning, I thought it is kind of redundant because if I commit some code, I will make sure there is no error, so why do we need another tool to do it again?
However after a while, I figured that actually I am wrong.
The reason why continuous integration is significant because different user may have a different environment setup. For example, person A commits something which depends on a class file he just created. When he is doing SVN commit, he didn't commit the new class file, because Tortoise SVN does not check non-versioned file automatically. In that case, although the code works well with person A's environment, it will introduce errors in any other user's environment. Now we need some kind of tool to prevent this sadly scenario.
For our WattDepot Client project, we used Hudson for continuous integration. Hudson is an open source software that supports continuous integration. It has a simple and clear user interface. You may set up a build schedule for your project. Then it will download your project and try to build it according to the schedule you set, like a batch program. All you need to do is to include a hudson.build.xml in the Ant build system. You may also want to leave the project discussion email address, so that Hudson will send a report email once it fails building the project. I believe all of these will facilitate group project dramatically.
However after a while, I figured that actually I am wrong.
The reason why continuous integration is significant because different user may have a different environment setup. For example, person A commits something which depends on a class file he just created. When he is doing SVN commit, he didn't commit the new class file, because Tortoise SVN does not check non-versioned file automatically. In that case, although the code works well with person A's environment, it will introduce errors in any other user's environment. Now we need some kind of tool to prevent this sadly scenario.
For our WattDepot Client project, we used Hudson for continuous integration. Hudson is an open source software that supports continuous integration. It has a simple and clear user interface. You may set up a build schedule for your project. Then it will download your project and try to build it according to the schedule you set, like a batch program. All you need to do is to include a hudson.build.xml in the Ant build system. You may also want to leave the project discussion email address, so that Hudson will send a report email once it fails building the project. I believe all of these will facilitate group project dramatically.
WattDepot Client and Working in a Group
Last week, we started on a new project: "WattDepot Client". This is a client program that retrieves data from the WattDepot server. The task for us is to implement a command-line style user interface and the system, which reads and processes the command. Following are the commands that the client should be able to recognize.
2.1 help
2.2 quit
2.3 list sources
2.4 list summary {source}
2.5 list sensordata {source} timestamp {timestamp}
2.6 list sensordata {source} day {day}
2.7 list power [generated|consumed] {source} timestamp {timestamp}
2.8 list power [generated|consumed] {source} day {day} sampling-interval {minutes} statistic {max|min|average}
2.9 list total [carbon|energy] generated {source} day {day} sampling-interval {minutes}
2.10 chart power [generated|consumed] {source} {startday} {endday} sampling-interval {minutes} file {file}
As you can see, there are a lot of things to implement. The good news is that we are not building from scratch. We have the code for the command-line interface and also some libraries that will make life easier.
I was assigned to the Umikumakolu team. My partner George is a very talented program er. I learned a lot of thing from viewing his code and he always can help me out when I had a problem.
Finally, we successfully finish the WattDepot Client development. We break up the work according to our skill of programming. We analyze the problem, and figure that the command with a lower number tends to be more trivial. So we decide that I will work from the front while George will work from the back, and we should be responsible for testing the commands that we wrote.
I think the whole development went through pretty smoothly. We had a daily meeting during the weekdays. In the weekend, we emailed our status to each other. I really enjoyed pair programming. I think pair programming gives me more motivation and I write my code more carefullly because I know my partner is counting on me.
I hope we can have more group project in this class.
2.1 help
2.2 quit
2.3 list sources
2.4 list summary {source}
2.5 list sensordata {source} timestamp {timestamp}
2.6 list sensordata {source} day {day}
2.7 list power [generated|consumed] {source} timestamp {timestamp}
2.8 list power [generated|consumed] {source} day {day} sampling-interval {minutes} statistic {max|min|average}
2.9 list total [carbon|energy] generated {source} day {day} sampling-interval {minutes}
2.10 chart power [generated|consumed] {source} {startday} {endday} sampling-interval {minutes} file {file}
As you can see, there are a lot of things to implement. The good news is that we are not building from scratch. We have the code for the command-line interface and also some libraries that will make life easier.
I was assigned to the Umikumakolu team. My partner George is a very talented program er. I learned a lot of thing from viewing his code and he always can help me out when I had a problem.
Finally, we successfully finish the WattDepot Client development. We break up the work according to our skill of programming. We analyze the problem, and figure that the command with a lower number tends to be more trivial. So we decide that I will work from the front while George will work from the back, and we should be responsible for testing the commands that we wrote.
I think the whole development went through pretty smoothly. We had a daily meeting during the weekdays. In the weekend, we emailed our status to each other. I really enjoyed pair programming. I think pair programming gives me more motivation and I write my code more carefullly because I know my partner is counting on me.
I hope we can have more group project in this class.
Subscribe to:
Posts (Atom)