Parsing XML with SAX

There are a few ways to parse XML. The first you maybe familiar with is the DOM parser. The DOM is a tree based structure which makes up XML's structure. You can traverse the DOM to find a tag, attribute or value you are seeking. The other method I will be talking about is SAX or Simple API for XML.

Typically the difference between DOM parsing and SAX parsing is that SAX parsing reads the file as a stream, whereas DOM parsing constructs the complete structure in memory. The advantage of SAX parsing is on mobile devices with limited memory or slow connection speeds. It's also really good at parsing very large XML files that can be gigabytes in size. A disadvantage is that you cannot traverse or backtrack. SAX parsing is also a little more complicated.

In order to setup your program to work with SAX you need to understand a little bit about event handling and a quick big picture. When the stream starts reading in data, certain handlers that you setup to are called via SAX's callback methods that look for tags, attributes and values which will be called if they match the criterium that you specified. Handlers in SAX are basically method overrides that allow you to take control over what happens. There are 3 methods you typically override in SAX, the startElement method, the endElement method and the characters method. When you instantiate your Handler class and feed it your XML stream, startElement is called. You conditionally check the tag that is passed into your method. With each tag that is passed into startElement and matched to a conditional statement, you flip boolean flags that you setup to keep track of which element was traversed.

Once startElement is finished executing (the length of one tag) the characters method is called to extract the values or attributes out of that tag. Keep in mind, these methods are called by the SAX library, not you, so you are simply catching values and flipping booleans to determine if you are in a location you want to subscribe to. Inside characters you receive a String containing the values you are looking for. Typically this looks like the startElement and endElement methods, which the exception that the string is passed to an class through public mutator method that you could name ParsedData. ParsedData would contain fields such as Title, Author, ISBN for example.

Once the tag has been passed over, the endElement is called. This method does the same as startElement with the exception that the booleans you flipped to true in startElement are now flipped to false. The next element in then streamed through and the process continues.

A Diagram Representing SAX's Possible States

In my project WattDroid (my first Android application) I've implemented SAX handlers with documentation to get you started.

Some more information is located here.

WattDroid GUI Improvements and Settings Added

Recently I talked about adding a settings feature to allow any WattDepot server to be queried for data. This has now been implemented and the settings will be saved once set. Here is a screenshot of this feature:

As you can see the top field is where you type the URL of the WattDepot server and the bottom image is what will pop up if you don't have that set when you first start the application. If the URL in invalid, meaning it does not link to a WattDepot server, then you will get an error message and it will tell you to enter the correct URL.

Beyond those necessary additions, we started to style our application to make it more visually pleasing. Here is a screenshot of a temporary placeholder image. It will change once we go over a few more designs. We have added transparency to each listview item so the background is visible.

We also added a feature where if the menu button is pressed it displays our settings panel. This is useful if the user would like to make changes to the WattDepot URL and also houses a placeholders for future settings.

We still have some pending issues to resolve. These issues are creating test cases and a continuous integration system. We also would like to add locational awareness that will be used to sort the list by closest proximity.

While Android is quite a fun framework to work with, getting to learn the libraries, like any framework, can be quite a task; so I recommend spending a lot of time read others code, it has helped me a lot.

WattDroid with Hudson and Unit Testing

Over the last few days I have been studying all the options for Android Continuous Integration and Unit Testing and well there is a plethora of choices to review.

Here are a few that I have reviewed:

Ant Related:

http://code.google.com/p/autoandroid/wiki/AndroidAnt

Hudson Related:

http://www.facebook.com/note.php?note_id=499519075367

JUnit Related:

http://mylifewithandroid.blogspot.com/2008/11/junit-in-android.html

http://marakana.com/tutorials/android/junit-test-example.html

http://code.google.com/p/robotium

What I have found is that Android requires its own unit testing libraries to perform tests that use Android libraries. Normal JUnit testing will work, however, it will not replicate actual functions the user will encounter. For example, it will test that a method returns the correct value given input, but it will not test if the user presses on a certain button and a result is shown in an Activity.

The classes that deal with specific Android testing are:

ActivityUnitTestCase and ActivityInstrumentationTestCase2

(ActivityInstrumentationTestCase is now deprecated)

The android.jar file also contains normal JUnit tests. I'm in the middle of evaluating a tool called Robotium ( http://code.google.com/p/robotium/ ) as well and it provides a simpler way to test Android applications, but this is mainly geared at the blackbox perspective, otherwise the users actions and the applications responses.

Robotium offers some interesting features and members of the Android community also say it is a valuable tool to learn. Here are a few of its features:

• You can develop powerful test cases, with minimal knowledge of the application under test.
• The framework handles multiple Android activities automatically.
• Minimal time needed to write solid test cases.
• Readability of test cases is greatly improved, compared to standard instrumentation tests.
• Test cases are more robust due to the run-time binding to GUI components.
• Blazing fast test case execution.
• Integrates smoothly with Maven or Ant to run tests as part of continuous integration.
• The Syntax is quite easy to understand as you can see in these examples.

Some others have recommended EasyMock as well. I am starting to feel all these extras are becoming a distraction and will stick to learning the standard Android test case classes and look further into Hudson CI after that.

Back to WattDroid...

Currently we are working on GPS integration and theming out application. The book we have doesn't really talk much about these two topics so we ordered a more advanced book Pro Android 2. However, in the meantime I have been trying to decipher and wad my way through some of the documentation and decent progress.

Until next time...

Remy

WattDroid Beta

The first beta of WattDroid is ready to explore. It's bare bones right now, but soon there will be a lot more functionality. Currently the WattDroid application displays information about specific sources when you select the source from a list. For those of you who are wondering, "What's a Source?" well it's just a node or sensor that contains data about anything you desire. WattDroid simply finds the list of sources and displays the XML of that source as of now. We have a lot in store for this application.

Here are some screenshots to give you a good idea:

WattDroid has a Watson Icon, taken from WattDepot.



















WattDroid's old intro screen.
















About WattDroid




















Source List


















Source Info










The next features we have planned are:

Add functionality

• Incorporate GPS (locational awareness for closest dorm)
  
• Add ability for user to specify WattDepot source URL
• Add ability for user to specify refresh interval in settings

Incorporate Android Unit Testing

• Research Android Unit Testing
• Research Integration with Hudson
• Better coding standards
  

Improve the look and feel of the application

• Needs to be more graphically enticing for the target audience (freshman, sophomores)
• Develop Killer Icon (Merge Android with Watson)
• Work with Themes
• Look into transition effects
  

Make the interface more user-friendly

• Add settings when standard menu button is pressed

Check out the project and follow the User Guide or Developer Guide Wiki to Try it out.

Android Ahoy!

After a long time wishing I had the time to develop an Android application, I finally got the chance. We are calling this app "WattDroid." The idea is quite simple, we will be pulling data from WattDepot to display energy usage data from specific dorm floors at the University of Hawaii at Manoa.

When the user launches the application he or she will see a main menu where they can enter (through the settings) a URL that the application will pull the data from. Currently this will work only with WattDepot servers. Then the user will see a list of sources to choose from (sources are dorm floors). When they choose a location, the app will display a meter reading with various other data readouts.

The idea here is to keep it intuitive and consistent with other Android applications and of course fun for the users. I see this application as a way to bypass the need for an expensive energy meter as every student can now have their own meter display for free.

So far we have read the first 5 chapters of the excellent book Android and Me (A Pragmatic Bookshelf publication) and are thoroughly enjoying working tidbits of examples into our application. Some of the difficulties we have are the networking aspect, but that should be resolved shortly after this writing. We have already been able to get a list of sources (not from the server yet) into a list that displays a Toast type message. The next step will be to create another activity (Android view) to display the updated readings.

The development cycle is quite fun as well. I simply plug my Android phone into my computer and place it into debug mode, when I hit Run in Eclipse, it sends the APK over to my Android device instead of the AVD (Android Virtual Device/ the emulator), this keeps my Macbook at a lower temperature (sometimes it can get up to 180 degree Fahrenheit).

I will post screenshots next Tuesday of this application.

Brainstorming the Next Phase

We've taken a bit of a break from working on the HEEP widgets for a little while and decided to focus our time on creative ideas for the next round of design. Kevin and I had a few brainstorming sessions over Spring break to come up with ideas that would benefit the users of the HEEP website, the people of HEEP and the students who will be using the larger aspect of the project my team is working on The UH Dorm Energy Competition.

The Dorm Energy Android Application
The idea here is to make the competitors visually see how their dorm and floor is doing compared to other dorms and floors.
Let's put this into a story/scenario:
Sally grabs her Android phone and presses the UH Dorm icon on her home screen.
She sees a layout that displays many floors of a particular dorm. She swipes the screen to change which dorm that she wants more information about. When she gets to the dorm she wants to view, she sees numbers 1-6 on a building representing the floors. She wants to find out how her friend Mark is doing on the 4th floor of Freer (a Dorm at UH). She taps the number 6 on a vertical structure that represents a building. A pretty layout with live energy consumption and a simple one week graph is displayed.

The idea here is to not push too much information on the students and allow an alternative mobile vector for the competition. We believe a simple mobile application has that potential.

A Visual Javascript Application to Display Household Energy Data
This idea is still under the works. So far our idea is to create an application that can visually demonstrate a graphical depiction of Honolulu energy usage based on household data. There are many possibilities with this and we intend to explore them when the data becomes available. Currently we are looking forward to seeing what kind of infrastructure we can obtain to house the 1TB+ of data on a SQL server that obtains fresh data nightly. I predict the model will be based on OLAP and contain highly detailed information in the form of a Google Map overlay. More to come on this exciting project.

Milestone 2

We have completed 3 of our gadgets. I'd like to share what we have so far.

First off, let me mention that these gadgets are Google Gadgets for placement of your iGoogle homepage. They report information by querying a Google Spreadsheet from javascript and then displaying the appropriate visualization or dynamic content.

Our Don’t Waste Money iGoogle Gadget displays the HEEP Rebate + Money Saved. It gives the consumer a birds eye view of how much they will earn by choosing an EnergyStar model.

When you select a certain brand, it queries the spreadsheet for the relation between the brand, rebate and savings.

Our NegaWatt iGoogle Gadget displays the amount of watts saved for certain types of appliances.

The following graph displays the HCEI (Hawaii Clean Energy Initiative) goals for the projected years. It also shows real statistics for given years that have passed.

Here are two of them together on the iGoogle Page:



There are some things we would like to continue to work on in order to perfect them. Most of these have to do with white space surrounding the visualizations and other CSS refinement.

You can search for these gadgets on Google Gadgets Search or simply visit our project page:

http://wiki.github.com/remyb/heepoverflow/

Most Prototypes Complete

Today I'm glad to say that we have completed most of our prototypes based on the mock-ups I previously demonstrated.

Let's have a look:

Mock-up:

Prototype:


Mock-up:

Prototype:


After this iteration, we will be tweaking the CSS to make it look as clean as possible to a deliverable state. Next week the applications will be ready for HEEP to review.

On another note there is a quite a cool trick I found that I thought I'd share. You can use any font you like in CSS without any PHP or GD tricks. It will actually load a TTF into the client browsers memory. You can upload a TTF here:

http://www.fontsquirrel.com/fontface/generator

and get a few lines of code that will work on all browsers. Here is a cut out of what the TTF looks
like and what you would place in your CSS file.

@font-face {
 font-family: 'TizaRegular';
 src: url('tiza.eot');
 src: local('Tiza Regular'), local('Tiza'), url(data:font/truetype;charset=utf-8;
base64,AAEAAAASAQAABAAgRkZUTU5mIEMABZvIAAAAHEdERUYA2gAGAAWXPAAAACBHUE9T/ykFxgAFl3wAAAR
MR1NVQmyRdI8ABZdcAAAAIE9TLzKFzi0LAAABqAAAAGBjbWFwGBFXGwAABLwAAAHKY3Z0IAAwBj8AAAgUAAAA
EmZwZ20GWZw3AAAGiAAAAXNnYXNwABcACQAFlywAAAAQZ2x5ZrZ+zyUAAArgAAWF9GhlYWTzweoFAAABLAAAA
DZoaGVhCfIE9gAAAWQAAAAkaG10eDgKBEwAAAIIAAACtGxvY2ECplwQAAAIKAAAArhtYXhwBIou4AAAAYgAAA
AgbmFtZfXm/qwABZDUAAAE1HBvc3RZOs/WAAWVqAAAAYRwcmVwHP99nAAAB/wAAAAWAAEAAAABAABpZxRFXw8
89QAfA+gAAAAAx7FSegAAAADHsVJ6/7b/aAV2BMMAAAAIAAIAAQAAAAAAAQAABMP/aAAABcL/tv8eBXYAAQAA
AAAAAAAAAAAAAAAAAK0AAQAAAK0TpQDyE24A3gABAAAAAAAKAAACAAfLAAIAAQADA1EBkAAFAAQCvAKKAAAA
jAK8AooAAAHdADIA+gQBAgYIBwAAAAIABIAAACMAAAAAAAAAAAAAAABweXJzAEAAISAeAu7/BgAABMMAmAAA
AAEAAAAAA18DVgAAACAAAgH0AAAAAAAAAU0AAAH0AAABwwAbAv0AGwNdACIC4QAaAr8AGgPzABoBjAAbAd4A
FQH6ACECSwAVAokAJgFPACECBwAiAR8AIQKJAAgDQQAlAnQAIgPDAB8DQQAhA38AFQMfABkCuQAaA38AGgN/
ABsDNAAbAToAIQEtABsBrgAbAugAUwH0ABsCpAATAqQAGwSj//cD/f/5A9j/6QQI//MDvv/wA5X/+QQS/+UE
bv/zAln/+QLU//YERAAhA7UABAVL//cEO//zA5r/9gOuABsDcf/9BBL/+gN+AAAD1f//BDsAAARw//UFwv//
BB//6wOK//UDp//1AQj//QKJAA0BNAAOAr8AEwKyABUBkwAbBNX/9wP2//kDzP/pA83/8wPo//ADef/5BAj
/5QRu//MCHv/5Aqn/9gREACEDtQAEBTX/9wRm//MDnP/2A64AGwNd//0EBP/6A34AAAPV//8EOwAPBGX/9Q
XC//8EH//rA4r/9QOa//UBeAAVAVoAVQFHAB0BoQABAToAGwJ9ABUCkAAaA0EA1wKrABsCWP/+A0EAawGSA
AACWAACBKP/9wSj//cEo//3BKP/9wSj//cEo//3A9j/6QO+//ADvv/wA77/8AO+//ACWf/5Aln/+QJZ/+s
CWf/5A83/8wQ7//QDmv/2A5r/9gOa//YDmv/2A5r/9gQfAKwDmv/2BDsAAAQ7AAAEOwAABDsAAAOK//UEo
//3BKP/9wSj//cEo//3BKP/9wSj//cDzP/pA77/8AO+//AD6P/wA77/8AJZ//kCWf/5A0H/9wJZ//kEZv/
zA5z/9gOc//YDnP/2A5z/9gOc//YBOv+2A5z/9gQ7AA8EOwAPBDsADwQ7AA8Div/1A4r/9QNBAKYB4gAEA0
EABAES//wBJgAAAmwAAgKjAAMCjAAhAAAAAwAAAAMAAAAcAAEAAAAAAMQAAwABAAAAHAAEAKgAAAAkACAA
BAAEAH4AowCpAKsArgC0ALsAxQDdAOUA7wD9AP8C3CAUIBkgHv//AAAAIACgAKgAqwCuALQAuwDAAMcA4A
DnAPEA/wLcIBMgGCAc////4wAA/73/vP+6/7X/r/+r/6r/qP+n/6b/pf3J4JPgkOCOAAEAAAAiAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwBiAGMAZAAAAQYAAAEAAAAAAAAAAQIAAAACAAAAAAAAAA
AAAAAAAAAAAQAAAAQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1
Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGEAb3Bxc3uAhom
==) format('truetype');

Enjoy :)

Refactoring Designs

Since the last post, we have refactored our designs to better communicate with our target audience. This is more of a marketing stage in our design. We still have not yet reached the implementation phase but we hope that changes in the next week.

This is what we have for our Negawatts Generated by Rebates application now:

This is a visualization of the percentage of total rebates that were generated by certain appliances. HEEP provides rebates for certain appliances and shows consumers how much energy they did not use because of their rebates.

We decided to get rid of the Appliances Energy Savings calculator because it did not relate to HEEP at all. It also is available on other websites like EnergyStar.

We constructed a Top EnergyStar Appliance Calculator that displays the potential loss caused by NOT purchasing an EnergyStar appliance. Studies show that people are more inclined to pay attention to things that cost them money, then things that save them money.


This is our Projected Energy Generation Visualization. It shows the past and projected means of generating energy up to 2030.

This visualization shows our past and present oil consumption and a bubble that appears when you mouse over a data point for the given year.

The next few weeks we are going to produce the final prototypes of our models, a fully working example that we hope will meet the needs of HEEP and their visitors.

On a side note, I really enjoy using CampFireNow.com and BaseCampHQ.com to manage our project and communicate. Campfirenow is a great web chat based collaboration tool that lets you share files and display them in the chat area while retaining the format and markup of pasted code. It also logs your chats so if a member of the group comes late he or she can catch up, search and see what happened earlier. Basecamphq.com is an amazing project management tool that lets you do everything Google code does, but a lot more. Both are written in ROR (Ruby on Rails) and I really enjoy the way it all works. You'll have to see for yourself to know what I mean.

Stay tuned for our next update...

HEEP Design Revisions

Realizing that our last designs were a bit too complicated for the average user, we decided to play them down a bit and make a few of them simpler to use and more visually appearing. I'm learning that high level design is much more challenging then the actual implementation. As such, I think this is a really good, but difficult exercise. I am starting to see the benefits after much frustration.

Let me walk you through a few of our mock-ups:

This is the EnergyStar Refrigerator Calculator. You select an approximate date and size and it will calculate your savings based on predefined average energy usage by the appliances. The energy cost, which will fluctuate the most will be either scraped from an external source, or updated manually on a Google Spreadsheet.

This is the Oil Consumption Timeline. Looking at it will hopefully tell you what is happening. It calculates the change from last year in the amount of oil consumed (number of barrels).

This is the Energy Generation by Source Chart. It breaks down the recent and future use of certain methods of power generation.

We also have the idea of working with NegaWatts (from Wiki):

Negawatt power is the idea of creating incentives to reduce demand for electricity to ease the load at peak times or alleviate the need to build more generation plants. In theory, these negawatts can be aggregated and an arbitrage market could be created to trade these.
The term was coined by Amory Lovins, who saw a typo — "negawatt" instead of "megawatt" — in a Colorado Public Utilities Commission report. He adopted the term to describe electricity that wasn't created due to energy efficiency.[1]

The Negawatts is almost complete, but the visualization needs a bit more work. Basically it comes down to totaling up the Negawatts for the appliances.

As we get closer to picking a few top selections of these visualizations and calculators, we will start to really refine them and take feedback from different people to see what needs more work.

HEEP Update - Milestone 1

Today is the first milestone of our HEEP project. I think significant progress has been made as far as creative thinking and design has been concerned. It's like a paradigm shift from constructing from specifications to designing a project for the client. They have basically handed us the reigns to pursue what we think is best. I hope it ends that way as well.

Our plan is now to come up with as many ideas as we can think of, outside the box. We are no longer focusing solely on visualizations. We want to create applications that reflect what the user of the site would want, not necessarily what the organization would like for itself. For example, a report card for the organization is not really at the best interests of the organization, rather, a report card for products that it gives rebates on would be a wiser choice since the consumer will find that information much more useful.

Currently we have thought of a few calculators that will serve as applications in the tabs. These are being implemented in plain javascript with the use of google visualization api to fetch data from the spreadsheets into our function that does the calculations. The result is displayed for the user in an easy to interpret interface.

The Appliance Report Card

• Get top 5 Energy Star Efficient Models
• Get Cheapest Non-Energy Star Models
• All models must have similar specs
• Compare/Determine How Long Until Break Even
• Less Amount of Time is Better
• Grade Based on Time for Break Even

The Appliance Calculator

• User enters info in for 2 models
• Calculate Break Even Point
• Total Savings and amount of time (lifetime estimate)

The Cooling Degree Day Calculator

• User enters two years, their corresponding
  power usages, and a base temperature
  
• Calculates total change in power usage per cooling degree day and percent of change

The Cooling Degree vs Oahu Generation

• Power generation for two years are read
• Cooling Degree Data is read for corresponding years
• Calculates the amount of power generated per Cooling Degree Day and percent change

We expect to have 2 of these calculators available for demo in two days.

We also plan on giving HEEP a live demonstration so they can give feed back in 2 weeks.

HEEP Status Update

We have implemented a raw form of the requested Google Chart visualizations embedded in JQuery Tabs. The problem with this is that the data is displayed in a form that is not quite readable or understandable by the user. Our next step is to take the Cooling Degree Day chart and the HEEP Report card and figure out a way to make them more usable. Brainstorming ways to achieve this over the next day hopefully will give us a good result.

Our current idea for the the Cooling Degree Day data is to display a settings tab, as part of the chart, that will allow the user to input his usage values to obtain a chart that provides a useful user-centric visualization of the request.

As far as the HEEP Report Card, currently we are going to design simply that, a report card. Letters /[A-F]/ will be distributed over months to indicate HEEP's success. In order to calculate this data is a different story, it is something that we need to work with HEEP on and discuss in detail. For now we'll focus on creating creative solutions.

By Thursday we hope to have, at the least, a mockup design of the charts we will be designing.

Google Visualizations with Energy Data

After much discussing we decided that Google Visualizations would be the best way to develop an application that can be easily used and maintained by the folks at http://hawaiienergy.com/. The idea is to create 3 or 4 applications within a tabbed environment on a section of their page. This will allow visitors to interact with the data that HEEP intends to make transparent. Our applications have the following design specs:

Stoplight Style Representation for Current Power Status

• Red, yellow, and green to represent high, moderate, and low demand times
• Use their socket icon(logo) to represent the colors.

Oil Price Variance over Time

• Create Google visualization to represent oil prices as stacks of barrels
• Information updated daily

HEEP Report Card

• Report HEEP's performance Displays cost vs. power savings Metrics updated weekly

Cooling degree days

• Display relationship between cooling degree days and power usage
• One cooling degree day per degree above 65 degrees

Our first task is to learn the visualization API and then show HEEP a demo.

I will post the demo here when it is complete.

New Project Underway

Kevin, Alex and I are going to be developing an embedded web application for The Hawaii Energy Efficiency Program. They are currently contracting a web design group from Maryland to construct their website. We will be working with this both of these groups to integrate our applications together. The interesting aspect of this project is that it is entirely up to us to design, implement Kevin, Alex and I are going to be developing an embedded web application for The Hawaii Energy Efficiency Program. They are currently contracting a web design group from Maryland to construct their website. We will be working with both of these groups to integrate our applications together. The interesting aspect of this project is that it is entirely up to us to design, implement and manage to the project. There are no assignments or deadlines except the ones we make. I think this freedom will allow us to really engage the project and teach us a lot about planning and real development. Working with people in the industry will also be a plus. So far we don’t have much planned until our initial meeting on Tuesday. I hope to gain perspective on the requirements and wishes of the client during this initial meeting.

Software Engineering: My Thoughts

I really enjoyed this Software Engineering course. It was by far the most intensive, time consuming and involved class that I have taken so far. It required a lot of sacrifices in my personal life and other classes, however, it would not of been possible to do if I didn't get myself head deep in it. I enjoyed learning all the tools to make the process of developing software efficient and productive.

I found the group work most enjoyable because it's a lot more fun to see things get brought together quicker. I also liked the group aspect when everyone gets really involved and motivates each other. Of the three projects we worked on, I felt that wattdepot was the most enjoyable because it didn't have much of a user interface design aspect to it. Design to me is subjective and when you pour time and effort into something you think and everyone else agrees is great, someone is bound to not like it.

I am looking forward to Software Engineering 2 where we will be building one system the entire semester. Hopefully this will be a more open environment where the developers can set their goals, specs and project, I feel this with some direction would produce the best learning environment because the developers must love what they are doing.

I'll see you in a few weeks,

Remy

WattWaiter 2.1 Release

WattWaiter 2.1 is now released. Version 2.0 had some issues as far as the user interface was concerned. These issues mostly dealt with very small resolution screens (1024x768). We have since fixed this and changed the overall appearance to reflect a more standard interface without much eyecandy.

If you are wondering what WattWaiter is read here:

"Wattwaiter is a web application that provides a visual display of carbon intensities for a given day. This information can be used by consumers to adjust their electrical usage and become “smart” consumers. By observing carbon intensities, consumers can determine which times during the day are most efficient for electrical usage. This benefits the consumer by allowing usage of lower costing electricity and the electric company by balancing their load."

This project was a learning experience. It seems that abstraction using Wicket, when dealing with web technologies, takes you away from what is really going on. It claims to offer state on top of the stateless protocol HTTP like it invented sessions or something. While it does do this, you must specifically implement this feature, otherwise users will share the same instance. PHP offers this right out of the box and spawns isolated threads for each connection. Wicket claims that it decreases development time and while it may after a lot of experience with it, it seems that recompiling all your files just to see the changes in your HTML, CSS or Java each time you edit source is quite annoying and time consuming. PHP compiles files on the fly, meaning I can change the a file and just refresh. When dealing with elements such as lists, you have to go through quite a process just to make that work.

However, I am quite biased since I have years of experience with the php/mysql/apache stack and find that it there is much more documentation and tutorials (which Wicket really lacks). That said, Wicket is a framework and should be treated as such. It aims to provide a better way to create web applications and for some I guess it does.

If I had to choose a framework for PHP, I would choose CodeIgniter because it is lightweight, easy to learn (a few hours and you've learned the whole framework) and provides various classes that you are likely to use often. It offers everything you could possibly need as well as easy object oriented interfaces to databases. It provides the abstraction you want with a MVC design and benchmarking is part of the package. It also allows you to create an app and package it up to bring it anywhere, you just edit the configuration on the new server and you are ready to launch.

Take a look at the table of contents here for the various classes.

Other PHP frameworks are a huge mess and have enormous libraries to drag around and load like PEAR. If you want rapid development in PHP, I suggest this lightweight option.

Stepping off the soapbox....

During the development of WattWaiter, I enjoyed the company of my co-developers, we seemed to work together quite well. As we divided up the work, everything fell into place because of good communication. We had daily meetings on IRC with a bot I wrote in Python that screenscraped the commit log from Google Code into our channel. It helped a lot because we wouldn't have to repeatedly say "I committed, update, see if that works"..."What did you update?....." etc. We used issue management to manage our tasks like any developer would and although we all know who is doing what, due to the small size of our group, it still served as a good reminder. If this wasn't there I would probably do someone else's work.

You can view the WattWaiter page here.

You can directly download the executable jar file for version 2.1 here.

Here is our 2.0 screenshot:

Here is a 2.1 Screenshot:

Eco-Depot Code Review

I performed a review on the Eco-Depot system. My summary is at the bottom if you don't wish to read through all the details, otherwise please make suggestions back to me about the quality of my review, I'd like to hear it.


Eco-Depot Review
reviewer: Remy Baumgarten


A. Review the build

The first part of any review is to verify that the system builds and passes automated quality assurance.

A1. Download the system, build it, and run any automated quality assurance checks (use "ant -f verify.build.xml"). If any errors occur, note these in your review.

BUILD SUCCESSFUL

B. Review system usage

If the system builds, the next step is to play with it.

B1. Run the system. Exercise as much of its functionality as possible. Does it implement all of the required features?

I ran the application with 11/23/2009 and it worked as it is supposed to.

B2. Try to break the system by providing it with unexpected input. Can you make the system crash or generate a stack dump? If so, note the input that caused the failure.

By deleting the date, and clicking submit it goes to 11/24/2009 instead of today, 23 or erroring out.

B3. Evaluate the user interface to the system. If it's a web app, is the interface self-explanatory? Does the system require unnecessary scrolling to see the data, or can it all fit in a single screen? Does it seem "professional", or does it look "amateurish"?

Data fits in 1 page. Decimal places should be eliminated. The key is good, it lets us know what we are looking at. A bit of CSS/JS code would be nice.

C. Review the JavaDocs.

Download the system and generate the javadocs (use "ant -f javadoc.build.xml"). Navigate to the build/javadoc folder and click on index.html to display the JavaDocs in a browser. Read through the JavaDocs and assess the following:

C1. Does the System Summary (provided in an overview.html file) provide an high-level description of the purpose of the system? Does it explain how each of the packages in the system relate to each other? Is the first sentence self-contained?

"A Wicket application of EcoDepot build system." This should be elaborated to describe the application briefly.

C2. Do the Package Summaries (provided in package.html files) provide a high-level description of the purpose of the package? Do they explain how the classes in the package related to each other? Is the first sentence self-contained?

Yes. This is very helpful in understanding what packages purposes are.

C3. Do the Class Summaries (provided at the top of each .java file) provide a high-level description of the purpose of the class? Does it provide sample code for clients of the class, if useful? Is the first sentence self-contained?

There is a highlevel description. There is no sample code. This would be helpful if someone wanted to use your class.

C4. Do the Method Summaries (provided before each method) explain, from a client-perspective, what the method does? Do they avoid giving away internal implementation details that could change? Do they document any side-effects of the method invocation? (Note that you can click on the method name to see the source code for the method, which is helpful to assessing the correctness and quality of the javadoc.)

The methods provided what I found sufficient documentation. setThresholds is a good example of this.

C5. Please review Chapter 4 of the Elements of Java Style for additional JavaDoc best practices, and check for compliance.

Very good.

D. Review the names

One of the most important (if not the most important) form of documentation in any software system is the choice of names for program elements, such as packages, classes, methods, instance variables, and parameters. Due to evolution in requirements and design changes, the name originally chosen for a program element may no longer be appropriate or optimal. An important goal of review is to ensure that the names of program elements are well suited to their function. Due to the refactoring capabilities in modern IDEs such as Eclipse, renaming need not be a burden.

D1. Do another pass through the JavaDocs, this time concentrating on the names of packages, classes, and methods. Are these names well chosen? Do they conform to the best practices in Elements of Java Style, Chapter 3? Can you propose better names?

I would propose the use of names that are not prepended by the name of the project, since these files are already in the project names package, it is redundant.

D2. Once you have reviewed the names displayed in the JavaDocs, review the source code for internal names in the same way.

Looking throughout the source I found the names to explain exactly what their purpose reflects. Easy to follow.

E. Review the testing.

The system should provide a useful set of test cases.

E1. Run Emma or some other code coverage tool on the system ("ant -f emma.build.xml"). Look at the uncovered code in order to understand one aspect of the limitations of the testing.

emma reports ~65-85% coverage. There are 4 test cases. They test for various conditions, not strictly happy paths. A few more tests to increase the coverage and the separation of tests into their own classes would be nice.

E2. Review the test cases. Is each component of the system exercised by a corresponding test class? Do the test cases exercise more than "happy path" behaviors?

Described above.

E3. Review the test output. Under default conditions, the test cases should not generate any output of their own. It output is desired for debugging purposes, it should be controlled by (for example) a System property.

There is no extraneous output.

F. Review the package design

The JavaDoc review is focussed on whether the system design is correctly explained. In this section, you start to look at whether the system design is itself correct.

F1. Consider the set of packages in the system. Does this reflect a logical structure for the program? Are the contents of each package related to each other, or do some package contain classes with widely divergent function? Can you think of a better package-level structure for the system?

After reviewing this requirement, I found that the classes are logically divided, yet lack packages.

G. Review the class design

Examine each class implementation with respect to at least the following issues.

G1. Examine its internal structure in terms of its instance variables and methods. Does the class accomplish a single, well-defined task? If not, suggest how it could be divided into two or more classes.

Yes, classes are logically divided.

G2. Are the set of instance variables appropriate for this class? If not, suggest a better way to organize its internal state.

Yes, the instance variables are related to the class.

G3. Does the class present a useful, but minimal interface to clients? In other words, are methods made private whenever possible? If not, which methods should be made private in order to improve the quality of the class interface to its clients?

There are public methods, but they should be public because they are needed by other classes. However, a restructure of this class could allow one method to be public and use internal methods (private) within.

H. Review the method design

Examine each method implementation with respect to at least the following issues.

H1. Does the method accomplish a single thing? If not, suggest how to divide it into two or more methods.

Yes, however I suggest refactoring as a wicket application for creating HTML and embedding CSS and use things such as labels, ListViews/Repeaters (for tables) instead of building strings to display on index.

H2. Is the method simple and easy to understand? Is it overly long? Does it have an overly complicated internal structure (branching and looping)? If so, suggest how to refactor it into a more simple design.

Displayed above.

H3. Does the method have a large number of side-effects? (Side effects are when the result of the method's operation is not reflected purely in its return value. Methods have side-effects when they alter the external environment through changing instance variables or other system state. All "void" methods express the results of their computation purely through side-effect.) In general, systems in which most methods have few or zero side-effects are easier to test, understand, and enhance. If a method has a large number of side-effects, try to think about ways to reduce them. (Note that this may involve a major redesign of the system in some cases.)

The methods are mainly self contained.

I. Check for common look and feel

I1. Is the code implemented consistently throughout the system, or do different sections look like they were implemented by different people? If so, provide examples of places with inconsistencies.

The code looks consistent.

J. Review the documentation

J1. Does the project home page provide a concise and informative summary of what the system accomplishes? Does it provide a screen dump that illustrates what the system does?

There is no screenshot or a clear description on the home page.

J2. Is there a UserGuide wiki page? Does it explain how to download an executable binary of the system? Does it explain the major functionality of the system and how to obtain it? Are there screen images when appropriate to guide use? Try following the instructions: do they work?

The userguide is detailed, and it explains exactly what the applications purpose is.

J3. Is there a DeveloperGuide wiki page? Does it explain how to download the sources and build the system? Does it provide guidance on how to extend the system? Try following the instructions: do they work?

Yes this was well written. It even describes how to setup the development environment and includes a link to the formatting xml configuration.

K. Review the Software ICU data

For this step, you must ask the Hackystat project owner to add you as a spectator to their project so you can invoke the Software ICU for their system. Run the Software ICU on the project.

K1. Is the Software ICU gathering data consistently and reliably? If not, what data appears to be missing, and why might it be missing?

Yes the data is present and shows a little data.

K2. If data is present, what does it tell you about the quality of the source code? Is the current level high, medium, or low? What are the trends in quality?




Coverage improved, complexity increased, coupling improved, churn went down a lot probably because of a lot of large commits. Dev time only shows one spike and well as commit and the build shows one spike as well. It looks like this project was done last minute from the looks of the stats.

K3. If data is present, what does it tell you about the group process? Are all members contributing equally and consistently?

It looks like 3 members contributed and one didn't build at all, but this could be due to improper setup with sensors.

L. Review Issue management

Go to the project home page, then click on the Issues tab. Next, search for "All Issues" to retrieve a page containing all issues, both open and closed. Next, select "Grid" view, and select "Owner" for the rows. The result should be a page of issues in a grid layout, where each rows shows all of the issues (both open and closed) for a particular project member.

L1. Does the issue management page indicate that the project members are doing planning? In other words, that they have broken down the project into a reasonable set of issues (i.e tasks taking one day or longer are represented by an issue)?

There are no issues present.

L2. Does the issue management page indicate that each member is contributing to the project? Does each member have at least one current "open" task? Has each member completed a reasonable number of tasks?

There are no issues present.

M. Review continuous integration

Go to the Hudson server, login, and select the continuous integration job associated with the project.

M1. Is the system being built regularly due to commits? Are there long periods (i.e. longer than a day) when there are no commits?

When the group started, there was a period of 5 days without any commits, and then activity toward the end.

M2. If the system build fails, are there situations in which the system stayed in a failed state for a long period of time (i.e. longer than an hour)?

Failed builds were fixed immediately.

M3. Is there a continuous integration job? If so, check the configuration. Is it correct? Will it be triggered by a commit? Check the console output from one of the invocations. Are the appropriate Ant tasks (i.e. checkstyle, pmd, junit, etc.) being executed?

Yes, it pulls svn every 5 minutes and builds with the ant tasks.

M4. Is there a daily build job? If so, check the configuration. Is it correct? Will the job be run regularly once a day? Check the console output from one of the invocations. Are the appropriate Ant tasks for a daily build job (i.e. coverage, coupling, complexity, size, etc.) being executed?

Yes. Based on the console output all the tasks are being run.

Summary

Based upon the above sections, provide an overall summary of your perspective on the project. Does it fulfill the requirements, and if not, why not? Is the code of reasonable quality based upon its design, implementation, and quality assurance techniques? If not, what should be improved? Does the group appear to be functioning well based upon Software ICU, Issue, and Continuous Integration data? If not, what appears to be wrong and what should they do to improve?

Good job on this project. I think working on this before it's too late might make it easier later if time is spent learning the wicket way of doing things, so time isn't wasted rewriting code. A little CSS would help too as well as packing the product appropriately. There are some great tutorials here http://w3schools.com/ that will help with CSS. I think this project has a lot of potential given time and effort. Good work.

WattWaiter 1.0 Released

My software development group has been working on a Wicket application that queries a server to retrieve data from the Oahu Power Grid and display an interface for a particular days power consumption or carbon intensities. We named this program WattWaiter.

Here is a brief overview of what the project is about:

Wattwaiter is a web application that provides a visual display of carbon intensities for a given day. This information can be used by consumers to adjust their electrical usage and become “smart” consumers. By observing carbon intensities, consumers can determine which times during the day are most efficient for electrical usage. This benefits the consumer by allowing usage of lower costing electricity and the electric company by balancing their load.

Carbon intensities are displayed in hourly increments with green, yellow, and red flags corresponding to low, moderate, and high carbon intensities respectively. Users are now able to adjust their electricity usage to coincide with lower intensity periods. A sample Wattwaiter display is shown below.

Here is a screenshot of the early stages of WattWaiter:

Wicket is a bit rough to learn, but reading the Wicket book and the wiki on Wicket helped a lot. I was soon able to program the Wicket way. Coming from a PHP, MySQL background, I found this a bit overkill, but I am sure that this kind of setup will pay off when the application grows.

Working in this team is really nice because I like to see all the assigned tasks come together. Communication between members is also really fun because we got to develop strategies and gain others perspectives as well as work with others code.

Honestly, I am quite happy with the way our system was designed, but not being an expert or even novice at Wicket at this point, I can guess that there will be a lot of room for improvement and better ways to do things.

Here is a screenshot of the software ICU (intensive care unit) as described in a previous post. This will give you an idea of how well our project is performing.




As you can see, we need to commit more often (churn). The problem with this is if there is a big overhaul in the project, or we need to redesign something, there's no way around this, because you're not going to commit. Also we need to develop more knowledge about the Wicket testing framework. We are having some issues developing proper tests for this.

Our Project Page is hosted here: http://code.google.com/p/wattwaiter/

Our distribution is here: http://wattwaiter.googlecode.com/files/wattwaiter-1.0.1122.zip

Our Wiki, User Guides and Dev Guides are here: http://code.google.com/p/wattwaiter/w/list

WattDepot Version 2.0 Released

WattDepot v2.0 implements a few more query options and employs an updated API for the wattdepotclient class. The necessary changes that were in our code reviewers notes were also satisfied. Since we already had the design correct, changes were minimal. We have a lot of unit tests but it seems that we probably need some more since our code coverage is at about 82%.

Teamwork in version two was just as good as it was in v1.0's development phase. We met regularly on IRC, and with the assistance of a python bot I wrote, we get commit logs posted directly into the channel. We discuss design and divide the work there and on the phone.

What was really interesting was the opportunity to employ a new tool called Hackystat to measure the health of our project.

Here is a screenshot:



Hackystat is a great way to monitor your project as it computes various statistics about how your project is performing.

"Hackystat is an open source framework for collection, analysis, visualization, interpretation, annotation, and dissemination of software development process and product data."

Hackystat works by relying on the user to install sensors in their project as well as their IDE. It dispatches data to the Hackystat server every 5 minutes (in IDE) and everytime ant is invoked. The kind of information that is transmitted is related to the files your working on and the time you spend on them.

This application can answer questions like these:

• What day and time during the month was Oahu energy usage at its highest? How many MW was this?

November [2,3,4,5,6,9,10,11,12,13,16,17,18,19,20,23,24,25,26,27] at 995MW

• What day and time during the month was Oahu energy usage at its lowest? How many MW was this?

November [2,3,4,5,6,9,10,11,12,13,16,17,18,19,20,23,24,25,26,27] at 493MW

• What day during the month did Oahu consume the most energy? How many MWh was this?

There is no data for this at the moment.

• What day during the month did Oahu consume the least energy? How many MWh was this?

There is no data for this at the moment.

• What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)? How many lbs of carbon were emitted?

November [4,5,16,17,30] at 29,959lbs

• What day during the month did Oahu emit the least carbon (i.e. the "cleanest" day)? How many lbs of carbon were emitted?

November [7,8] at 22,908lbs

You can download our distribution here: WattDepot CLI v2.0

1-on-1 Code Reviews

The Elua Branch had one-on-one code reviews today. I found this mildly useful in the respect that both parties were able to elaborate a little more on the reports. However, I found the reports much more detailed, and therefore useful. I think code reviews should be about going over every line in the code after the reviewer has read and understood the program, perhaps more then the author.

The reviews in general from the reports were very helpful simply because when someone else looks at your code, they notice things you didn't. For the next project I am hoping to get more time with the reviewer and hope they read the code, instead of glance at it looking for specific conventions.