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.

WattDepot Visualizer Underway

For this past week in Software Engineering, I have been working on the first stand-alone web application for WattDepot-Apps, the WattDepot Visualizer. The name hasn't officially been decided, but I'm just sticking with WattDepot Visualizer for now. So far, I believe that project WattDepot-Apps has met our set deadlines and is currently progressing nicely.

First off, by the next day, Tuesday 1/19 team WattDepot-Apps had a meeting with Prof. Johnson to talk about the general direction we'll be heading. We decided on which Google Visualization to implement, and with much debate had got it down to either Annotated Timeline or Multi-colored Bar Graph. Considering the pros and cons of each, it was decided that an Annotated Timeline would be much cleaner to use.

On the same day we discussed the overall functionality of what each page should do. The game plan is to complete one application at a time so most of the discussion was geared towards the functionality of the Visualizer page.

To split up the work, I would be the one to set-up the initial ground work for everything to do done. This included an initial Java/Wicket project that will be hosted in the Google Project Hosting - WattDepot Apps. Apply Software Engineering techniques such as Continuous Integration through Hudson and automated Quality Assurance tools with Ant.

Bao seemed to be the most eager and strong in JavaScript so he would be the one to set-up the initial JavaScript that will take the input through the UI elements on the page, and create a query to be sent to WattDepot, and hand the response to Google Visualization and output the Annotated Timeline.

After the Bao completes the initial JavaScripts, it would be Kendyll's job to convert the Annotated Timeline into another visualization, be a Table, so the user can interactively inspect WattDepot data through hard numbers instead of just a graph. Looking for project Carbonometer for inspiration, Kendyll also will look into why their visualization currently no longer works, which was also brought up at the meeting.

By 1/21, I uploaded an initial site that laid the general work area that the whole group will be using. For now, the project contains basic UI elements. The major thing that will be changed is the drop-down menus. They will eventually be changed to multi-selection boxes so users can select multiple sources and display multiple data types in a single visualization. But for now in this initial set-up we just want to get a running visualizer working that actually query's the WattDepot server, get a response, and pass that response to Google and get the visualizer to display on the page.

The end of this past weekend, Bao had completed JavaScripting and managed to get the visualizer up and running. Now that the visualizer is in place, Kendyll now takes over and will add in data tabulation, as well as look at some minor aesthetics since right now the page is pretty plain.

I'd say that the most difficult obstacles this week was planning out a general layout for all the User Interface elements such as drop-down boxes, date pickers, the visualization itself, and meeting general functionality requirements. There were a few coding issues that had to be addressed, but we got through them. We see each other everyday so the project is constantly being talked about and comments/suggestions are always being thrown around.

The goals for this week is to improve upon the current visualizer and hopefully get a start on the Browser page. To improve on the visualizer we will need to switch out drop-down menus and replace them with multi-selection elements and set-up more advanced JavaScript code that will gray out certain options depending on what the user selects. I believe this will be the most difficult stage since it deals more intense coding that any other step.

ICS 414: Software Engineering Season 2

It's the start of a new semester and for this one, I'm currently taking the second half of Software Engineering. Prof. Johnson, the same professor as last semester's ICS 413, is teaching this semester's ICS 414.

Continuing off from last semester, where the last stages of our final project was based on the idea of saving energy and going green, we are continuing with project WattDepot, but this time we are working together with graduates, and outside organizations such as HEEP - Hawai'i Energy Efficiency Program to expand the idea of going green and saving energy.

There were many ideas that were pitched on our first day.

Here are some possible sub-projects that are currently underway:

WattDepot apps:

    • A set of stand-alone webapps for WattDepot.

Google Stoplight Visualization:

    • General purpose stoplight widget.

Hawaii Energy Efficiency Program apps:

    • Oahu grid data inside the HEEP website.

Kukui Cup technology prototypes:

    • Dorm energy competition website.

Kukui Cup competition design:

    • Content and structure of the competition.

Energy meter design:

    • Hardware and software specs for dorm energy meters.

There will be 4 milestones throughout the semester, at each milestone we will be give a final report and a deliverable on what we accomplished.

For this first milestone, I am working in project WattDepot-Apps. For this project, I feel I am on familiar grounds since this is probably the only project that's almost exactly like what we were doing last semester. Essentially, for WattDepot-Apps we want to quickly visualize the WattDepot repository using Google Visualizations to accomplish this.

For WattDepot-Apps, there are 3 possible stand-alone apps we will be taking on:

WattDepotVisualizer:

    • Use Google Visualizations to interactively display various data from the WattDepot service.

WattDepotBrowser:

    • Interactively inspect WattDepot

WattDepotMonitor:

    • Provide real-time updates and automatically push recent data w/o constantly polling WattDepot.

We were assigned our groups last week Thursday and have begun the organization process. Within the past week we have set up our initial Google Project Hosting named WattDepot-Apps right now it's not much to look at, but we set up Issues for each member.

For inspiration we've taken a look at last semesters proto-type projects Carbonometer and Greenometer. The base functionality exists, but they require some tweaking in order to get each up to specifics.

Some of the difficulties in this first stage was how to divide the work. Since this was relatively new, and the deadlines were a little strict, it's hard to tell how much of each sub-project we would actually get finished. For this reason, we decided to take each sub-project as a 1 week deadline, and micro-manage each part. What we've decided to do can be summarized by looking at our Issues Page in our Google Project, I suggest clicking on Grid View to get a more organized view of what each person in our group is doing. Most of the initial tasks are research and determining what things we should add. Some of the more immediate coding aspects are setting up the initial site for each stand-alone application to run.

Our goal for this week is to get an initial site uploaded to the trunk of your project. The bare skeleton will have atleast 1 page, for the Google Visualization, Wicket UI elements, a test case, and also JavaScript to test querying WattDepot. Probably about mid-way through the week we will have settled on which Google Visualization to implement, and also start brainstorming on display elements for the WattDepotBrowser.

Greenometer v2.0: Saving Green$ While Going Green

The final project for my Software Engineering class was to polish my group's first iteration of the Wicket Application: Greenometer. Continuing from my previous post about creating Greenometer, this blog post is my final overall thoughts on the whole process. The final specifications for version 2.0 were released here.

Greenometer v2.0 can be downloaded here.

Prof. Johnson had originally planned for us to make a v1.1 release, specifications found here, he decided to forgo the due date of v1.1 and have v2.0 due instead, reason being v2.0 should have all revisions and changes that would have been made in v1.1.

So, for the last month of the semester I have been constantly working around the clock with my group members to get the specifications for v2.0 done. I have gotten more acquainted with using Wicket in combination with Java and took on various tasks that dealt with the actual UI of our interface, to the actual source code, and testing.

My journey into first semester Software Engineering - ICS 413 certainly gave me a little taste of every aspect of being a software engineer. I learned the group collaboration process, which entails splitting group work, getting group members motivated to participate, and making sure the project is still on schedule, all while having an overall great time. The coding aspects seemed to revolve around learning how to create test cases and learning the different between high coverage and quality coverage. There is definitely a difference between creating a functional interface versus a quality interface.

Prof. Johnson had stressed that although creating a quality end product is the ultimate goal, a partially complete system that's high quality is better than having a system that's partially tested and mostly functional.

Our final project features 5 pages:

• Home
• Stop Light
• Grid
• Concepts
• Contact Us

As noted in my previous post regarding this project, the functionality of this application is to provide users with detailed information about the Oahu power grid. In an attempt to gain users attention about Going Green and saving energy. Our simulated application allows its users to view the energy generated at specific sources given a date or range of dates.

Project Details
Home
The home page briefly describes the applications purpose and it's functionality, mainly outlining the other 4 pages; Stop Light, Grid, Concepts, and Contact Us.

Stop Light
This page features a stop light that shows either red, yellow, or green depending on the Carbon Intensity (lbs CO2 / MWh) of the current time. This pages queries the WattDepot and gathers carbon intensities for the whole day, then determines the color value for the current time.

Grid
The grid features a Google Chart, either a Bar or Line chosen by the user, based on the Energy Emitted (MWh). The user can also specify which source he/she wants to view. It's currently defaulted to the overall Oahu power grid, but can be changed via a drop down menu.

Concepts
This page outlines the motivation for the application and gives in-depth explanation how how to understand and use the Grid and Stop Light pages.

Contact Us
Provides the projects Google Site, Discussion Group, and a link to each developers Professional Portfolio.

From Robots to Energy Grids: Software Engineering Reflection

Prof. Johnson's ICS Software Engineering class was a unique experience this semester. It was the first class that actually made me feel like a Computer Scientist. Working towards a real-world problem, collaborating with others, and learning new tools all made it surreal and thrilling. Granted this course takes a lot out of you, at times I felt like the assignments didn't bear enough time and that I had to focus most of my energies into this course. This course felt like a job and my pay was my final grade.

What I found most valuable were the new software engineering tools such as Ant, Subversion, and Quality Assurance tools, JUnit, Checklist, PMD, and FindBugs. For the assignments that we did, from Robocode, to Wattdepot, to Wicket, it was hard to find a balance between Quality and Functionality. Prof. Johnson constantly encouraged us to create test cases as we developed our projects, but I found it difficult to come up with what aspects to test. Testing takes a considerable amount of time with every run of Ant. JUnit would take an excess amount of time to complete and it seemed like it hindered the overall time spent waiting for the project to pass verify.

The group aspect gave me another take at what it is to collaborate with others, especially with those in my field. It seemed that the group went only as far as the strongest person. Sure everyone has their forte, but doing everything shouldn't be one of them. It was hard to find an even split of work for everyone to do. There was always some aspect that bled into another, and it was hard not to just work on a single method or class without waiting for someone to commit their changes.

We were introduced to an array of technologies and experienced many different aspects of being a software engineer. We were fortunate enough to have coded in Java throughout the semester, a language that has been drilled into my brain every since my beginning semesters as an ICS student. Though, the one thing that I would like to learn more about is the framework for planning. Splitting the work load is always a big issue. How do you come across as knowledgeable rather than bossy? Or try and get someone to carry their own weight in a tactful way that doesn't sound too threatening. Indeed, it might have turned out differently if we had everyone in our group share what are strengths and weaknesses were. However, group work isn't something that is deeply encourage in the lower levels of ICS, so it takes some getting used to the concept of collaboration and the sharing of ideas.

Learning a new system and how to use it such as WattDepotClient, and learning a new language, via Wicket, are the types of things expected of every Computer Scientist in order to keep up in this field.