The red tracks were recorded while driving (or, in one instance, while on a ferry). The yellow tracks were recorded while hiking (or in small boats). I only started recording driving tracklogs end of April, hence the few disconnected hiking tracks on the map.

The map was created with Google Fusion Tables, which somehow is smart enough to be able to show a large number of tracklogs all at once. I wrote a small script (in Groovy) to convert a directory containing GPX tracklog files into a single KML file that can be imported into Google Fusion Tables.

Click on the image above to open an interactive, zoomable map.

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!