Finally, the software engineering class is over. It has been a pretty busy semester for me. In the beginning of this semester, I did not follow the class very well. I was kind of not getting used to so many work during one week or even two days. There are lots of blog posting and I never post a blog before. But now, I am used to it.
Being busy is not a bad thing. I learned a lot of new things in this semester. Before, I never used Java. Now I am pretty confidence with Java programming. I never used eclipse either. Now I am pretty familiar with eclipse. Before, I never created a unit test in my project, but now I understand the importance of testing and what is a good test coverage and quality. Further more, I never heard about Apache Ant and all those quality assurance tools, such as PMD, CheckStyle, and Findbugs. Now I learned how to distribute the system and make use of those auto-quality assurance tools. In the end, we worked on a web application that using Apache Wicket. Before I only used ASP .net frame work and now I have some experiences about Apache Wicket. The most important experience I gained this semester is that project management. Before I mostly code individually, now I learned how to split the work and use issue management tools to manage the schedule and effort.
After all, I think this class is an interesting and important class for me. It makes me more professional and helps me establish good coding habits. I am pretty satisfied with the content that covered this semester. However, if we talk about different software planing technique such as Agile, it will be more interesting.
Anyway, it is a nice semester to remember. Thank you very much for Dr. Johnson and all of you who helped me in this class.
Friday, December 18, 2009
E-hoomaluo V2.0 is released!!
After two weeks development, finally, E-hoomaluo V2.0 is released. It is more a new project rather than version 2. Almost nothing was kept from the last version. In this version, we need to create three pages:
-Home page: describe the purpose of this web application and instruct users how to use this web application.
-Stop light page: get current carbon emitted information from WattDepot server and display different stop light based on the value got.
-Grid info page: generate a chart that describes the energy generation for a specific source given a time interval.
Since we have four people in the group, we decide to split the work into four parts. First, Dean is going to work on the stop light page. Then, Aaron is going to work on the home page and write CSS for the web site. George is going to develop the user input and output panel for the grid info page. My task is to create the method that collects data from wattDepot Server and generate the chart URL.
It is always nice to work in a team. we had a lot good time in this project. For example, we meet in a coffee shop and discuss our status. We use Google wave to host an on-line meeting. We send emails to help each other. Besides, I learned some knowledge about how to use Apache Wicket to host a web application, such as how to add different inputs to the form. Also, I learned how to use google chart to generate different charts.
As a result, I think our E-hoomaluo is pretty good, although the design of the page is not very fancy. However, we got almost everything done.
After we released the V2.0, Aaron and I decided to keep working on this project so that we can get some bonus points for the class. Since there are only two people left, we didn't try to be ambitious. We basically improve the E-hoomaluo in three aspects:
1. Improve the user interface so that E-hoomaluo is more user friendly.
2. Create cache to reduce processing time of generating chart and loading stop light.
3. Develop more functionality in the gird info page, so that user can generate different kinds of chart.
We break the work in half: Aaron works on creating cache, while I work on enhance the chart generation, and both of us work on Improving the user interface.
Compare with V2.0, I added four more user inputs in the grid info page:
1. Time scale
It can be either "Hour", "Day", or "Week". It tells the time scale that used to grab data from WattDepot Server.
2. Resource type
It can be either "Carbon" or "Energy". It tells what type of resource that is going to be displayed in the chart.
3. Transitive check box
If transitive check box is checked, system will display the data for both the selected source and its subsources.
4. Cumulative check box
If cumulative check box is checked, system will generate the chart based on the cumulative data of the selected source.
Finally, we got the E-hoomaluo V2.1 done as well. The cache is working and the chart is more powerful. I am pretty satisfied with what we got.
I learned several lesson in this implementation. The one that impress me the most is that it is pretty hard to maintain other people's code. As I mentioned before, only two of us worked on V2.1, which means we have to maintain George's and Dean's code. Understand their code definitely takes some time for me. Second thing is that testing is really very important. For example, I didn't test a lot about generating chart with a time scale of "week". However, right before the project presentation, I find out that the error message is wrong and some data is not valid to generate the chart. The last thing I learned is communication is very important. For example when Aaron commit the cache creating part, I didn't notice that the data he hashed actually is wrong. I was keep looking at my code and finally find out that it is a caching defect. That also caused a lot of trouble during the development.
Anyway, next semester I will keep working on this project with Dr. Johnson. So hopefully, I can bring some more news on this topic. So, to be continued...
-Home page: describe the purpose of this web application and instruct users how to use this web application.
-Stop light page: get current carbon emitted information from WattDepot server and display different stop light based on the value got.
-Grid info page: generate a chart that describes the energy generation for a specific source given a time interval.
Since we have four people in the group, we decide to split the work into four parts. First, Dean is going to work on the stop light page. Then, Aaron is going to work on the home page and write CSS for the web site. George is going to develop the user input and output panel for the grid info page. My task is to create the method that collects data from wattDepot Server and generate the chart URL.
It is always nice to work in a team. we had a lot good time in this project. For example, we meet in a coffee shop and discuss our status. We use Google wave to host an on-line meeting. We send emails to help each other. Besides, I learned some knowledge about how to use Apache Wicket to host a web application, such as how to add different inputs to the form. Also, I learned how to use google chart to generate different charts.
As a result, I think our E-hoomaluo is pretty good, although the design of the page is not very fancy. However, we got almost everything done.
After we released the V2.0, Aaron and I decided to keep working on this project so that we can get some bonus points for the class. Since there are only two people left, we didn't try to be ambitious. We basically improve the E-hoomaluo in three aspects:
1. Improve the user interface so that E-hoomaluo is more user friendly.
2. Create cache to reduce processing time of generating chart and loading stop light.
3. Develop more functionality in the gird info page, so that user can generate different kinds of chart.
We break the work in half: Aaron works on creating cache, while I work on enhance the chart generation, and both of us work on Improving the user interface.
Compare with V2.0, I added four more user inputs in the grid info page:
1. Time scale
It can be either "Hour", "Day", or "Week". It tells the time scale that used to grab data from WattDepot Server.
2. Resource type
It can be either "Carbon" or "Energy". It tells what type of resource that is going to be displayed in the chart.
3. Transitive check box
If transitive check box is checked, system will display the data for both the selected source and its subsources.
4. Cumulative check box
If cumulative check box is checked, system will generate the chart based on the cumulative data of the selected source.
Finally, we got the E-hoomaluo V2.1 done as well. The cache is working and the chart is more powerful. I am pretty satisfied with what we got.
I learned several lesson in this implementation. The one that impress me the most is that it is pretty hard to maintain other people's code. As I mentioned before, only two of us worked on V2.1, which means we have to maintain George's and Dean's code. Understand their code definitely takes some time for me. Second thing is that testing is really very important. For example, I didn't test a lot about generating chart with a time scale of "week". However, right before the project presentation, I find out that the error message is wrong and some data is not valid to generate the chart. The last thing I learned is communication is very important. For example when Aaron commit the cache creating part, I didn't notice that the data he hashed actually is wrong. I was keep looking at my code and finally find out that it is a caching defect. That also caused a lot of trouble during the development.
Anyway, next semester I will keep working on this project with Dr. Johnson. So hopefully, I can bring some more news on this topic. So, to be continued...
Tuesday, December 8, 2009
Oscar Web Application V1.1
Last week, we got some more new requirements on our web application project. As I mentioned in previous post, the version 1.0 "e-hoomaluo" only has one page which displays the carbon emitted information for one day and mark the data with different color based on a threshold. For version 1.1, we just need to modify the version 1.0 a little bit based on the comments that we got.
Basically, we have two important issues to work on:
1. Change the user interface so that the content will fit in one screen.
2. Change the threshold calculation so that in each day there will be some red, some yellow, and some green.
In this case, I volunteer to work on the threshold calculation. In version 1.0, we just pick some arbitrary value as our threshold. It is hard to have a spread red, yellow, and green in this way because the threshold we use represents the statistic in a long period. Therefore, I decide to use a moving average method to generate a dynamic threshold. After I implemented this method, it looks pretty good as a result.
Since last week in class we discussed about Oscar Web Application V1.0, I learned some interesting things about web application design. First of all, use the space effectively. Try to fit the content in one screen so that user does not have to scroll around. Second, keep the interface simple and clean. Third, make sure the default input value is a valid input, so that default input can show user an example how to use the system.
Basically, we have two important issues to work on:
1. Change the user interface so that the content will fit in one screen.
2. Change the threshold calculation so that in each day there will be some red, some yellow, and some green.
In this case, I volunteer to work on the threshold calculation. In version 1.0, we just pick some arbitrary value as our threshold. It is hard to have a spread red, yellow, and green in this way because the threshold we use represents the statistic in a long period. Therefore, I decide to use a moving average method to generate a dynamic threshold. After I implemented this method, it looks pretty good as a result.
Since last week in class we discussed about Oscar Web Application V1.0, I learned some interesting things about web application design. First of all, use the space effectively. Try to fit the content in one screen so that user does not have to scroll around. Second, keep the interface simple and clean. Third, make sure the default input value is a valid input, so that default input can show user an example how to use the system.
Tuesday, November 24, 2009
Reveiw for Project Ekolugical Carbonometer
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.
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.
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.
Subscribe to:
Posts (Atom)