www.ian.dees.name

how to speak robinese

undees — 2009-10-31T16:41:43+00:00

The baby is teaching me how to speak Robinese. This is a greater intellectual challenge, she reasons, than merely learning English would be (which she’s also doing). Old dogs, new tricks, and all that.

From what I’ve been able to gather, Robinese is more of an analytic language than English. She changes the meanings of words not by gluing on prefixes or suffixes, but by adding more words. For example, I would stick together two concepts and a suffix in one word to refer to my absentmindedness. She would express the same sentiment using separate words: “silly Daddy.” We intensify a word by adding “-er” or “-est.” She does so by repeating the word: “shoo shoo bad bad,” she says to the cats or anyone else who crosses her.

Her most creative use of this technique so far has to be “water monkey balls,” her term for “museum” (don’t all museums have a giant monkey and an aquatic play room?).

Other linguistic highlights:

Normally we don’t modify pronouns: we can say “red car,” but not “red it.” Robinese has no such restriction: “my this” is a frequent utterance when she has no idea what to call something, but knows she wants it.

“All right” is not just a response to cajoling (as in, “all right, I’ll do it, quit bugging me”); it is also an expression of cajoling. Can you imagine waking up to a baby standing next to your bed, pulling on your arm and saying, “All right, all right, all right?”

Word meanings are extremely dependent on context. The single-word sentence, “Hold,” can mean, “I want to play with the cups that are on that table,” or “If you value your eardrums, you’ll pick me up right now.”

Next lesson starts today. Can’t wait.

drain bump

undees — 2009-09-05T06:07:45+00:00

We have a drawer at the house we call the “oh, shit” drawer. It has chargers for long-discontinued phones (hey, Nokia might start making the 2120 again!). It has enough paperclips and safety pins to melt down and make, say, a medium-sized bicycle. It’s got crap I don’t even know what to call.

Welcome to the verbal equivalent of that drawer. What’s left to write about here? Flash-pan, off-the-cuff insights go on Twitter. Code goes on GitHub, thanks to hg-git. Prose, if I’m excited enough to feel compelled to type it in no matter where I am, gets e-mailed straight to Posterous. And if I’m not excited to write it? Well, you’re lookin’ at it, bub.

Weird that just a couple of years ago, a domain was a one-stop shop to put everything you cared about: reading, writing, code, life, photos, essays, quips, everything. Now, our identities are so sharded. (No, not sharted.) Not a bad thing, necessarily. A bunch of people I know get way more eyeballs on their tweets than they ever did on their blog posts. And one gal uses the Internet as kind of a fault-embracing distributed backup of her brain. Why worry about meticulously finding room on your computer to put stuff, the reasoning goes, when you can blast it out into the ether?

Tempting.

Still, though, the retro-2000s curmudgeon in me says that www.yourname.com is better than facebook.com/yourname plus twitter.com/yourname. Not that these are mutually exclusive, but realistically, how much time do we all have to be de-facto system admins of ten different websites? In our spare time, no less?

And what’s left to put on your own domain when you’ve already said everything elsewhere? Just an aggregation of crud that lives elsewhere?

I dunno, maybe I’m overthinking this (shocker!). Probably best just to let all those other (a)venues be breeding grounds for ideas, and use good ol’ Ctrl-C plus Ctrl-V to bring the greatest hits into one place.

Not that there won’t always be that little monkey voice saying, “Wouldn’t it be cool to have a little script to tie this all together? C’mon, let’s fire up Emacs….”

bacon cucumber sandwich

undees — 2009-05-26T15:08:44+00:00

Dammit, scooped by Giles. I hint tantalizingly at an upcoming article on Bacon and Cucumber, and he goes and writes the damn thing. I was even gonna raid Flickr for an appropriate picture, just like he did (this one’s courtesy of user nicubunu):

Ah well. It turns out we have different things to say on the matter, anyway. Giles was making an important point about understanding the tools you work with, and you should listen to him. I’m just going to say something much more mundane about using these two particular test libraries together.

You’ll recall that Cucumber’s ancestor, the Story Runner, used to be part of RSpec. So it made sense to use RSpec as your one-stop testing shop, for unit tests, acceptance tests, mocks, stubs, and best of all, the beautiful “should” syntax for assertions.

Of course, RSpec has long supported drop-in replacements for most of these, should you have a favorite stub library or such. The spinning off of Cucumber has made it that much more timely to consider custom-fitting each layer of your tests.

You certainly can use RSpec’s assertions underneath your Cucumber stories, as we’ve seen. But let’s say I’m some kind of hypothetical curmudgeonly developer who doesn’t want to download an entire test + assertion + mock + stub framework, just to get nice assertions for Cucumber. What do I do?

Well, one option is Bacon (Christian Neukirchen’s nod to RSpec; “Spec” in German means “Bacon”), which gives you RSpec-style asssertions, but leaves you to find or invent your own mocking, Rails integration, Web bindings, and so on.

Because it comes without all those extras, and because it “cuts with the grain” of Ruby in its design, the Bacon core weighs in at a svelte 356 lines of code as of this writing—that’s counting comments, but not tests. If you stick to the basics, it feels a lot like RSpec, with two important distinctions worth mentioning here:

RSpec assertions tend to use spaces and underscores to separate words, while Bacon tends to use dots. So answer.should be_true becomes answer.should.be.true.
RSpec always throws an exception when a test fails. Bacon tailors its behavior to whether it thinks you’re manually typing code into irb or running an automated test. So to use Bacon with Cucumber, you have to throw Bacon::Counter[:depth] = 1 inside your env.rb somewhere, effectively saying, “Hey, Bacon, we’re inside a test framework, even though you don’t see a describe block anywhere.”

So for the party-planning example from the book, all you’d need to do is require 'bacon', do the counter-depth thing I described above, make a quick pass through the shoulds to “decimalize” them, and… deal with custom matchers.

For simplicity’s sake, Bacon omits some of RSpec’s fancier matchers. In particular, object.should have_foo doesn’t automatically call object.has_foo?. But we can get pretty close to that with a custom matcher, which in Bacon is a plain old top-level function:


  def have(suffix, *args)
    lambda do |obj|
      obj.send "has_#{suffix}?", *args
    end
  end

Then, instead of party.should have_location, you’ll write party.should.have(:location).

What have we gained from all this? If your project already has code-level tests in RSpec, you can get should-style assertions in your acceptance tests for free—might as well use ‘em. But if you don’t need the mocks and extras that come with RSpec (maybe you’re testing non-Ruby project!), and you just want the assertion syntax, that’s where Bacon comes in.

Anyway, have a look at the diff between an RSpec project and a Bacon one; it’s quite easy to migrate from one to the other. Me, I’m going to lunch. Enjoy!

cucumber for a story

undees — 2009-02-18T06:57:35+00:00

Ah, technology. Write a book with a chapter on testing programs in plain English, and they go and change the software the next morning. It would be enough to make a more timorous developer tip the entire bookshelf into the dustbin and give up on testing altogether.

But not us. You and I, we’re going strap Aslak’s guide to our side, wade in, and see just what it takes to whip a bunch of RSpec stories into shape for Cucumber. Specifically, we’re going to tackle the party planning web app from Chapter 10 of the book.

Renaming the files from .story to .feature and sticking them in a features/ directory is easy, right? No need to edit the contents of the file, unless you get weird parser errors—Cucumber is strangely unforgiving about really silly things like line breaks in comments. The examples for the book didn’t need any tweaking, but a couple of tests at work did. When in doubt, keep deleting lines (temporarily!) until you find the problem child.

Next, it’s time to free the step definitions from the blocks that enchain them. For the party-planning example in the book, we have steps_for :planning, :reviewing, :rsvp, and :email blocks. Here’s a tiny example. If this were one of our blocks:


steps_for :rsvp do
  Then 'I should see "$guest" in the list of $type' do |guest, type|
    want_attending = (type == 'partygoers')
    @party.responses(want_attending).should include(guest)
  end
end

...we’d ditch the first and last lines (steps_for... and end) and put the rest into features/step_definitions/rsvp_steps.rb). The other three groups of definitions get a similar treatment.

Next, we need to get rid of the Story Runner’s fuzzy string matchers and replace them with proper regular expressions. This only took a few seconds, even on the large body of tests we have at my day job; we just used a text editor search-and-replace to change Given ' to Given /^, and so on. (If your text editor is extra-clever, you can use a regex to, um, write your regex for you. Somewhere in there, there’s a Sup dawg joke just aching to get out.)

Next, we need to get rid of those dollar-variables inside, and replace them with good ol’ regex captures. All of the ones for this chapter worked with (.*)—the catch-all capture. For a chunk of tests we converted at work, there were a few places where Cucumber complained that a test step matched more than one regular expression. This kind of thing can happen when you want to match both of these:

When I frob the quux to 123

When I frob the quux to 123 furlongs

The naïve approach won’t work:


When /I frob the quux to (.*)/

When /I frob the quux to (.*) (.*)/

Because “123 furlongs” matches both (.*) and (.*) (.*). Cases like these call for more specific captures, either requiring numeric characters, or enclosing quotes, or optional matches, or some other way to tell them apart—for now. The Cucumber team are working on a way to resolve some ambiguous matches automatically. In the meantime, cleaning up regexes doesn’t hurt too bad.

After the changes we’ve done so far, the step definitions in rsvp_steps.rb would look like this excerpt:


Then /^I should see "(.*)" in the list of (.*)$/ do |guest, type|
  want_attending = (type == 'partygoers')
  @party.responses(want_attending).should include(guest)
end

Next up: the setup and teardown stuff. Cucumber provides Before and After hooks, but these run for every Scenario in our code. Some actions, like starting and stopping a web browser, are slower than typical setup code and should only be run one time. For these cases, Cucumber will run anything you put in features/support/env.rb just once—at launch time. Since this file can contain Ruby-style at_exit handlers, you can also put global teardown code in this file.

For this example, we need just one little tweak to the approach. The browser object needs to be available inside or test steps, so we can pass it into our Party support code. Cucumber’s World method will do the trick. Think of it as a Before hook with instance methods; if we define a browser method in a custom World, every test step in our suite will have access to the it.


class PartyWorld
  @@browser = Selenium::SeleniumDriver.new \
    'localhost', 4444, '*firefox', 'http://localhost:3000', 10000
  @@browser.start
  at_exit {@@browser.stop}

  def browser; @@browser end
end

World do
  PartyWorld.new
end

(Note that one test step uses the old @browser instance variable inside; it needs to be changed to use the browser method instead.)

The last holdover from our old RSpec-style stories is the with_steps_for ... run ... block that actually starts the tests. We don’t need this any more, since Cucumber comes with its own launcher that scans a directory for *.feature files and runs them:

cucumber features

Don’t forget to require 'spec/expectations' somewhere if you’re using the fancy RSpec matchers like should_have. See the code listings for the finished product.

Coming up next: I’ll explore using the lo-cal Bacon assertion framework instead of RSpec. Mmmm, Cucumber and Bacon….

iphone gui testing

undees — 2009-02-02T06:13:37+00:00

Ah, the iPhone. Darling of the geeks. All these shiny new applications running on it. How will we test them all? What software test framework is simple enough, elegant enough, trendy enough to suit the device?

Why, Cucumber, of course.

the state of the art

The art of automated testing of iPhone apps is still in its infancy. Not to say folks haven’t been busy. There’s the Google Toolbox for Mac, which includes an iPhone test section. And Dr. Nic has paved the way for code-level unit testing of Cocoa classes, albeit on the Mac.

Most promisingly, Matt Gallagher has put together the three crucial pieces of automated GUI testing for iPhone apps: identifying pieces of the UI, simulating a human finger poking at the screen, and finding out what happened.

And in just a few short steps, we’re going to hook up Matt’s demo app to Cucumber, the Ruby-based framework that understands tests in plain English. What you’re about to see is a toy. It’s the minimum amount of glue to get Ruby pointed at Matt’s code. Plenty of time to make it into something for grownups later.

First, a brief word on Matt’s approach is in order. He basically monkey-patched the UIView class that underlies the iPhone’s on-screen gizmos, so that you can interrogate them at runtime: “What are you? Where are you? Do you have any text or gizmos inside you?” Next, he reverse-engineered how to simulate screen taps. And he tied it all together with an XML-based scripting language that lets you define simple steps like, “scroll to the 10th row in the list,” or, “Press the button that says, ‘Click me.’”

For this technique to work on an iPhone app, you have to add a little piece of custom code to read the test script and spider your UI. And you have to bundle the XML test script itself into your app—well, into a special test version of your app.

hooking it up to cucumber

I thought of just building a translator from Cucumber’s subset of plain English (affectionately called “Gherkin”) into the XML property list format, and then just using that generated code as before. But I wanted Cucumber to be actually talking to the iPhone app.

Remember, Apple likes iPhone apps to pull data from the rest of the world, rather than having data pushed into it. And one of the simplest, dumbest ways you can make data available for the iPhone is to use a web server.

So this project uses a slight modification of Matt’s app. Instead of reading its instructions all at once at the beginning of the program, we want to fetch each step one at a time from a web server. The app runs the step—pushing a button, or comparing a caption, or what have you—and then reports its results by hitting a /pass or /fail URL on the web server. (Yes, I know that’s not what HTTP GET is for, but until Apple provides a one-liner for HTTP POST instead of a ten-line novella, GET will remain the refuge of scoundrels writing quickie blog posts.)

Another web server listens to requests from Cucumber and…. Wait a sec. We’re going to need better names for these than “the first server” and “the other one.” In honor of the Big Important Handegg Game that was going on during this madcap experiment, we’ll call them the quarterback and the coach. The quarterback talks to the iPhone, and the coach talks to Cucumber. The coach signals plays to the quarterback via the silliest set of hand signals you can think of: the file system (told you it was a toy).

trying it out

You can actually try out these pieces in isolation, using curl to pretend to be an iPhone asking for instructions or an instance of Cucumber issuing them. But of course, it’ll be more fun to put it all together.

More detailed instructions and code are available using the distributed revision control system of your choice. Here’s the short, short version.

Apply a patch to Matt’s project to fetch the list of test instructions from a web server instead of a disk file.
Launch the coach and quarterback web servers.
Start the Cucumber test.
Kick off the test version of the app.

You won’t see the iPhone simulator pop up, but the code is running and duly reporting its results to the quarterback.

Where do we go from here? Lots of directions.

The test script should have an option to kick off the simulator app, instead of waiting for you to launch it manually.
The Ruby side should expand to do things like string comparisons and pass/fail decisions, so that we can move some of that stuff out of the iPhone.
The cheesy one-liners I added to the app to fetch data should be replaced by event-driven network I/O.
We should get this thing going on a real iPhone.

What we’ve got so far is a just a baby step. But take it from the father of a toddler, those can be entertaining.

primitive boots

undees — 2008-12-16T23:26:00+00:00

Do you remember the Rocky’s Boots video game from the eighties? Of course you do. While the rest of us were struggling to survive to the end of the Oregon Trail, you were building rudimentary Rube Goldberg devices out of simple “and” and “or” operations to make Rocky the Raccoon kick the right sequence of little colored squares.

Primitive recursive functions in mathematics are kind of like that. Most simple calculations you can think of — testing whether or not a number is prime, say Ᾱ can be built out of a few really basic functional pieces.

First, you need to be able to represent natural numbers. You can do that with a zero function, a successor function, and a glue function to stick ‘em together. Need to represent the number two? Glue a successor to another successor to a zero.

Next, you need a picker and a flicker. The picker chooses a single item out of a list, and the flicker takes two functions and “flicks” the calculation to one of them, depending solely on whether a single number is zero or nonzero.

The accepted names for these functions, respectively, are zero (Z), successor (S), composition (written as a little circle; I’ll use a lower case o), projection (P), and primitive recursion (PR).

Projection is typically written with a superscript representing the number of items on the list, and a subscript representing which item to choose. So P/3/2 is a function that takes three numbers and hands you the second.

The canonical example they give you in grad school is defining addition. You add two numbers together by adding 1 to one of them, over and over again. Doing something over and over requires the flicker; that is, primitive recursion. PR asks us for two things:

When the first number is zero, PR hands us just the other number says, “What do you want to do with this?” Since anything plus zero equals itself, we just hand the number back. We’re given one number and we give it right back, so this is P/1/1.
When the first number is something greater than zero, PR gives us a three-item list: the first number’s predecessor, the running total so far, and the second number. How do we get a sum from that? We take the running total and add one to it. Picking the middle item from a list is P/3/2, adding one is S, and when we glue ‘em up, we get [S o P/3/2].

Putting it all together, we have Add = PR[P/1/1, [S o P/3/2]].

If we had some kind of machine that understood all these pieces, we could feed it this definition of Add, give it two numbers, and watch as the correct sum came magically out the other end. Some would read this paragraph, scoff, and say, “Big deal. Even Windows Vista can add two numbers together.” But you’d never say that, no. You like knowing that you could build addition with your bare hands if an emergency called for it.

So here’s an Lisp-y implementation in Clojure that you can play with. For zero and the successor, Clojure has the constantly and inc built-in functions, respectively:


(def z (constantly 0))

(def s inc)

Composition — the glue function — is easy when we’re just sticking two single-value functions together:


(defn o [f g]
  (fn [x] (f (g x))))

This code just builds a new function f o g that takes a number x, runs it through a function g, and hands the result to another function, f.

Real life is a little more complicated, though. g may take more than one parameter, so we may need a bunch of x’s. Similarly, f may take more than one parameter, so we may need not just one g, but a slew of them. Calling a function with an unknown number of arguments is a job for apply, that cornerstone of Lisp programming:


(defn o [f & gs]
  (fn [& xs]
    (apply f
           (map
             (fn [g] (apply g xs))
             gs))))

Now for the picker and the flicker. The picker, remember, just returns a single list item. Clojure has a handy nth function for looking inside lists.


(defn p [_ subscript] (fn [& xs] (nth xs (dec subscript))))

You’ll notice that p ignores its first parameter; that’s just the list length, and we don’t need it for this exercise. Also, lists start at the zeroth item in Clojure, rather than the first—so we need to subtract one from our index.

That just leaves the flicker, primitive recursion. This definition is the most complicated one of the batch, but it’s still fairly straightforward. By convention, we take a function g for the zero case and h for the nonzero case. We then build a new function f that decides whether to call g or h based on the first value passed to it.


(defn p-r [g h]
  (fn f [x y]
    (if (zero? x)
        (g y)
        (let [prev (dec x)]
          (h prev (f prev y) y)))))

This limited PR won’t be able to define anything other than a two-argument function, but that’s enough for us to build and use addition:


(def add (p-r (p 1 1) (o s (p 3 2))))

(add 4 5) ;; => 9

Aside from making addition slower and harder to read, what has this bought us? Well, it’s given me peace of mind, since I can test my grad school homework answers after writing them. It was also a great excuse to learn the basics of Clojure and SLIME. But mostly, it was a chance to recapture that thrill of lining up all the building-block logic circuits to boot all the blue diamonds and make Rocky dance.

So have a peek at the latest version of the code. It does a bit more than what you see here, like checking the lengths of argument lists, and handling primitive recursion for any number of parameters. Happy kickin’!

the road to quineville

undees — 2008-12-16T22:38:34+00:00

A quine is a program that prints its own source code as output, without using any dirty tricks like “go find the file this source code lives in, and spit out the contents.”

Most programmers cut their baby teeth on neat tricks like quines. Others spend their undergrad years using electrons as the fundamental unit of computation, and don’t get to programming-language tomfoolery until much further on.

So, better late than never.

To see why writing a quine takes a bit of twisty thinking, consider this Ruby program:


puts

It just prints a blank line. How about this one?


puts 'puts'

That one prints the following:

puts

Okay, how about this?


puts 'puts "puts"'

That results in:

puts "puts"

No matter how many puts-es we have in there, we always need one more than we have. We need a way to hide a lil’ copy of the program inside itself. Let’s try to trick ourselves by scrambling it!

What if we could set up some variable s that contained a scrambled version of the program’s source?


s = "[scrambled source code]" 
puts s.unscramble

But to scramble the program, we’d have to know the whole text in advance—including the scrambled part! Instead, let’s imagine scrambling just a skeleton of the program, with the %s marker standing in for the scrambled part.

Here’s what the skeleton looks like:


s = "%s" 
puts s.unscramble % s

Now that we can scramble. Don’t worry about how yet. But once we’ve done so, the following program will be a quine:


s = "[scrambled skeleton]" 
puts s.unscramble % s

Almost. We still have to write the unscramble function and make sure the program has access to the definition.

Rather than manually scrambling the skeleton and pasting it into the program, I’ve built a “Quinerizer” class that does this for me. That way, it’s easy to change scramble / unscramble methods on a whim. In the spirit of swatting a fly with a Buick, Quinerizer has unit tests as well; feel free to peek at that code on your own.

Here’s the auto-generated quine using Base64 as a scrambling mechanism:


require 'base64'

class String
  def unscramble
    Base64.decode64 self
  end
end

s = "cmVxdWlyZSAnYmFzZTY0JwoKY2xhc3MgU3RyaW5nCiAgZGVmIHVuc2NyYW1i
bGUKICAgIEJhc2U2NC5kZWNvZGU2NCBzZWxmCiAgZW5kCmVuZAoKcyA9ICIl
cyIKCnB1dHMgcy51bnNjcmFtYmxlLnN1YigiJXMiLCBzKQo=
" 

puts s.unscramble.sub("%s", s)

Go ahead, try it!

This qualifies as a quine, but we can certainly be more space-efficient than Base64. Imagine using regular string quoting and printing (e.g., via String#inspect) instead of a scrambling and unscrambling routine. If we’re very careful with our percent signs and quote marks, we can condense the quine down to this:


s = "s = %s; puts s %% s.inspect"; puts s % s.inspect

This approach reaches its full logical extreme in Ryan Davis’s curt Ruby quine:


_="_=%p;puts _%%_";puts _%_

Hard to do much better than that.

fuzzy grad student

undees — 2008-12-16T20:26:36+00:00

With an intelligently rambunctious second-grader, a trouble-seeking one-year-old, a full-time job, a book to promote, and another book to write, I’d have to be stupid to take on anything else, right?

Heh.

Now I’m a fuzzy grad student, too. (The terminology comes from my old undergrad days, when we’d universally refer to all the masters / doctoral crowd, regardless of facial hair situation or even gender, as “fuzzy grad students.”) How did this happen?

Two things kind of led up to this foolishness. The first was Ackermann’s function, a programming rite of passage I’d decided to take a particularly strange whack at. It’s easy enough to do in Ruby, my favorite programming language, but—and here’s the teeth-gritting part—I insisted on doing it in a certain strange way, implementing language features Ruby was never meant to have.

Tilting at this windmill led to all sorts of mental bookkeeping about a single piece of code meaning different things in different contexts. “I’ve heard this stuff before,” says I, “from professional computer scientists. Maybe I should talk to some of those.”

The other thing that led me down this road was that a bunch of my co-workers got their OMSE (Oregon Master of Software Engineering) certificates, a kind of professional-track alternative to a traditional comp-sci master’s degree. They were beaming, of course, but also spoke coherently and specifically about what they got from the program.

I don’t think the OMSE is for me. There seems to be a lot of focus on doing anything but writing great programs. For example, there are a lot of courses in engineering budgets, time estimates, project management, bug tracking, and so on. All worthwhile endeavors, to be sure. But the gaps in my knowledge are in the egg-headed arena of context and meaning.

So I’m dipping my toes into the water and taking a few traditional master’s-level classes at Portland State, starting right smack dab in the middle of the gaping void with the Theory of Computation. The ink dried on the last of our final exams last week. I’ll let you know how it went.

In the meantime, a bunch of my half-assed experiments will probably show up from time to time on this blog. They will probably share the dual fault of being inscrutable to non-programmers and absurdly simple to experienced programmers. C’est la vie….

one!

undees — 2008-12-02T09:59:58+00:00

Hard to believe it’s been a whole year. Back then, all she could do was eat, sleep, and poop. Now, she can walk. And talk! She knows I’m “Daddy” (actually, sometimes anything bigger than her is “Dajjy”), Mommy is “Baba,” sister is “Adeeeeee,” and a cat or anything else you have to be gentle with is “Sof’.”

Some parents teach their children a simplified sign language. In our case, Robin taught us her own signs. A tug of the ear means, “I’m hungry.” Slapping the knees simultaneously means, “Yes, very amusing.” Slapping the knees alternately means, “You’ve got about three seconds to pick me up or I start shrieking.” And when she grabs her bare belly at bath time, we’re pretty sure she’s saying, “I appear not to be wearing a shirt any more. I find this hilarious for some reason.”

We did manage to get a couple of our signs to sink in with her. The standard stuff you’d expect: point at the mouth for “Eat,” touch the hands together for “More,” and reach out one-handed to say, “Give me that.” But my favorite sign that she picked up from us is this: when we do our best Homer Simpson and say, Don’t stop a-rockin’! she grins wildly and shakes her head from side to side.

i think it translates as...

undees — 2008-12-02T08:57:35+00:00

Another months-overdue post. Catching up on my posting backlog, though, which is is more than I can say for nearly every other sector of my life. This one’s about my summer vacation.

Well, I say vacation. But it wasn’t quite that, since my family came along, too. Har, har.

We’d been trying to find something to please everybody. Big sister wanted a pool. Little sister wanted an endless supply of booboo. Mommy wanted a spa. And Daddy wanted something bucolic and Northwest-y, so that (har, har) I could hole up and write—my idea of a break from writing stuff I have to is writing stuff I want to.

So we found Kah-Nee-Ta, a mysteriously-named casino slash resort on reservation land. Perfect! A little something for everyone, including my dad, who was in town from Texas.

KNT, as I’ll refer to it from now on, is out in the high desert not too far from Bend, a few hours from Portland. We stopped at the Timberline Lodge atop Mount Hood (thank you, FDR, for building it!) for lunch and enjoyed the sight of snow-starved skiers and boarders lugging their equipment up to “enjoy” a whole ten square yards of grey slush. Poor things. Winter will be here soon, dears.

Back on the road with the kids uncharacteristically and mercifully asleep, we wound down through the mountains and into the desert. I’d never seen that kind of terrain at such a high elevation. It’s a whole different ecosystem. At least the resort was easy to spot, sticking out of the desert like a slot machine in church.

We checked in as quickly as we could, since the pixie was itching to get to the pool. I took a moment to take in the paradox of a cedar log burning white-hot in the fireplace of a crisply air-conditioned lobby in the middle of the blasting heat of the desert. Oh well. Smelled nice.

Swim, road leftovers, talk, sleep. Up, breakfast, activities.

Today was horseback-riding day. The plan was to put the pixie on the tame, amble-around-the parking-lot ride. She wanted me to ride, too, so they put me on this poor pony that’s used to having kids on him. Sorry, fella. At least it was a short ride.

We also spent ages at the water park. Astoundingly, this was Lynn’s first trip ever to one. (I keep forgetting that there are parts of the country that aren’t totally saturated with the things.) Anyway, little one enjoyed splashing in the baby pool, while her big sister delighted in forcibly dunking her long-suffering supervisor.

The dinner options were singularly uninspiring. The buffet was literally a trough of food. Yes, trough. The expensive restaurant had exactly the same menu as the cheap one, but with much higher numbers after the items. The family gamely went for takeout, while I stormed back to the room and picked at what was left of the road food that hadn’t rotted yet.

You have to f… up pretty badly to come up with menu items so unappealing that even I can’t eat them, but KNT managed it that night. The greasy sauces and wilted salads that the family good-naturedly styrofoamed back to the room were worse than nothing. Things were rapidly approaching the three meals away from revolution stage: here we were two meals in, and I was ready to overthrow the whole vacation idea, toss everyone in the car, and drive back to Portland that night. To my embarrassment, I caught myself thinking really uncharitable thoughts about my fellow man, in particular the folks who seemed to be filing through the lobby in happy ignorance of the ripoff ride we were all being taken on. “How can you smile when you’re paying this kind of money to be treated like this?!?” I wanted to shout.

It’s worth pointing out that KNT doesn’t have to compete on price or quality, since they’re the only game for miles around when it comes to food. Would it kill ‘em to have a grocery store next door and a kitchenette somewhere near the rooms? The only alternatives are Bend, which is half an hour away, or going back home, the option I almost got away with.

But Lynn, the no-bullshit soul that she is, talked me back down with the expert technique of a hostage negotiator. (See, folks, this is why it’s crucial to choose a spouse with the right skill set.) Somehow, she got me through the night without a coup, and without my needing to eat the bedsheets.

Good thing, too, because things suddenly started looking up. Beginning with breakfast, the food quality started improving steadily. And the activities drifted away from the crowded, enforced-fun style, to the more relaxed, self-reliant feel. For instance, we took a much-needed cooling kayak trip down the Warm Springs River. My dad, easily the most experienced among us, was the first one tossed overboard. Hee hee! The pixie squealed as we blasted through the rapids, bounced off rocks, and generally ran circles around the other boats.

That night, we discovered that the poolside lounge had food that was orders of magnitude better than elsewhere, and they didn’t (ahem) soak us quite so much on the prices. So we got to eat at a relaxed pace, let the pixie swim safely on into the evening, and then just hop a few steps to the room when we were tired. Nice!

And that’s about all there is to tell. None of us set foot in the casino the whole time there; the only thing we gambled with was our sanity.