This is part two of a series of posts discussing various aspects of a bike trip I did across the United States in 2012. Part 1 discussed the start of the trip and choosing a route. This post discusses my daily routine and where I sheltered each night.

The daily grind

After the first-day snafu, the trip went basically as planned.

I started biking each day sometime in the morning (from as early as 04:00 to as late as 11:45). I finished sometime before or within a couple hours of dark (in the range of 17:00 to 22:00, dependent on my destination) after typical distances of 90-130 miles. Knowing I was on a marathon, I deliberately never pushed for any real length of time. When I hit an uphill, I shifted to the lowest gear that felt comfortable and kept pedaling; I never attempted to power up a hill. And in flatlands I traveled at whatever pace was comfortable, not aiming for speed.

Around home through Bay Area flatlands I usually push myself and average 17-18mph during riding time, depending where and how far I go. On this trip 14-16mph was more common, and I had days well below that. Somewhat hilariously, when I returned I found myself in worse cycling shape by this metric: I was slower than my previous average for awhile, until I could, er, get back into shape. (I also returned well out of shape for playing ultimate frisbee, as I expected would happen from not running and walking little for over a month. When I first played after returning, I had plenty of endurance. But my muscles quickly made it abundantly clear that if I sprinted or made a break, I would hurt myself.)

Shelter

At night I stayed a variety of places. About half the time I camped in a one-man Eureka Solitare tent. (There’s no better 2.5-pound three-season tent out there for its $90 price. Its only demerits are its fiberglass poles [which long ago I was forced to replace with aluminum poles, that have posed no problems] and, occasionally, its not being freestanding.) I slept in a 45-degree bag (too warm!) and a short-length inflatable sleeping pad. These nights were usually in campgrounds, but I stayed in city parks several times in the middle of the country, when allowed. The rest of the time I stayed in motels of varying quality, from $40 to $100+ for the night, sometimes with a meal, sometimes with a pool, sometimes with nothing.

There were a few nights where I neither camped nor stayed at a motel. A local resident of Ordway, CO graciously shared her home with cyclists, and I ended up staying there a night with a couple other cyclists, some heading west, some heading east. The city of Farmington, MO maintains Al’s Place, a hostel for cyclists on the TransAmerica, and I stayed there a night with another cyclist heading east. I also visited The Place, a hostel in Damascus, VA that I’d stopped at while hiking the A.T. And at the end of the trip, in Yorktown, Grace Episcopal Church provided space for cyclists to stay: much appreciated as a base for me to regroup before heading to an airport to fly home.

One additional hostel that I didn’t visit deserves special note. The TransAmerica Trail was first inaugurated in a 1976 mass cross-country ride. One woman along the way, June Curry, put out a sign informing passing cyclists that they could get water at her house if they wanted. One thing snowballed into another, and eventually, somehow, she found herself opening a hostel as a place for passing cyclists to stay, offering much other hospitality as well. Unfortunately June Curry died just before I started my trip, so I couldn’t meet her. 🙁 But I’d heard the hostel would still be open and running when I passed through, and even if it weren’t, it’d be worth a visit just to learn about the place. The day I’d hoped to stay, however, was the day after my longest day the entire way — which meant I’d roll in fairly late, certainly after dark. I tried calling ahead, multiple times, to see if it’d be okay showing up later. But I couldn’t get a response, and after a last attempt before the sun went down, I gave up and went with alternative lodging. 🙁

If my pace were more leisurely, I might have tried out Warm Showers, a site for on-the-road cyclists looking for a place to stay overnight. But as I mostly didn’t know where I’d be til end of day (I set aggressive goals that I didn’t always reach, or only reached late in the evening — see the June Curry story above), the last-minute scheduling seemed way too much hassle for both me and any person who might be willing to host me for a night. It seemed much better to use campgrounds or motels that expect people to spontaneously show up (and more to the point, are specifically paid market rates for it), than to put people hosting mostly for fun through any hassle.

Next time: mileage, elevation, and route scenery.

One year ago, after 37 days of biking around ~3875mi total starting in San Francisco, I reached Yorktown, VA to finish biking across the country. An exact day-to-day accounting would likely bog down in uninteresting logistics (particularly given the way I traveled — other approaches would likely yield more interesting day-by-day commentary). Instead, I’m going to cover a variety of topics of interest from the trip, in somewhat random order, in series. If you want a very cursory, sometimes out-of-order account of the trip, reading approximately July 18 to August 25 of my Twitter stream covers it.

An inauspicious start

The trip got off to a bumpy start the Tuesday night before I planned to leave. I planned to ride my spiffy, super-light carbon-fiber racing bike. I use it for regular transport, so I waited to get a final tune-up til the last minute, picking it up the evening before I departed. I began loading it with panniers and gear. Racing bikes don’t have mounts for carrying gear, so I’d use a seatpost rack (with correspondingly light ~16-pound load). When I began attaching the rack, I noticed the clamp matched a much smaller-diameter seatpost. Looking at how the clamp would make contact with the seatpost, it suddenly occurred to me that attaching a seatpost rack to a carbon fiber seatpost might not be a good idea. Carbon fiber is strong along its length, not laterally: the clamp could easily crush the seatpost.

Wednesday morning, I asked the bike shop if they had an aluminum seatpost of the right size. They wouldn’t have one til Friday. Other local shops didn’t have any, either. Replacing the seatpost was out.

Seeing no other options…I went to the first bike shop, bought a non-carbon road bike that fit me, walked home with it, transferred gear and pedals to it, and biked to Caltrain to head to San Francisco to start the trip.

Thus I crossed the country on a bike I bought the day I left.

This is crazy. But not quite as crazy as it sounds. I’d purchased a 2012 Scattante R-570; I’d previously owned the 2010 version, so I knew I’d be comfortable. And months before, I’d considered getting a touring-oriented bike for extra carrying capacity. But I’ve never spent money very easily. I had the money, but I didn’t want to spend it if I didn’t have to.

Now I was in a “have to” situation. Riding a totally untested bike would rightly scare most people to death. Most people would probably cancel the trip or substantially change plans. But my philosophy is that what must be done, can be done. So I did it.

Other than lost biking time (day 1 was 23.76mi route miles rather than the ~100mi I’d intended — no small loss, but not huge, either), all I lost was the ability to buy the bike on sale for ~$160 less. It could have been worse.

Choosing a route

I traveled pretty much entirely with the aid of the Adventure Cycling Association‘s route maps. I considered finding my own route, but I discarded the idea for lack of time and being unsure I’d enjoy route-planning. In hindsight this was clearly the right choice. Unless you enjoy route-planning for its own sake, buy existing cycling maps. You’ll get better routes, and more cycling-useful information, than you can create on the fly. (Plus GPS units cost hundreds of dollars and must be charged every night.)

The 4200-mile TransAmerica Trail goes from Oregon into Montana, southeast to Pueblo in Colorado, then east to Virginia and the coast. It’s the most well-known and commonly-used cross-country route. The 1580-mile Western Express goes from San Francisco to Pueblo. Most people do the TransAmerica because it avoids much waterless desert and elevation change. For me, convenience and available time made the Western Express and eastern TransAmerica a no-brainer.

A definite perk to using an existing route is that the roads will be good for cycling. Often I was on relatively empty back roads, or on state roads with light traffic. The worst roads were in the Rockies in Colorado, likely because of the terrain. The worst regularly-bad road occurred between Cimarron and Sapinero along US-50: a narrow, winding stretch of road with little shoulder and a bunch of RV traffic, where I should have occasionally taken the entire lane rather than let anyone unsafely pass me. Colorado also had the worst irregularly-bad stretches of road, along CO-145 due to road construction. There were two two-mile stretches of riding through gravel where roads were being re-oiled, which I rode through (what choice did I have?) past Motorcycles use extreme caution signs on 700×23 tires (less than an inch wide). Good times. And the stretch from Telluride to Placerville had so much construction dust I sometimes couldn’t see ten feet; I had to stop and turn on head and tail lights to be visible. But generally, ignoring these rare exceptions, the roads were great.

Next time, the daily grind and shelter.

A couple years ago when SpiderMonkey’s implementation of strict mode was completed, I observed that strict mode forbids octal number syntax. There was some evidence that novice programmers used leading zeroes as alignment devices, leading to unexpected results:

var sum = 015 + // === 13, not 15!
          197;
// sum === 210, not 212

But some users (Mozilla extensions and server-side node.js packages in particular) still want octal syntax, usually for file permissions. ES6 thus adds new octal syntax that won’t trip up novices. Hexadecimal numbers are formed with the prefix 0x or 0X followed by hexadecimal digits. Octal numbers are similarly formed using 0o or 0O followed by octal digits:

var DEFAULT_PERMS = 0o644; // kosher anywhere, including strict mode code

(Yes, it was intentional to allow the 0O prefix [zero followed by a capital O] despite its total unreadability. Consistency trumped readability in TC39, as I learned when questioning the wisdom of 0O as prefix. I think that decision is debatable, and the alternative is certainly not “nanny language design”. But I don’t much care as long as I never see it. 🙂 I recommend never using the capital version and applying a cluestick to anyone who does.)

Some developers also need binary syntax, which ECMAScript has never provided. ES6 thus adds analogous binary syntax using the letter b (lowercase or uppercase):

var FLT_SIGNBIT  = 0b10000000000000000000000000000000;
var FLT_EXPONENT = 0b01111111100000000000000000000000;
var FLT_MANTISSA = 0b00000000011111111111111111111111;

Try out both new syntaxes in Firefox Aurora or, if you’re feeling adventurous, in a Firefox nightly. Use the profile manager if you don’t want your regular Firefox browsing history touched.

If you’ve ever needed octal or binary numbers, hopefully these additions will brighten your day a little. 🙂

Properties and their attributes

Properties of JavaScript objects include attributes for enumerability (whether the property shows up in a for-in loop on the object) and configurability (whether the property can be deleted or changed in certain ways). Getter/setter properties also include get and set attributes storing those functions, and value properties include attributes for writability and value.

Array properties’ attributes

Arrays are objects; array properties are structurally identical to properties of all other objects. But arrays have long-standing, unusual behavior concerning their elements and their lengths. These oddities cause array properties to look like other properties but behave quite differently.

The length property

The length property of an array looks like a data property but when set acts like an accessor property.

var arr = [0, 1, 2, 3];
var desc = Object.getOwnPropertyDescriptor(arr, "length");
print(desc.value); // 4
print(desc.writable); // true
print("get" in desc); // false
print("set" in desc); // false

print("0" in arr); // true
arr.length = 0;
print("0" in arr); // false (!)

In ES5 terms, the length property is a data property. But arrays have a special [[DefineOwnProperty]] hook, invoked whenever a property is added, set, or modified, that imposes special behavior on array length changes.

The element properties of arrays

Arrays’ [[DefineOwnProperty]] also imposes special behavior on array elements. Array elements also look like data properties, but if you add an element beyond the length, it’s as if a setter were called — the length grows to accommodate the element.

var arr = [0, 1, 2, 3];
var desc = Object.getOwnPropertyDescriptor(arr, "0");
print(desc.value); // 0
print(desc.writable); // true
print("get" in desc); // false
print("set" in desc); // false

print(arr.length); // 4
arr[7] = 0;
print(arr.length); // 8 (!)

Arrays are unlike any other objects, and so JS array implementations are highly customized. These customizations allow the length and elements to act as specified when modified. They also make array element access about as fast as array element accesses in languages like C++.

Object.defineProperty implementations and arrays

Customized array representations complicate Object.defineProperty. Defining array elements isn’t a problem, as increasing the length for added elements is long-standing behavior. But defining array length is problematic: if the length can be made non-writable, every place that modifies array elements must respect that.

Most engines’ initial Object.defineProperty implementations didn’t correctly support redefining array lengths. Providing a usable implementation for non-array objects was top priority; array support was secondary. SpiderMonkey’s initial Object.defineProperty implementation threw a TypeError when redefining length, stating this was “not currently supported”. Fully-correct behavior required changes to our object representation.

Earlier this year, Brian Hackett’s work in bug 827490 changed our object representation enough to implement length redefinition. I fixed bug 858381 in April to make Object.defineProperty work for array lengths. Those changes will be in Firefox 23 tomorrow.

Should you make array lengths non-writable?

You can change an array’s length without redefining it, so the only new capability is making an array length non-writable. Compatibility aside, should you make array lengths non-writable? I don’t think so.

Non-writable array length forbids certain operations:

• You can’t change the length.
• You can’t add an element past that length.
• You can’t call methods that increase (e.g. Array.prototype.push) or decrease (e.g. Array.prototype.pop) the length. (These methods do sometimes modify the array, in well-specified ways that don’t change the length, before throwing.)

But these are purely restrictions. Any operation that succeeds on an array with non-writable length, succeeds on the same array with writable length. You wouldn’t do any of these things anyway, to an array whose length you’re treating as fixed. So why mark it non-writable at all? There’s no functionality-based reason for good code to have non-writable array lengths.

Fixed-length arrays’ only value is in maybe permitting optimizations dependent on immutable length. Making length immutable permits minimizing array elements’ memory use. (Arrays usually over-allocate memory to avoid O(n2) behavior when repeatedly extending the array.) But if it saves memory (this is highly allocator-sensitive), it won’t save much. Fixed-length arrays may permit bounds-check elimination in very circumscribed situations. But these are micro-optimizations you’d be hard-pressed to notice in practice.

In conclusion: I don’t think you should use non-writable array lengths. They’re required by ES5, so we’ll support them. But there’s no good reason to use them.