What's Next

Since we finished development on our first Google Gadget Project last week, we are ready for some new project. So during the meeting with Dr. Johnson, he introduced our next project (WattDepot Gadget Monitor) to us. Also during the meeting, we found there were still some minor things need to be taken care of. Therefore, the task for this week is to clean up the rest of Stoplight Gadget and also start the development on new project.

For the clean up, we added a new user field called title, which allows user to specify what this gadget for. Since we couldn't get the scalable image working, we created a drop down menu to let user pick the size of the image.

My task is to create the first version of WattDepot Gadget Monitor. WattDepot Gadget Monitor is a google gadget that retrives a value from WattDepot Server and display it. It allows user to choose a source from all sources in WattDepot Server, as well as data displayed in the gadget (either Energy or Carbon). Because I had some experiences in gadget development from last project, this time the version 1 development went pretty smoothly. The only problem I had so far is that I am not sure how to generate the drop down menu dynamically. Hopefully, in the following week I can find a solution to it.

This is it... the Stoplight Gadget

Finally, our last version of stoplight gadget,Stoplight Gadget 1.4, is released. From now on, we are going to pause our development on Stoplight Gadget. We have added it to the Google Gadget gallery so that other people may use it or improve it.

In this week, we made several enhancement. First of all, we added a new user input field called 'Unit', which let user specify the unit of the data from the data source. In addition, we modified the auto-refresh system so that the message get refreshed as well. Further more, we added some error checking in the gadget. We also tried to make our stoplight image scalable, but we didn't successfully implement it.

My task this week was fixing the auto-refresh system. This bug was discovered last week in the meeting with Dr. Johnson. In Stoplight Gadget 1.3, the message area is not auto-refreshed. This function is implemented by using a default method in Google.Visualization.Query class called setRefreshInterval. This method will send the query every certain time period. However, I found that the query will only be sent if the data in the data source is changed. Since the message source did not change when we changed the data source, the query for helpful message was not sent. That's why the message area is not auto-refreshed. In this version, I used the most common JavaScript method: system.timeout method. This will refresh the page for every certain time period. It works a little bit slower than the Google Query method, but acceptable.

Second thing I worked on this week is to determine the "direction", which tells whether the lower number is preferable or the larger number is preferable. In the current version, the gadget will compare the two values that user set for green threshold and red threshold. If the green threshold is smaller, then lower number will be preferable. If the green threshold is larger, then larger number will be preferable.

Basically, this is it, our first Google Gadget. I would say I earned a lot of experience in Google Gadget development. The most enjoyable thing for me is the joy of solving the problems that I run into during the development. The next week, we are going to work on something else. Hopefully, it will be a fun project.

Playing with Google Visualization Query

Since a month has passed, this week is the last week before our first milestone. During this week, we re-organized the SVN repository. Also we updated our Google Project Hosting page. Further more, we improved our existing stoplight gadget a little bit and release the version 1.3.

Among these tasks, I worked on improving the stoplight gadget. For the new version of stoplight gadget, users can specify if they want auto-refresh in their gadget. To implement this functionality, I just create a new user input and pass the value to the Google Visualization Query default method setRefreshInterval. The second enhancement is that user can specify a message source URL in the gadget. This message source URL should contain the relevant message about the data from the data source URL. Hopefully, this message can help user better understand the stoplight and the data. This functionality requires to send another Google Query in the gadget. To figure this out, I had a lot of fun in studying the Google Visualization Query.

Initially, I was trying to nest the Google Query together, which looks like:

MainMethod{
  ...
  ...
  queryA.send(handleQA)
}

handleQA(response){
  ...
  ...
  queryB.send(handleQB)
}

handleQB(response){ 
  ...
  ...
}

However, I found that handleQB is never invoked. Then I start Googling this problem. Most post said it is because the request ID for two query.send are the same, so the query.response will confuse which request should response to. However, it is not a really good idea to manually set the request ID, since handling the response requires modifying the server side which is kind of pain in the ass. After couple days thinking, I just realized this actually is not very hard. I simply moved the code a little bit. So the code looks like:

MainMethod{
  ...
  ...
  queryA.send(handleQA)
  queryB.send(handleQB)
}

handleQA(response){
  ...
  ...
}

handleQB(response){ 
  ...
  ...
}

Yes, it is very simple. So it seems Google Visualization Query does not like get nested. Anyway, I am very surprised that some tasks look so hard, but we soon can figure out how easy they are if we take another perspective.

Well, here is a link for the Stoplight Gadget 1.3. I am looking forward to the upcoming enhancement of this project.

Stoplight Gadget 1.2

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.

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.

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.

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.