This week, we keep working on the Stoplight Gadget project. This time, we made some remarkable progress and release the version 1.2(http://stoplightgadget.googlecode.com/svn/tags/Gadget_1_2/stoplight_gadget.xml). Version 1.2 basically has four enhancement.
First of all, I add three user inputs (Data source URL, threshold for green light, and threshold for red light) in the Stoplight Gadget, and the gadget is able to read and use the inputs. All of these input fields are created by "user pref". Google has a pretty detail documentation of it. However, I am still not sure how to create Google Visualization Query from the user pref.
Second, I modified the Google Visualization code, so that it displays a stoplight image instead of the actual data. This time, we simply add a few "if" statements in the JavaScript for the value comparison. Also we use a image tag to display the stoplight image.
Third, Jarret embedded the our Stoplight Gadget to our Google Project Hosting website. Also he fixed my Visualization Code so that adjust the image size.
One more thing, Paul figured out a way to use the URL in Google Project Hosting in the Gadget. He found two ways: either use the raw file URL in Google Project Hosting or set the MIME type property of the Visualization JavaScript and modify the SVN configuration.
So basically this is what we had so far. The lesson I learned from Google Gadget development so far is that debug in Google Gadget is not very easy. Google Gadget Editor is the tool that I mostly use in coding. However, it does not provide a preview if the gadget requires a user input. So I have to add it to the iGoogle all the time. Also it seems the page caches the gadget code. Sometimes I made some changes and click save, but the changes are gone when I load the file again. Anyway, I think the IDE is really a serious issue for Google Gadget Development.
Monday, February 1, 2010
Wednesday, January 27, 2010
Get Started With Gadget and Visualization
This week, we had our first team meeting with Dr. Johnson. It turned out that we actually misunderstood the project requirement. In the beginning, we thought this Stoplight project is same as the Stoplight we designed last semester. The only thing we need to do is to make a Google Gadget and visualization for it. However, we actually need to create a generic Stoplight that takes any data source. Since we are still new comers in Google Gadget, we decide to develop the project into three steps.
The first step:
Implement a Google Visualization that displays a number. Create a Google Gadget that retrieves a number from a Google Spreadsheet.
The second step:
Modify the Google Visualization that displays a stoplight according to the number that pass to it. Modify the Google Gadget that takes three user inputs: Data source URL, Red threshold, Green threshold.
The third step:
Modify the Google Visualization that displays a stoplight and a text message and handles error. Modify the Google Gadget that refreshes after a certain time period.
This week, I finished implementing the first step. Basically, I just follow the example in Google Documentations. It has tutorial for how to get Google Spreadsheet URL, how to create a Google Visualization Query, how to include visualization in the Google Gadget. Finally, this is my first try on Google Visualization and Google Gadget (http://stoplightgadget.googlecode.com/svn/tags/Gadget_1_1/Gadget_1_1.xml).
For the next week, I am going to dig more in Google Visualization so that it can display a image. Also I will find out what else data format can be convert into Google datatable and how to make the user input in Google Gadget. Hopefully, we can make a better looking Gadget next week.
The first step:
Implement a Google Visualization that displays a number. Create a Google Gadget that retrieves a number from a Google Spreadsheet.
The second step:
Modify the Google Visualization that displays a stoplight according to the number that pass to it. Modify the Google Gadget that takes three user inputs: Data source URL, Red threshold, Green threshold.
The third step:
Modify the Google Visualization that displays a stoplight and a text message and handles error. Modify the Google Gadget that refreshes after a certain time period.
This week, I finished implementing the first step. Basically, I just follow the example in Google Documentations. It has tutorial for how to get Google Spreadsheet URL, how to create a Google Visualization Query, how to include visualization in the Google Gadget. Finally, this is my first try on Google Visualization and Google Gadget (http://stoplightgadget.googlecode.com/svn/tags/Gadget_1_1/Gadget_1_1.xml).
For the next week, I am going to dig more in Google Visualization so that it can display a image. Also I will find out what else data format can be convert into Google datatable and how to make the user input in Google Gadget. Hopefully, we can make a better looking Gadget next week.
Tuesday, January 19, 2010
Back to the Software Engineering
After a short winter break, I am back to software engineering. I am very glad to take Dr.Johnson's class again, which is also part of my graduate research. This class is sort of an extension of the project (WattDepot Web Application) that I worked on last semester.
This semester we are going to create a dorm competition for energy usage called Kukui Cup. It contains a lot of parts. I was in the team of creating a Google Gadget for the stoplight that we built last semester. Further more, we also need to integrate Google Visualization to this stoplight gadget.
Stoplight team has three members: Jerry, Paul and I. We had our first meeting on Monday. We talked about the project schedule and came up with some questions that we are not sure. Both Jerry and Paul are very friendly and energetic. I hope we can have fun in this project and develop a remarkable Google Gadget.
For this week, I am going to walk through the Google Gadget Tutorial ( I have looked at it a little bit. It is very detail and helpful.) Interestingly, I figured that Google Chrome has a problem in parsing the xml version of a Google Gadget. And everything looks good in FireFox. The second task for us is to get familiar with JavaScript and Google Visualization API, so that we can get ready for the future development.
This semester we are going to create a dorm competition for energy usage called Kukui Cup. It contains a lot of parts. I was in the team of creating a Google Gadget for the stoplight that we built last semester. Further more, we also need to integrate Google Visualization to this stoplight gadget.
Stoplight team has three members: Jerry, Paul and I. We had our first meeting on Monday. We talked about the project schedule and came up with some questions that we are not sure. Both Jerry and Paul are very friendly and energetic. I hope we can have fun in this project and develop a remarkable Google Gadget.
For this week, I am going to walk through the Google Gadget Tutorial ( I have looked at it a little bit. It is very detail and helpful.) Interestingly, I figured that Google Chrome has a problem in parsing the xml version of a Google Gadget. And everything looks good in FireFox. The second task for us is to get familiar with JavaScript and Google Visualization API, so that we can get ready for the future development.
Friday, December 18, 2009
My Experience of Software Engineering Class
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.
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.
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.
Subscribe to:
Posts (Atom)