When I moved to SoCal I was scared of driving on the (nominally) right side of the road, since we in Oz drive on the left. A friend suggested a brilliant idea: put an attention-grabbing object on the curb-side of the dashboard. The object is like a little god in a shrine dedicated to keeping me out of incoming traffic. This blog is like that.

Sunday 27 October 2013

The Rum Rebellion v. The Tequila Uprising

Here's something of a leitmotif,
We shall not cease from exploration 
And the end of all our exploring 
Will be to arrive where we started 
And know the place for the first time. 
   T. S. Eliot, Four Quartets, "Little Gidding," V, 26-29
 I am in a new place thousands of miles from home, late in my life, with a clear view of both places ... sepia memories of one, flickering momentary impressions of the other.

Above all, one is always immersed in people, people are the proper country of people, and the natural environment of people.  So what stands out, most, are the little inexplicable differences in how people seem to think in both places.

In this, I'm going to be crashing through a forest of sprouting platitudes.  I'm not giving up my membership of the People's Liberation Front of Judea, but am interested in why the Romans had power, big highways, and a system of production which seems to favour creative pursuit of interesting projects.  Forgive my generalisations, in the sure and certain knowledge that all generalisation is bad, always.

As a general observation, just to work into the topic:  people in Southern California are a lot nicer than people in Sydney.  More polite, more considerate, easier-going on the roads and in person, less censorious and judgemental.  I get the impression that a lot of this arises from their internal narrative, which posits their locus of control inside the narrator and not in some always-absent all-seeing all-judging omniscient third person colonial administration.  I'm not saying the narrative is accurate, just that it motivates people to behave differently.  Examples abound, just ask me.

Anyway, I want to talk about the world of work.  I've been a contractor for more than 30 years, and have met more than my fair share of managers in technical realms.  In all that time, out of the hundreds, I've met no more than a handful who were any good at all.  Part of that is down to the corporate culture in which they operated, part of it is the nature of the kind of person selected for that role, part is what motivates them to undertake that role.

I want to think and talk about what is different here, and why I think it has to do with something broader in our respective cultures, and what that is.  "History," is what I'm essaying at the moment as the root cause of the differences.

Checking my privilege for a moment:  I'm a white boy working in a field of ideas.  I'm not talking about the experiences of the guys who stack supermarket shelves, or take my money in the local petrol station.  My observations arise from the privilege I've always had, to be working with my mind and not my hands.  I spent a week working on bricks, and apart from the pain, and the fact that my boss was a fan of Bertrand Russell, I wasn't very good at it.  It seemed like toil, and toil is stupid.

"Each person is history and a project," I think Sartre said that.  I don't think that is the case, though, in Oz technical management, where the existential truth is "Each unit of production is a time-sheet and a procedure."  This cartoon-distinction seems to explain much of what I see as the difference between Oz and SoCal.

It's not that there are no timesheets here, or people aren't accountable, no.  It's that the orientation is toward something which does (or may) produce a result.  There is procedure, but it is always in the service of outcome, not the other way around.

Why?  I would say because there is a narrative belief in outcome.  Yank internal narratives always have a happy ending, the good guys get the girl, the bad guys their come-uppance.  Even their high literature has endings ... Holden Caulfield discovers that everything goes 'round and 'round, Gatsby fails, but the narrator gets to moralise, Tom Joad will always be there.

Oz, I always come back to Voss.  Man organises a venture, man heads off into desert, man wanders helplessly lost, man becomes part of the landscape.  All the best Oz lit is about despair.  All the paintings are lost children, or Ned Kelly as a postbox, with the bush peeking out through the slit.  No one goes out back: that's that.

What we have is otherness, and estrangement from the real source of power.  And it's because we were a slave colony.  There was never a point in striking out alone, or with a small group ... you'd end up dead, and cannibalising your companions, not end up having a state named after you.  Every time a bunch of colonial Americans struck out for new places, they found a richer and better place (I explicitly except Utah from this.)  Every time explorers in Oz did the same, they ended up with "Dig" carved into a tree.  And the destinations in Oz: they always promised so richly and delivered only sand and bleached bones.

An internal locus of control, and a goal worth winning.  These are the first differences.

The second difference is the subjective narrative role of disruption.  The yanks had the Boston tea party, which they invest with values like casting off the yoke of oppression (although of course it was not just that) and with clearing a space for improvement.  The only truly successful uprising we ever had was the Rum Rebellion, which merely served to enrich the already wealthy, further oppress the already enslaved.

Disruption to structure and established process can be seen to have positive outcomes in Unistater narrative, but not in Oz.  That's the next difference.  Perhaps it's a difference in time scale, as in the long run we are all dead, Ozymandius and all that stone.

What I have found, and I can't say too much right now, is that working here is good.  Much better than Oz.  Here, I feel like what I do has value, what I'm good at has inherent merit, and my issues and concerns, my itches, are not merely the annoying ravings of a guy who's too lazy to fill in his timesheet, and get to work before 9am.

I dare to think that's because I found a place which shares my values, and so can be happy and among mental kin.  Shame it's so far from home.

I haven't changed.  I just changed where I plug in my laptop, and with whom I associate in daylight hours.  Whether this is an Ugly Duckling story, or a Flowers for Algernon, time will tell.

Current sound track:  Steely Dan, Aja.  Some guys moved from NYC to LA because the quality of musicianship was so much higher in LA, and proceeded to do an album of songs about homesickness for NYC.  Here's the story of its making ... a striving for perfection and realised vision in a context of alienation.  My kind of narrative!

Sunday 20 October 2013

Torrey Pines


Torrey Pine, Del Mar

Today I visited Torrey Pines State Natural Reserve in Del Mar/La Jolla.  I drove past/through/around it a couple of times, because the entrance was cleverly hidden behind a car park giving access to the beach.  People had been telling me it's the #1 nature spot in San Diego, and I well believe it.  Somewhere I read the word 'wilderness,' and brought a full pack, thinking I might get some hiking done.  Once I got there, it was apparent that this was not that place, so I repacked a litre of water into the 20 litre day pack I carry for emergencies (it packs down into about 10cc, and would carry water nicely) and joined a volunteer-guided walk focusing on the vegetation and ecosystem of maritime chaparral.

Adobe house C.1923 v. Yucca and Chaparral
I saw the plant Hollywood was named for, saw and smelled more kinds of sage than I knew existed, and saw some yucca close-up.

I was befriended by a trainee guide, a small German lady who's been living in SoCal for 20 years, but "longs for a grey day."  It is true, the relentless blue skies and bright sunlight can become oppressive.  Sometimes you just do not want to "have a nice day."

I saw the Torrey Pine, a very rare plant named for a botanist who never saw one growing, dependent on fog for water, hardy, long-growing, gnarled and sea-dwarfed.  They hang on here, and only one other place.  Good for them, I say.

My photography was hampered, somewhat, by the presence of others, so I only got a couple in, and in any case no serious study of the pine for which all the fuss is being made.  I got to name, and maybe begin to recognise, and in some furtive and illegal moments *smell* some of the vegetation.

I enjoyed the couple of hours walking slowly and the companionship of the small crew of tourists.

Where is the solitude, though?  I asked the guide, and he said, for his, Sequoia NP was the place.  So ... maybe I'll set my sights on that.

Here's a gallery of the few photos I took.  The beauty of this place is subtle, and hard to find.  It's in the small things.

The guide told us that there's only one native species of ant here, the red harvester ant, and its population is collapsing because of the incursion of argentine ants.  We observed a little battle in the unremitting war.  It really doesn't look good for the locals, though:  as this radiolab ep explains.

So, if you look at the Oz bush ecosystems, they have really poor biodiversity, until you look at the scale of ants - all the biodiversity is there.  It was all I could do to stop myself mentioning this to the guide.  You can walk 50 metres in Oz, and you will cross the range of a dozen different species of ants.

Wednesday 16 October 2013

Hummingbirds smaller than moths

I got to observe one of these cuties this morning


She was getting nectar from a hibiscus, and as it's late in the season she was prepared to tolerate me watching (from a distance) for about 30s as she fed.

These critters are amazing, they're smaller than a bogong moth, and they just never stop moving.  They're so profligate in their use of energy that I've seen one hover where another bird would roost.

Sunday 13 October 2013

Chewing Gum while Running (Geek Post)

Tcl and Network/Process Control

Tcl is very good for network/process-control systems because it has an event system built in, because it's strong on string manipulation, and most recently because it has coroutines. This is not surprising, really, because of its pedigree. Tcl, as an embedded control language, has this kind of thing in its DNA (as the cliche goes.)

The purpose of this page it to explore, in abstract, the kinds of facilities Tcl provides across the whole range of network/process-control systems, and which language cliches are useful when Tcl facilities must be blended together, and where Tcl could be improved to suit these applications.

Ideal Client/Server

Most (if not all) network/control systems involve message passing of some kind. Request-response, indication-confirmation: a chunk of data arrives, something is done with it, and a chunk of data is returned to the caller.

Ideal Server

  1. session starts,
  2. request is received,
  3. processing occurs,
  4. response is sent
  5. repeat 2-4
  6. session terminates.
Lexicon: session above can be synonymous with transaction, connection, pipeline.

A simple example is a time-of-day server. (1,2) A connection opens (implying a request,) (3) the current time of day is calculated and formatted, and (4) returned. (5,6) The connection is closed by the recipient.

This simple case is amply served by event-driven code which runs to completion. Any time taken to perform processing is considered negligible, such that there is no requirement for multiple threads of control to intervene, provide input to, or suspend processing.


The Ideal Client looks very similar to the server:

  1. establish session,
  2. send request,
  3. wait for response,
  4. receive response,
  5. repeat 2-4,
  6. session terminates.
Each client state has 1:1 mapping to a presumed/hypothetical ideal server state.

And this is how we like it. It makes life simpler to reason about.

An ideal client can be written [Connect(); foreach request $requests {Send(); Receive();} Disconnect()], and the current execution state is the current communication state ... the client can put its grubby index finger on one place in the code, and say "we have Connected, Sent, Received or Disconnected. This is a considerable benefit in writing and reasoning about client code.

The idealised model is also useful in that it expresses (in plain English) the passivity of the server. All of the verbs describing server processing are in the passive voice, all of the verbs describing client processing are in the active voice - consistent with how we think about clients and servers.

These two models serve well in many cases, but not in all. In particular, the implicit control flow in the ideal client is mostly linear (or clearly nested loops) and single-threaded.

Complexity 1 - the multi-client server

Naive run-to-completion won't work if you expect to be able to serve an arbitrary number of clients with an arbitrary number of requests per client (apparently) simultaneously, because while you're serving the current client's requests you can't serve any other client requests.

Examples of real protocols where server naive run-to-completion will possibly work include strict original HTTP 1.0 ... (others?) because although HTTP 1.0 servers expect to serve multiple clients, each client's requests per connection are limited to 1 per connection. Of course, in practice this never happened, because the extreme expense of setting up and tearing down a TCP connection per request was prohibitive.

A run-to-completion model for servers, where each request is processed completely and replied to before any other request is considered or acted upon can work, but only if the time to process is short and in any case bounded [Assumption 1]. In practice (outside of contrived examples,) this seldom happens, so in practice the strict run-to-completion server is limited to a server with a single client, and the interactions could more properly be regarded as remote procedure calls.

A more realistic example is a server providing HTTP 1.0 + 100 Continue messages to multiple clients ... these are expected to provide an arbitrary number of clients the ability to request multiple entities, and must use Tcl events to provide this service.

The good news is that each 'session' is adequately identified by a single instance of Tcl connection /channel, and the Tcl fileevent facility is sufficient (in theory) to contain/represent all state relevant to a given client instance in the server (all state could be associated with the script prefix in a pending fileevent, and could therefore be inspected/mutated in that locus.)

In practice, then, a slight variant on the ideal server is often adopted:

Quasi-Ideal Server:

  1. session starts on $chan, [fileevent readable State2 $chan; return]
  2. request is received,
  3. processing occurs,
  4. response is sent
  5. repeat 2-4
  6. session terminates.
The [fileevent readable State2 $chan; return] cliche has the effect of freeing the server to accept more connections on new channels. Reception, processing, response are all able to be implemented in run-to-completion form within the readable event-handler.

Note, all of this processing, 2-6, could be performed in a Tcl thread, and written linearly. However, the overhead of creating/maintaining/destroying a thread per client instance is prohibitive, complex, doesn't scale (insert your favourite scare-words here) and since Tcl provides for a lighter-weight alternative, why not use it?

coroutines provide an even cleaner approach to this problem, in that they permit states 2-6 to be encapsulated in a proc or apply wrapper, and written as if they expressed a single thread of control (using green threads.) This is wonderful, in that it makes the server again look as simple as the client.

But ... all too predictably, it isn't sufficient ... if State (3) processing entails (a) access to shared resources, or (b) external systems, or (c) subsystems which take considerable time to complete, run-to-completion of processing will inevitably degrade the client-illusion of having a dedicated server. Assumption 1 is often invalid, but not often enough that Tcl has evolved any particular strengths in facilities to handle it, so here's where the fun starts.

Complexity 2 - the multi-client server with unbounded processing

A well-known example of this is database access.

Quasi-Ideal Server Split in two

  1. session starts on $chan, [fileevent readable State2 $chan; return]
  2. request is received,
  3. processing starts
  4. repeat 2-4
  5. session terminates
and its accompanying half
  1. processing occurs, then completes
  2. response is sent
Here, the completion of processing is an event which runs in a distinct thread of control, maybe a thread or maybe as a consequence of an external event.

Processing could be querying a database, fetching a web page from a different server, getting some readings from an external device that is going to take a while, invoking an external program under unix, or it could just be complex processing which is going to take a long time and is delegated to a thread. Often, processing entails the server acting as a client to a different server. Notably, the Ideal Client is often chosen as the appropriate model to express inter-server processing.

Complexity 3 - multi-client server with scatter-gather

If the server's processing phase requires more than a single interaction with external asynchronous data sources, the usual choice is to make these requests synchronously and await their completion, effectively to enact the Ideal Client with multiple Ideal Servers.

Sometimes this just won't work as well as it might. Examples: A server which functions as an SMTP client, in which an email can be sent, simultaneously, to a large number of recipient machines, and resultant delivery success/failure is to be reported to the server's client. In this case, processing is complete when all client-relationships terminate. The appropriate paradigm is scatter-gather.

The problem here is that Tcl doesn't provide any obvious way to aggregate responses from asynchronous processes, but it does provide one: variable traces on arrays and on array elements. Using this mechanism, it is efficient to wait on both individual channels and on the set of all channels, orthogonally giving events per-external resource, and events on the entire collection of resources.

Criticism of Ideal Client

Humans are notoriously bad at dividing their attention (and not just people who are a bit autistic, like me.) We can't talk on the phone and drive, some of us can't walk and chew gum at the same time.

Computers aren't bad at multi-focal attention at all, but (I posit) because we're bad at it, we build our faults into our code.

Tcl coroutines are able to provide a perfect illusion of single thread of control while accessing chans, by means of Coronet(a package which hides the event system in a nice coroutine-enabled wrapper.) This advances the [green threads] for Tcl project, and also raises the question: if threads are now green, and we can use them anywhere, even to the extent of shoehorning code into green threads without it having to be modified ... where are the control mechanisms and language cliches which exploit that simplicity to give us more expressive power?

Tuesday 8 October 2013

Hike Report (overdue) Hollenbeck Canyon

I took a wander along Hollenbeck Canyon, just to get a sense of the country.  I stopped in Jamuz to ask for directions, they'd never heard of it ... it was all of 5 miles out of town, in a non-fashionable direction, so fair enough.  They went so far as to deny its existence, because if it'd been there, they'd surely have heard of it.  I'm sure there's a parable there about foreign policy.

It's a desert here, who'd have thought?  And so much granite, more than I've ever seen in one place.  Theoretically, then, this would make the soil quite fertile, except for the whole desert thing.  The land was formed by vulcanism 20 million years ago.  Imagine that, those hills and mountainettes are over 20 million years old.  Shows how hard granite it.

View South from a Private Road

 The nicest thing about this country is the far vistas, no trees to obscure the view.  In this place, one could actually use a compass to take back-bearings, assuming only that one could obtain USGS maps.  I'm told printing them is the best option.  It's nice that they're free.

Sage of some kind
 The vegetation is all low herbaceous stuff, so dry, so flammable, but the total biomass is really quite low (compared to what I'm used to.)  I think they call this land form chaparral.  Maybe that's where 'chaps' comes from too.  I dunno.  You'd definitely want gaiters if you intended any kind of cross country walking.  This place would be full of rattlesnakes.
 

The course of my wandering followed a formed road along a creek.  The creek wasn't flowing, though it had some pretty deep, pretty stagnant, pools of water.

Old brick hearth, part of a ruin

And people lived here, once.  Then thought better of it.

Oak in the landscape

By its occasional flows, the creek supports a reasonably rich and diverse local ecosystem.  It is accompanied in its course by some kind of oak, some kind of tough gnarled wind and drought resistant oak.  Good for the oaks, I say!


 And the oaks support squirrels (you can see one in this photo, if you squint.)  And the squirrels support rattlesnakes.  And the rattlesnakes support road-runners.  And road-runners supported the Depatie-Freling animation studio long after they'd run out of ideas.

I actually saw a road-runner!  Just a fleeting glimpse as he barrelled across the track about 50 meters ahead of me.  He looked like a chicken on stilts, but black with a red topnotch.  I looked, but could not see an accompanying coyote.  I imagine he was hiding behind an ACME rocket launcher or something.  I think people could improve the landscape by nailing ACME signs to things.

One distinctive difference between Oz and here ... hardly any ants.  Not much insect life at all, really.

Mount Lyons or something.

That mountain up ahead has a webcam on it.  Here are some photos from there. You can find videos of what the San Diegans laughingly call wildfires taken from that peak.  Of course, I got nowhere near it, that thing is *high*.

And the end of all our wanderings shall be a bloody nice margarita

Sunday 6 October 2013

We have achieved extraction.

This!  This is a double-shot espresso.  The stuff on top is called 'crema' and it is the tasty bit.  It is bitter, yet it does not taste like insect shells.  It is coffee.

I made it with a cheap-as $89 proper espresso machine from Macy's, and some ultra-premium coffee (sadly, ground over a month ago.)

It tastes good!  You don't *need* fluffy milk to go with it, it tastes so good.

Someone in the USA ought to learn to make something like it, with crema.  I'd even pay for a cup of it.