WattDepot Monitor First Iteration

This past week for my Software Engineering class I've been working solely on the WattDepot Monitor. The WattDepot Monitor as a web application that displays the most recent sensor data of a selected source in WattDepot.

While the Visualizer dealt with JavaScript, Java, and Wicket as its background engine, the Monitor was solely based on Wicket constructs. During our weekly meeting with Prof. Johnson, we concluded that the person to do the Monitor would be the one who is most knowledgeable in Wicket. Since I was the one setting up all the other pages WattDepot-Apps uses and other various UI components that the Visualizer uses, I was the most likely candidate for the task. I actually wanted to do the Monitor because some of the elements that the Monitor needed (timer behaviors) were already incorporated in last semesters project, Greenometer.

I've completed the base functionality, with some assistance from my teammate Bao with the time conversion, of the Monitor. Here's a screen shot of the current interface.

Right now the trunk has the most up-to-date version of the Monitor with debug print statements active. As of now, there has not been a .jar created solely for the monitor, but I will not make one until probably after tomorrow's meeting.

The basic How-To goes:

1. Select your source. After you select a source, beneath the drop-down menu a text field auto-updates and notifies you how often the source gets updated.
2. Select the interval. The interval is how often you want to check WattDepot for new data.
3. Select the sensor data type
4. Click "Monitor" this will start the action of monitoring a source and output will be displayed on the right hand side.

The current issues for the Monitor page have been added to the Issues page in our hosting site. But here's a short list of the current issues:

• Some sources take longer than the specified interval to display. Say for example the interval is set to 5 seconds. Some calls to WattDepot (i.e. a call to SIM_OAHU_GRID, the largest source) takes as long as 10 seconds to respond and output the new data. So the difference between 2 successive "Last Checked" times are longer than 5 seconds.
• Need a way to notify the user if he/she sets an interval that is way lower than the source's update. Say the selected source updates every hour, but the user selects 5 seconds as the update interval.

A nice feature would be to have a nice URL for the "Monitor" button. Right now, when the "Monitor" button is clicked, it adds the Wicket action to the URL.

E.x.

http://localhost:7070/wattdepotapps/?wicket:interface=:3:1:::

to just

http://localhost:7070/wattdepotapps/monitor

So far these are the known issues that I can think of, just waiting for tomorrow weekly meeting with Prof. Johnson and Robert Brewer to review it.

WattDepot-Apps: Second Milestone

After my groups weekly meeting with Prof. Johnson last week Tuesday, it was decided that we will continue to work on the WattDepot-Apps project for the second milestone of the semester. Our most recent distribution of WattDepot-Apps implemented the basic visualizer without multi-source capabilities, and a skeleton structure for the WattDepot Browser page. Though the distribution itself is mainly for the Visualizer while still containing source code for pages in the next iteration (i.e. Browser page).

What seemed like would be natural to start working on the Browser page, Robert Brewer and Prof. Johnson decided that the next application to be developed will be the WattDepot Monitor instead. The WattDepot Monitor is an application that will display the most recent data from a chosen source, and while the application is active, will update every so often given a chosen interval.

During the meeting we established the week's To Do list which included:

1. Re-structuring of Visualizer layout
2. WattDepot Monitor
3. Multi-source functionality to Visualizer
4. Subsource capability for Visualizer
5. WattDepot Browser

(I've also ranked them in to the most to least important)

During the meeting we also delegated on who's to do what. Since there were 2 major things to be done between the 3 of us, Kendyll would handle the re-structuring and multi-source capabilities, I would handle the Monitor page, and Bao would be the go-between.

The main focus of last week Tuesday's meeting was the Monitor, so we pretty much did a run down of how the Monitor is to be set-up. This included the layout and functionality. What I accomplished for this past week was revert the trunk to before the v1.0 Distribution. I added back in the main page so that the user can select between the Visualizer and Monitor. I've also added the Wicket UI components to the page and created an Ajax behavior that changes a label on the page to show the selected Source's update interval. Even though Bao was supposed to be the go-between and facilitate my and Kendyll's work, he showed some interest in working with the Monitor so we are going to work together in creating the page.

Earlier in the week Kendyll had moved around some components in the Visualizer page and it caused the time drop-downs to no longer work. But just recently he had corrected the error by reverting to an older version and re-arranging the layout. As of now, the trunk currently has a re-arranged Visualizer and skeleton working of the Monitor.

WattDepot-Apps: Visualizer 1.0

The time has come for the first milestone in my Software Engineering class. My group and I are to unveil the first iteration of WattDepot-Apps. What we had boldly set out to do were the three applications I described in my previous posts (Visualizer, Browser, Monitor). Most of the past month was devoted to the development of the Visualizer, a web application with a User Interface that queries the WattDepot server and uses Google Visualization's Annotated Timeline/Chart to display the data.

WattDepot-App's updated Google Code Hosting site here

*Complete with featured wiki pages for end-users as well as developers curious about WattDepot and our project.

Both the stand-alone binary .jar for the Visualizer and the complete distribution .zip file can be downloaded at our Google Code site here.

The jar file is solely for the purpose of running the Visualizer whereas the distribution contains not only the classes for the Visualizer, but also the classes that are soon to be implemented, such as the Browser. There are still quite a few issues that need to be worked out with the Visualizer page, all the issues concerning the whole project can be found at the Issues Page here.

The gist of the Visualizers Issues includes:

• Multi-select capabilities
• Subsources Option

What I want to point out is that for this first milestone, what we wanted to present was "the" most completed aspect of our work. Therefore we actually downgraded the source multi-select to a drop-down menu since the multi-select checkboxes would only take the first source selected and ignore any of the other sources. We will definitely try and get the two mentioned issues completed and start working on the browser page. Those wanting to check out the trunk via SVN may do so, but v1.0 distribution and what's currently in the trunk is different. What's currently in the trunk is current work into v2.0 which is the multi-select elements.

Looking back this past month, there were a lot of constructs I had to revisit. Most of which being Wicket and Java, but I also dealt with some JavaScript, which I never touched, I even dived into some User Interface design aspects such as menu placement, browser compliance, and resolution issues.

The hardest part of this first milestone was just getting everything to work, reading up on how to implement specific elements such as Wicket's CheckboxMultipleSelect, implement JavaScript actions to invalidate options, and working with Google Visualizations. For the most part we always knew where we were headed, we just needed to get there.

An aspect I found semi-ironic was the laying out of tasks. Before and after every meeting with Kendyll and Bao, I always made sure we knew what tasks needed to be done, however, when it came time to actually do work, I still needed to see the Issues page and constantly remind myself and the others what we needed to get done.

What I've contributed to this first milestone included setting up the initial groundwork for all development, which included creating the Google Site, setting up a Continuous Integration job through Hudson, and creating the base site for WattDepot-Apps that runs through Ant. I've also added Wicket components to the Visualizer page, as well as other HTML components that is used to query WattDepot.

The next milestone we will probably resume work on this project and continue our same work habits. I believe if we maintain our work ethics and continue to output the same level, if not higher, we can truly develop the three stand-alone applications we set out to do.

WattDepot Status: Progress Retarded

It has been three weeks since this semester began and already is the first milestone for Software Engineering coming up next week.

What I thought to have started out strong with the initial setup and progress with WattDepot-Apps, has suddenly taken a huge bump in our road to completion. Although I can't blame anyone or anything in particular, a snag was bound to happen within the three weeks of working on this project.

To re-iterate our final project deliverable, WattDepot-Apps, was set to complete three stand-alone applications for the WattDepot service. This included:

• WattDepot Visualizer
• WattDepot Browser
• WattDepot Monitor

Our main focus was to work on each project before moving to the next. We compromised that it was better to have one completed, if not, near completed project, than having 3 partially functioning one.

By the end of this week, it will mark 1/4 of the semester gone by, which means the semester is in full swing, with midterms coming up, I believe it will be even more difficult to keep up the progress we once had.

For this past week, the momentum we had died down and we stood a more steady approach to things. Our weekly meeting with Robert Brewer, the WattDepot Wiz, was canceled due to inactivity. What we set out to finish by today was a working version of Visualizer with advanced User Interface components, meaning multi-select menus for sources and data types, and the initial setup of the Browser page.

What we did accomplish though is getting the Multi-select menu to render all the sources of WattDepot, setting up JavaScript to accommodate erroneous option selection, and re-designing page layout to better suite the new User Interface components.

The problems we encountered were between the different constructs we were using to get the site functioning. The base of our site is Wicket based, which is supposed to interact well with Java, however, we also need to use JavaScript in order to get Google Visualizations up and running. Between these three systems, it was hard to jumble between each of them. The way that Wicket is designed seemed to be a hassle to code JavaScript for what we needed. The most irritating I found with Wicket was that setting Default options for menus is a complete headache. When I converted the source drop-down menu to a "CheckBoxMultipleChoice" I ended up hard-coding a default value in the JavaScript of the page because I could not figure out a simple way to set defaults using Wicket.

For this week, we will have to haul double-time. Getting the multi-source selection is our top priority, once we get that done the Visualizer is pretty much complete. For the Browser page the initial workings is in progress. Unfortunately only half of the functionality can be implemented since half is Source summaries, and the other half is User data. The User data has yet to be completed, and even then, there seems to be permission issues with viewing non-public user information.