Monthly Archives: November 2009

WattDepot has persistence

The Derby persistence implementation is now complete. This week I will start performance testing the Derby persistence implementation, and work on the GVisualizationServlet so we can visualize virtual sources. Loading default data into WattDepot using Derby for storage (no network traffic) is running at ~876 sensor data entries per second, which seems pretty good.

Plans from last week:

  • Remove last of HashMap code from DerbyStorageImplementation
    • done, along with some other cleanup (like running unit tests on both DB implementations)
  • Start performance testing of Derby storage implementation
    • just started

Other accomplishments from last week:

  • Ate lots of delicious food

Pointers to work products:

Plans for this week:

  • Test performance of Derby implementation
  • Make GVisualizationServlet work with virtual sources
  • Review grant proposal?
  • Close some more WattDepot open issues

Cool links:

Advertisements

WattDepot Derby storage almost complete

The Derby persistence implementation is mostly complete. SensorData is temporarily still stored both in memory and in Derby, to simplify the initial implementation. The next steps during this short week are to remove the final in-memory tables, and start performance testing the Derby persistence implementation.

Plans from last week:

  • Keep working on DerbyStorageImplementation
    • almost done
  • Finish implementing missing methods in REST API
    • not done, deferred until Derby work is done

Other accomplishments from last week:

  • Wrote up directions on running WattDepot locally

Pointers to work products:

Plans for this week:

  • Remove last of HashMap code from DerbyStorageImplementation
  • Start performance testing of Derby storage implementation

Cool links:

  • New acronym I encountered: LOHAS. Lifestyles of Health and Sustainability (LOHAS) is a demographic defining a particular market segment related to sustainable living, “green” ecological initiatives, and generally composed of a relatively upscale and well-educated population segment.

WattDepot presentation & Derby started

Last week was holiday-shortened by Veterans’ Day. I spent most of my time working on my slides for my ICS 690 presentation, and helping the REIS seminar substitute videographer. Now that the presentation is done, I have begun implementing persistence in WattDepot using Derby.

Plans from last week:

  • Finish slides for presentation to ICS 690
    • done
  • Start working on DerbyStorageImplementation
    • done

Other accomplishments from last week:

  • Finally got video from 11/5/2009 REIS seminar uploaded
  • Attended ITS update seminar
  • Upgraded to 64-bit Cocoa version of Eclipse
  • Wrote up my Java 1.6 & Eclipse experiences

Pointers to work products:

Plans for this week:

  • Keep working on DerbyStorageImplementation
  • Finish implementing missing methods in REST API

Cool links:

Java 1.6 & Eclipse on Mac OS X

These are some notes on using Java 1.6 on Mac OS X with Eclipse.

Mac OS X lagged behind for some time on adopting Java 1.6, but it was finally released as Java for Mac OS X 10.5 Update 1. Unfortunately, this release has some limitations: it only runs in 64-bit mode and only on Mac OS X 10.5 (Leopard). This meant no Java 1.6 support on Mac OS X 10.4, no support for PowerPC systems, and no support on the early 32-bit Intel Macs released in 2006.

To make Java 1.6 the default Java execution environment, run the Java Preferences application (found in the Utilities subfolder of the Applications folder). There you can drag the Java versions into any order you wish for both applications and applets. So to default to using Java 1.6 for everything, you can just drag Java SE 6 to the top of both the application and applet lists. The Java Preferences application will change around symlinks to correspond to your new choices. Mac OS X 10.6 (Snow Leopard) appears to include only Java SE 6, but includes both 32 and 64-bit versions, so it should allow Java 1.6 to be run on the oldest Intel Macs (no PPC because Snow Leopard does not support PPC).

Some command line scripts expect the JAVA_HOME environment variable to be set to the directory that contains the Java distribution being used. Also, some scripts might require different versions of Java. To support this, Apple introduced a new utility called /usr/libexec/java_home. By default, java_home just returns the home value appropriate based on the selection in the Java Preferences utility, but command line arguments can request different versions (see the manual page linked earlier). The output of java_home is intended to be assigned to the JAVA_HOME environment variable in a shell initialization script (like .profile or .cshrc).

This brings us to Eclipse, the Java development environment. Eclipse can be used to develop for multiple Java versions. When creating a Java project, Eclipse prompts for the desired JRE version in the new project dialog box. To ensure that Eclipse tracks the language differences between versions, also select the desired version in Preferences->Java->Compiler->Compiler compliance level to match your project.

However, despite these changes, Eclipse itself does not necessarily run using the Java version being used for the project being developed. Initially, the latest version of Eclipse (3.5) was released only in 32-bit mode for both Carbon (an older and deprecated Mac OS API) and Cocoa (the modern Mac OS API). Since Leopard only supported Java 1.6 in 64-bit mode, this meant that Eclipse was always running under Java 1.5. With the release of Eclipse 3.5.1, there are now 64-bit Cocoa downloads available, and these will run under Java 1.6. For some users, this may not be important, but for those doing Eclipse tool development (such as the Hackystat Eclipse sensor) it is very helpful. I use JAXB in some of my Ant build scripts, and JAXB is built into Java 1.6 but not Java 1.5. When running Eclipse in Java 1.5, many of my Ant scripts report spurious errors about being unable to locate JAXBException, but these all vanish when running Eclipse under Java 1.6. I should note that at least some people disagree with this advice, and suggest using the 32-bit Cocoa version on Leopard instead of the 64-bit version. Everyone apparently agrees that on Snow Leopard you want the 64-bit Cocoa version of Eclipse (unless you are on a 32-bit Intel Mac).

So if you want to use Java 1.6 for your application and run Eclipse under Java 1.6 there are two options:

  • Use Mac OS X 10.5 Leopard (with all software updates) on a Core 2 Duo Intel Mac, with Java Preferences set to use Java SE 6 as the default Java version, and use the 64-bit Cocoa version of Eclipse 3.5.1.
  • Use Mac OS X 10.6 Snow Leopard on an Intel Mac, and use the 64-bit Cocoa version of Eclipse 3.5.1 [note, I have not specifically tested this configuration, but it should work. Confirmed, this works]

Yet more WattDepot work

Last week I got WattDepot ready for the next ICS 413/613 assignment. This included adding fuel types to each of the sources, and then implementing each of the new CLI commands to ensure that they could actually be implemented 🙂 Along the way I made some changes to the client that only became apparent when running the client independent of the server.

I also changed the server so that it can load default resources from one big file instead of one resource per file. This greatly speeds startup when there are 100K+ resources to load (like Oscar-generated sensor data for 2 months).

I’m still working on slides for my presentation for ICS 690 this week. After that is done, I will shift to working on persistence in WattDepot using Derby.

Plans from last week:

  • Turn TODO.txt into Google Code issues
    • done
  • Implement instantaneous carbon emission rate resource in WattDepot
    • not done, ended up using emissions over 1 hr of energy as basic measure
  • Write up code review description for Philip
    • not done
  • Prepare draft presentation for ICS 690
    • in progress
  • Make GVisualizationServlet support virtual sources
    • not done
  • Start working on DerbyStorageImplementation
    • not done

Other accomplishments from last week:

  • Prepared documents for REIS RA renewal application
  • Sped up WattDepot server startup from minutes to a few seconds
  • Implemented ICS 413/613 CLI assignment
  • More problematic video from REIS seminar. Double Arg.

Pointers to work products:

Plans for this week:

  • Finish slides for presentation to ICS 690
  • Start working on DerbyStorageImplementation

Cool links:

  • N/A

Refactoring WattDepot

I spent most of last week working on refactoring some cruft out of WattDepot. The core data types (Source, SensorData, and User) now all have proper constructors and all the code that was in utility classes has been folded into the datatypes themselves. This makes the rest of the system easier to read, but it means it will be a pain if I need to modify the XML schema in the future. If I need to make schema modifications, perhaps I will use the JAXB schema compiler in the other direction to go from code to XML schema.

There is still more refactoring that needs to be done, especially around the interpolated resources. I need to start creating issues in the Google Code site instead of my current tracking via TODO.txt.

Next week on Thursday 11/12 I will be giving an hour-long presentation on my research. Philip will be out of the office for the latter half of that week, so I want to have a draft presentation ready by the end of this week. The other important deliverable for this week is a carbon emission rate resource for WattDepot, which will be needed for the next ICS 413/613 assignment.

Other WattDepot features that need to be implemented are persistence and bringing the Google visualization servlet up to the rest of WattDepot (supporting virtual sources, authentication, etc).

Plans from last week:

  • Make list of refactoring changes to implement
    • mostly done, should be turned into Google Code issues
  • Start designing real persistence layer
    • not done. Philip and I agree that for expediency’s sake I should stick with Derby for now
  • Make Saunders demo with virtual source Google visualization?
    • not done, requires visualization data source improvements
  • Start planning for next 413/613 assignment
    • done, only new feature needed is instantaneous carbon emission rate
  • Write WattDepot server installation and configuration wiki page
    • deferred: without real persistence, probably nobody should be using WattDepot just yet, so no point in writing up installation instructions that will need to be changed

Other accomplishments from last week:

  • Produced a list of “known good” values from the current WattDepot public server for the ICS 413/613 students
  • Wrestled with bad video from REIS seminar, probably due to dirty camcorder heads. Arg.

Pointers to work products:

Plans for this week:

  • Turn TODO.txt into Google Code issues
  • Implement instantaneous carbon emission rate resource in WattDepot
  • Write up code review description for Philip
  • Prepare draft presentation for ICS 690
  • Make GVisualizationServlet support virtual sources
  • Start working on DerbyStorageImplementation

Cool links:

  • Google Wave is pretty interesting (just got an invite last week). In theory, it seems pretty useful, but until many of the people who I collaborate with have accounts, it’s hard to tell if it will be useful in practice.