Day 1

Arrived in Lihue in the evening. Picked up our rental car from Hertz (1 min shuttle drive from the terminal). Upgraded the car to a Subaru Forester (AWD) due to some concern about the condition of a road we intended to drive the next day. Checked in at our hotel, the Aston Islander on the Beach in Kapaa [My Review].

Day 2

Got our state park camping permits in Lihue. Spent almost an hour waiting for the paperwork to be completed, but was glad we had been able to get all the permits we wanted on short notice (advance reservations of up to one year are sometimes required). Bought groceries for camping and to stock up our hotel fridge. Didn’t manage to get hold of a gas canister for our camping stove, so we’d have to make do with a Sterno. Bought topo maps at the museum shop. Rented snorkeling gear at Snorkel Bob’s.

Drove around to the west side of the island. To get to Polihale Beach we had to drive the last few miles on a notorious dirt road [Directions]. There had been a lot of rain prior to our arrival, and we had been warned when we got the permit that we’d get stuck for sure. But the road was starting to dry out, and we made it just fine (albeit covered with mud). Might even have made it with a compact car, but navigating the miles of potholes would have taken forever, and we’d have had to leave the car at the day use area at the end of the road. Found a beautiful spot to set up camp and walked up along the beach until we hit the end.

Polihale Beach Photos

Day 3

Drove back to Waimea and from there up to Koke’e State Park along the spectacular Waimea canyon. Stopped at the Koke’e Museum to ask about trail conditions. Started hiking from the end of the road at the Pu’uokila Lookout (amazing views down into Kalalau Valley and out into the ocean). Followed the (muddy) Pihea trail along the valley rim and then down into the Alakai Swamp (nice boardwalk). Followed the Alakai Trail from the intersection to its beginning at a picnic area with stunning views down Waimea Canyon. Headed back, with a small detour up Pihea Peak. Stayed at the Koke’e campground (near the museum).

Alakai Swamp Photos

Day 4

Drove down to Po’ipu. Po’ipu Beach looked a bit crowded, but we didn’t have trouble finding parking. The snorkeling turned out to be quite simple: Just had to stick the head underwater and watch all kinds of colorful fish swim up. Next we went on a (guided) tour of the Allerton Garden. They had some pretty amazing flowers and fruits growing there. Too bad the guide was more focused on keeping the group entertained with football jokes than lecturing… Before we headed back to the hotel to clean our gear and get a good night’s sleep, we were glad we checked out the “Spouting Horn” blowhole across the road from the garden [Movie].

Allerton Garden Photos

Day 5

Got up early and drove to the other end of the road, Ke’e beach, from where we hiked the Kalalau trail along the Napali coast 11 miles to Kalalau Beach. The trail is notorious for some scary bits along cliffs, but, being used to hiking in the mountains, we did just fine. On the other hand we lost a lot of time slipping along muddy sections of the trail (the first 2 miles were worst). Not to mention time lost crossing several streams (though none more than knee-deep) and filtering water. We also went through several cycles of getting rained on and drying out again, never bothered getting out our rain jackets. Reached Kalalau Valley as the sun was setting. The evening light combined with a rainbow or two made for a very scenic setting. By the time we reached the campground at the other end of the valley, it was dark. Surprised to find the campground packed; took us a while to find an even spot between the tents. [Tracklog]

Day 6

Wished we had a day to explore the valley and talk to the friendly “locals”, but we had to head back out…

Kalalau Trail Photos

Day 7

Long list of things to do on our last day: Find sea turtles (got lucky in the area next to Brennecker’s Beach, there was even a rare monk seal there). Visit the Museum in Lihue (no stunning exhibits, but interesting nevertheless). Return rented snorkeling gear. Clean our gear (and rental car). Return the snorkeling equipment. Buy gifts. Mail postcards. Print boarding passes. Even managed to swing by the Opaeka’a (yawn) and Wailua (wow) Falls [Movie].

Day 8

Our flight left early in the morning. On our last day a cold front had hit Hawaii; and since the weather back home in Seattle was nice, there was almost no noticeable difference when we got off the plane!

Useful Resources

• Ultimate Kauai Guidebook incl Updates [My Review]
• Kauai Forum at TripAdvisor — had all questions the guidebook didn’t cover answered there
• Kauai Explorer — ocean report and list of beaches and hiking trails
• Climate of Hawaii — some background information required to make sense of local weather forecasts
• National Weather Service: Area Forecast; Windward, Leeward and Mountain Forecasts
• Priceline.com — first time I used them, but seemed to work great for getting a good deal on the flight + hotel + car rental

I uploaded a jar file containing a simple test applet to Google Docs and referenced it like so:

<applet
  width="440" height="60"
  code="JavaVersionDisplayApplet.class"
  codebase="http://docs.google.com/"
  archive="uc?id=0B9ANnqvnRtroOTM5YWE3YmMtMGZkMy00ZGE5LWE2NWUtOGZhNzk5MzA2NzBk">
</applet>

The result:

Tracklog in Google Earth

TrailRegistry

TrailRegistry appears to be one of the oldest sites for sharing tracklogs. It also has the smartest approach, using a network algorithm to consolidate overlapping tracklogs and remove noise. Unfortunately the site doesn’t appear to have had much effort invested into it since it was set up in 2003.

GPXchange

GPXchange also appears to have been around since about 2003. The interface is similarly lacking and trail coverage isn’t great. No attempt is made to consolidate tracklogs.

GpsXChange.com

GpsXChange.com is a simple forum where people can post tracklogs. Seems to have been around since circa 2006 — like the following sites. Finding a tracklog requires searching the forums e.g. with a trail name. There doesn’t appear to be a huge amount of participation.

Redtrails

Redtrails is based on the trail maps compiled by Northwest Trails, where you can submit tracklogs (and wait for them to be integrated into a consolidated trail map database which is released every month or so). This is by far the most comprehensive set of trails (for Washington State) that I came across.

EveryTrail

EveryTrail is a Web 2.0-ish site where you can share a trip by uploading a tracklog and some pictures. Nice site to browse around, but if you are looking for a specific trail, your chances aren’t to good (unless it happens to be a major tourist attraction). Requires login to download raw tracklogs.

Wikiloc

Similar to EveryTrail. The interface is a bit less cluttered interface but I found only a dozen hiking trails for all of Washington State. Also requires login to download raw tracklogs.

Garmin Connect

The focus of this site seems to be more on keeping track of your fitness than providing hiking trail maps (e.g. it will show additional information such as the heart rate, if recorded), but it has the best interface for looking at tracklogs. There’s a reasonable amount of trails. Exports raw tracklogs in Garmin’s TCX rather than in the standard GPX format.

Trails.com

This site has been around since at least 2000, but they just started experimenting with letting people upload tracklogs. Tracklogs are attached to trail descriptions taken from books. But I couldn’t get this feature to work yet…

(In)conclusion

There is no shortage of options for uploading tracklogs. The ideal site would both store individual tracklogs and aggregate them into consensus trails — while making use of contextual information (How long ago was a tracklog recorded? During what season? Using what device? How reliable is the submitter?). Such as site does not appear to exist at the moment.

I’m not sure I’d bother submitting my (sometimes messy) tracklogs to sites such as TrailRegistry or Northwest Trails. But I do want to make sure that the raw data is available to anyone who wants to crawl it. Hosting the raw files on this blog is an option, but that makes finding the files difficult for anyone but Google. So I’ll probably go with Garmin Connect or Gp(s)XChange.com. Suggestions?

James A. Whitaker (Microsoft) on The Future of Testing: Crowdsourcing testing (see e.g. uTest) is the simplest way to get an application tested on a large number of different platforms. Such services should also allow testers to focus more on designing rather than executing (manual) tests. Virtualisation could address the issue of hard to reproduce bugs by capturing the state of the machine as part of bug reports. Game testers use maps to highlight areas in game worlds that have been thoroughly tested. Similar visualizations could help people testing normal software what areas of the application need more testing.

Elfriede Dustin and Marcus Borch (IDT) on Advances in Automated Software Testing Technologies: There are tools that can help generate random test data. The speakers spoke in great length about generating test code from customer supplied spreadsheets. Not sure if anyone in the audience understood what the advantage of this approach is — I didn’t.

Andres Almiray (Oracle) on Boosting Your Testing Productivity with Groovy: This was more about the advantages of Groovy in general than testing, though towards the end of the talk the speaker did show how to create mock objects (using MockFor/StubFor) and how to use DbUnit in Groovy (more or less the same way you’d use it in Java). Oh boy this guy really did drink the Kool-Aid…

Markus Clermont and John Thomas on Taming the Beast: How to Test an AJAX Application: The speakers did their best to keep he audience awake in this after-lunch talk. This got a bit tiring after the tenth “raise your hand if…”, but they had an excellent point: The amount of large, end-to-end tests (written e.g. with Selenium) should be minimized in favor of “medium”-sized tests that test interactions between specific components (one level deep).

Matt Wood (Sanger Institute) on The New Genomics: Software Development at Petabyte Scale: This was perhaps the most interesting talk, though it didn’t really go into testing at all!

Marc-Elian Bégin (Six2) on Using Cloud Computing to Automate Full-Scale System Tests: The case was made that Amazon EC2 is of great use for (system-level) testing. The speaker predicts that paravirtualization (e.g. with Xen) will increasingly be replaced with full virtualization (e.g. KVM), even though latter requires special hardware support (built into most newer processors?).

Vishal Chowdhary (Microsoft) on Practicing Testablity in the Real World: Good explanation of the basics of writing testable code, though perhaps a bit too basic for the audience that was present.

Here are the exact routes taken on these two tours:

Ride the Ducks of Seattle

Tracklog

Seattle Sea Planes

Tracklog | Pictures

The routes were recorded with a Garmin eTrex H, and the maps were created with Robogeo.

Don’t choose a visualization method in advance. The goal of a graphic is to invoke a content response, not a design response (i.e. wow, nice graph).

Organization charts are not informative — unless the lines (relationships) are annotated.

Every graphic should provide reasons to believe. Detail helps credibility and raises interest (as an extreme example consider aerial pictures). If you don’t show all the data you must be a “cherry picker”.

Letting people look at data themselves stimulates their interest and gets them thinking (and has more impact). More data points means more “hooks” for people to (potentially) be interested in.

When possible, bring something real to a presentation (for example a hospital bill when discussing medical expenses).

Annotate everything — even your text. Don’t use foot notes, create side notes.

It rarely makes sense to order items in tables alphabetically.

The Gil Sans font (a compact sans-serif font) works great for (time-)tables.

Don’t go for the lowest common denominator. Don’t be “flabby & generic”.

Make presentations that make proper use of the human eye-brain system (which has a bandwidth of ~10Mbs).

Tables outperform graphics up until ~500 data points.

Respect both the content and the audience. Why is it that an average PowerPoint table contains only 12 numbers, but tables in the sports section of a magazine can burden their audience with an average of ~200 numbers?

Distribute data in space (using multiple monitors, if must be) rather than not time (e.g. across several slides).

People should have their names on their work (as pride often results in better work).

Don’t separate information depending to its mode of production (e.g. in separate “multimedia” slide shows).

Be aware that design often mimics the hierarchy in an organization.

The original computer desktop at Xerox had icons for documents only (i.e. now trash icon etc).

Create “infographics” that you can leave around (maybe people will give them another look during a following, boring presentation).

“No matter how beautiful your interface is, it would be better if there was less of it” (though I don’t think he’d extend that all the way to command line interfaces).

“Flat” interfaces beat “hierarchical” interfaces in terms of usability.

Efforts to provide “personalized” interfaces are “pathetic” (shows that you don’t know how to present something, and try to offload the responsibility to the user).

Going beyond sparklines: Wavefields (?).

Instead of doing “presentations”, dump the data on the audience, let them read through it, and then have a “guided discussion” (i.e. answer questions).

So far there are 11 books, from Jess in Action (published July 2003) to jQuery in Action (published February 2008). I’m somewhat surprised that there was no announcement (so far) on either company’s web sites… In any case I’m hoping that there is more to come!

Sessions

These are the sessions I attended:

• TestNG with Code Coverage (Howard Lewis Ship)
• Groovy: Metaprogramming (Scott Davis)
• Professional Java UI Development with Eclipse RCP (Brian Sam-Bodden)
• The Busy Java Developers Guide to Concurrency (Ted Neward)
• Code Metrics & Analysis for Agile Projects (Neal Ford)
• Building Web Apps with Spring OSGi (Craig Walls)
• The Busy Developer’s Guide to Debugging (Ted Neward)
• The Busy Developer’s Guide to Monitoring (Ted Neward)
• The Busy Developer’s Guide to Scala (Ted Neward)
• The Busy Developer’s Guide to Hacking on the JVM (Ted Neward)

Notes

Test coverage should at least be 85% as there is often a significant number of bugs that are flushed out when you cross that threshold. But if you don’t aim for 100% coverage, there is the risk that you start copping out on testing the most difficult code!

When using the EclEmma Eclipse plug-in for gathering code coverage statistics, set up separate build output folders — otherwise unit tests are included in the statistics (even if the unit test source folder is not selected).

Cobertura generates somewhat better code coverage statistics than EMMA, but lacks an IDE plug-in.

Maven is a great idea, but using it for your project can be “like living with a dangerous psychopath” — it behaves when showing it to other people, but you never know when it will turn on you….

Ant has a presetdef task that allows you to create an alias for a task, and set default attribute values.

TestNG can be used both for unit and for functional tests. Test “groups” can distinguish the two (quirk: can’t directly select all tests that are not in a group). TestNG creates only one instance of each test class. TestNG can run tests in parallel (either at the class or at the method level). There is an @DataProvider mechanism that can return either an array of test data or an iterator. TestNG can run JUnit tests! Can also run Selenium RC from TestNG — check the Tapestry test code.

New Groovy language features don’t require new Java versions. This may be attractive for people who are stuck with old versions of Java. Groovy even allows addition and modification of all methods at runtime via its ExpandoMetaClass, e.g. String.metaClass.foo = { -> delegate.toUppercase() }

A JVM may map threads n:m at the OS level.

Schedulers may do “priority inversion” when a low priority thread holds a lock required by a high priority thread.

Build-specific deltas are more interesting than absolute numbers when looking at code metrics.

The “teddy bear” debugging technique: Explain the problem to a teddy bear! Often you’ll realize what the problem is before you need to go bother a colleague…

Should declare unchecked exceptions.

-XX:OnOutOfMemoryError=cmd sets a command that is run when we run out of memory.

-XX:TraceClassLoading shows where classes are loaded from.

The extconflict tool (shipped with Sun’s Java) detects duplicate classes in lib/ext.

Heisenberg principal: Monitoring a system always influences it (e.g. garbage collection activity due to jconsole connection).

jconsole has a scripting plugin. Also consider using Groovy for scripting tasks.

Scala is an (impure) functional language. Functional languages are great for concurrent programming (immutable objects, use of “actors” etc). But Scala won’t be ready for production use this year (or even next year). Get the book!

Reflection can be used to read (and set) private fields, even in core classes such as java.lang.String! Going one step further: We can provide our own String implementation (use -Xbootclasspath=...).

Comments

Most of the talks were at a level of detail that if you happened to have read a book on the topic you weren’t likely to learn a lot. Nevertheless you were bound to pick up some useful stuff as (most of) the speakers were clearly not only quite experienced but also great speakers. Ideally you’d have the number one expert on each topic give the talk, but I realize that isn’t practical… Despite the “No Fluff” branding there was a lot of talk about how we all need to be “agile” etc. Nevertheless I think everyone managed to keep their feet on the ground, and in any case their were sufficient technical talks. Not to mention the food and free stuff :-)

First I tried using POI-HSSF (a well-known Apache project). The code is reasonably straightforward — though I had to get it from tutorials on the Web as I couldn’t find much in terms of documentation on their site, and the API isn’t exactly self-evident:

POIFSFileSystem fs = new POIFSFileSystem(in);
HSSFWorkbook wb = new HSSFWorkbook(fs);
HSSFSheet sheet = wb.getSheetAt(0);
Iterator rows = sheet.rowIterator();
while (rows.hasNext()) {
    HSSFRow row = (HSSFRow) rows.next();
    Iterator cells = row.cellIterator();
    List<string> fields = new ArrayList<string>();
    while (cells.hasNext()) {
        HSSFCell cell = (HSSFCell) cells.next();
        switch (cell.getCellType()) {
            case HSSFCell.CELL_TYPE_STRING:
                fields.add(cell.getStringCellValue());
                break;
            case HSSFCell.CELL_TYPE_NUMERIC:
                fields.add(Double.toString(cell.getNumericCellValue()));
                break;
            default:
                log.warn("Unsupported cell type: " + cell.getCellType());
                break;
        }
    }
    process(fields);
}

This works fine — except that there doesn’t seem to be a way to keep the precision of numbers, i.e. if you don’t want to convert “4″ to “4.0″! Fortunately POI isn’t the only game in town. I ended up using JExcel API which has a much simpler API (and behaves the way I want it to):

Workbook workbook = Workbook.getWorkbook(in);
Sheet sheet = workbook.getSheet(0);
for (int i = 0; i < sheet.getRows(); ++i) {
    List<string> fields = new ArrayList<string>();
    for (int j = 0; j < sheet.getColumns(); ++j) {
        fields.add(sheet.getCell(j, i).getContents());
    }
    process(fields);
}

Upon logging in and creating a “blist”, you are presented with a spreadsheet-like view. You then drag and drop data types onto the spreadsheet to create columns.

“Lenses” can be created to get non-tabular (and filtered) views of your data. Data can be entered directly both in the table or in the “lense” views. There are options to share and discuss “blists” — however these don’t seem to be implemented yet.

Blist is still in a very early stage. Following are some comments, based on my initial impression.

Neat!

In addition to the standard data types (text, numbers, dates etc) there are lots of unusual but useful data types such as email addresses, images, and star ratings.

Columns (unlike in a normal spreadsheet) can be set to allow multiple values in a single “cell” (possible, but cumbersome to implement with a normal database).

You can easily create “custom types” a.k.a. “pick lists” or enumerations.

It is possible to group/nest columns one level deep, creating a “blist-in-a-blist”.

Blist (unlike a normal database) doesn’t prevent invalid values in fields that expect a certain format. But (unlike a normal spreadsheet) invalid values are highlighted.

Suggestions…

If non-technical users are the main audience, it may be worth thinking about making the interface less intimidating. Too many buttons and controls!

Features that haven’t been implemented yet would probably better be hidden from view. It’s frustrating to not know if a button is disabled because you’re in the wrong mode, or because it isn’t implemented yet…

Support for undoing actions (and fewer prompts).

Support for changing the data type of a column (e.g. from number to string).

There is a nice calendar control for entering dates. Unfortunately it can’t be bypassed — if you want to enter an old date you need to go back in time month by month… The money data type is nice, too, but seems to be USD only.

Some of the data types muddle the distinction between data type and display. For example, is a checkbox really a different data type than a boolean — or is it just another way to display boolean values?

Help, Firefox eats all my memory! (May be an issue with Flash?)

I bet a geo-location data type and map view is already being worked on…

If the query builder showed a preview of the results, this would save some tedious back and forth when building queries. Speaking of search: Where is the quick search?

Should be able to link blists to each other (one of the killer features of relational databases)!

Support copy-pasting single (and multiple) cells.

Finally, there is a typo in the “downloading Lenss” status message :-)

Conclusion

While Blist isn’t the first effort to do spreadsheets or databases on the Web (think Google Spreadsheet or Freebase), the way it combines the best features from both worlds seems new (to me, at least).

Will be interesting to see how the “social” features are implemented — and of course if their infrastructure manages to scale (especially once they enable the data import feature and people start dumping existing collections into Blist)!