another blog

Commutes.

Best commute I ever had was the summer just out of high school when I was changing sprinklers for a farmer towards the upper end of the rural valley I lived in. I'd drive 30 miles each way over traffic-free county roads and never tire of the unbounded postcard scenery. Gas was a lot cheaper back then.

Oddest commute was during my brief business stint in Seoul. The office of my host, on the outskirts, wasn't near any subway lines, so I took a cab to work each morning. Rush hours in Seoul seems routinely more deadlocked than anything I've experienced at home. But, as maybe happens anywhere, I got used to it, and I eventually always did get to where I wanted. What I never grew accustomed to was some of the local driving idioms. Like being in the far right of six lanes of heavy rush hour traffic and making a slow speed U turn, cutting across all lanes. This seemed a fairly standard maneuver. Less common, but more alarming was making use of a sidewalk as an extra traffic lane when all other lanes are at capacity.

In spite of the seeming deadlock, that Korean traffic did seem more orderly. I never saw any traffic accidents while there.

During my three weeks in Seoul, I noticed a total of only three bicycle commuters. Possibly I just wasn't looking in the right places. When in Tokyo the previous year, bicycle commuters seemed commonplace.

Nowadays, when home, I'm primarily a bicycle commuter. To get from my island home to the office in downtown Bellevue, takes an hour on the road and 45 minutes on the ferry into Seattle. Other that the few blocks through downtown Seattle, the ride is away from heavy traffic. Now the scenery isn't as consistently spectacular as for that long ago summer job commute. But I suppose that serves to make the good days more noteworthy.

I'm back

An astute reader might notice a bit of a gap in entry dates. That pretty much corresponds to the year of my intense involvement with a phone project. The task was to build a full featured phone UI using the UI Engine and associated toolset previously developed by UIEvolution. (NDA says I can't disclose project details.)

My initial task was to develop the 'platform interface' part of calling. Getting up to speed on the platform included some back and forth travel to Seoul, to work directly with manufacturer engineers. I still don't understand the appeal of kim chee, but I did manage to pick up a fair bit of knowledge about CDMA protocols along the way. My initial role later morphed into project lead, where I had a significant hand in most pieces of the application.

A modern phone is a complicated beast. Besides calling, the most substantial chunks were address book, messaging, media access and camera. Fun project.

Game on.

There are few board ['bored'] games we play regularly at our house. Several of us like the idea of Monpoly, but we've never really got up enough steam to actually play the game to its bitter and glorious conclusion. At least not via the official rulebook. Over the years, we've refined our local rules to a much abridged game that we call "Start Monoply". To play "Start Monopoly", we randomly deal out all the properties beforehand and have a vigorous round of trading wherein each player tries to maximize holdings according to their preferred metric. Then, at the first turn each player buys housing for any monopolies as desired. Usually, the clear winner is pretty well determined by the 3rd or 4th turn, at which point, we call it done and move on to other activities. "Start Monopoly" typically takes about thirty minutes to play.

Book Update. Phone update.

Still using that book reader app on my cell phone. Since finishing Moby Dick, I've also read "A Room of One's Own" and am now partway through Frankenstein. A couple of months back, I switched phones -- from the LG VX8000 to a VX9800. The new VX9800 doesn't work nearly as well in one handed reader mode as the old 8000. It's got the flip out qwerty keyboard, with keys that are too small for most functions. The cursor keys are especially challenging for my fat fingers to hit reliably. The inside display is nice, but the inside keyboard interface seems optimized for two handed (hunt and peck) use.

I plugged a 1GB memory card into the phone and loaded it up with mp3 music content. (The phone is billed as a multimedia platform, and looks to have good hardware support for audio and video.) It does sound pretty good. But it's no IPod killer. Too damn big and heavy. I'm not a real fan of personal audio devices anyway. [aka, Personal Isolation Devices.] Was mostly just feeling obliged to experiment with current multimedia capabilities, since I work for a subsidiary of one of the bigger computer game makers in the world.

BookReader

A few years back I carried around a PDA (PocketPC) for a while. I used it mainly for reading books, mostly while waiting to do something else. (Waiting to ride the bus or ferry. Waiting to buy something in the store.) I liked being able to read even under lousy lighting conditions.

Downsides were the size of the PDA (at the time, the typical PocketPC didn't easily fit in my pocket) and its relatively short battery life. After reading a few books, I set the PDA aside.

Nowadays, the computing functionality of my cell phone is approaching that of the PDA I used before. I wrote a little bookreader app for the phone, and grabbed some uncopyrighted book content from the guttenberg.org site. The phone can't hold as much local content, but it does have a fair sized cache, and can pull in content on the fly as needed. The smaller phone display (I use an LG VX8000, which has a usable display resolution of 176x203) doesn't show as much text per page as the PDA did, but it still seems sufficiently readable to me. The reader can show text in either of 2 different sizes.

With the larger text size, about 50 words get rendered on the screen. The smaller text allows about 70 words per screen. The improved portability more than compensates for the smaller display size. I just about always have my phone with me.

Am currently reading Moby Dick via the phone. (One of those titles that's been on my 'to read' list forever). Am about a quarter of the way through so far.

Blush

Another reason it took me so long to put up a blog is that I knew it would highlight the amount of time between inspirations (or whatever it is that results in the next blog entry).

In the absence of proper inspiration, I guess we'll designate this a slog entry...

I just went back and looked at that pinger script. It's been running for a month, and the results are mildly interesting (to me anyway). We haven't experienced any major network outage from our provider during that time. The most siginificant outage happened one Friday evening for nearly three minutes. Definitely long enough to generate a support call or three.

6:06p Fri -- 66.77.88.99 response received -- 0ms 
6:06p Fri -- 66.77.88.99 NO response received -- 1000ms 
6:07p Fri -- 66.77.88.99 NO response received -- 1000ms 
6:07p Fri -- 66.77.88.99 NO response received -- 1000ms 
6:07p Fri -- 66.77.88.99 NO response received -- 1000ms 
6:08p Fri -- 66.77.88.99 NO response received -- 1000ms 
6:08p Fri -- 66.77.88.99 NO response received -- 1000ms 
6:09p Fri -- 66.77.88.99 response received -- 10ms

And a few times a week, we see smaller, variously scattered clusters of timeouts. May result from denial of service activity on our side, or routing instability on their side. I think their side, since I'm able to get to my device just fine from my side. Sometime,I'll see if I can reduce this info down to a few digestible statistics.

Service Scripts

That connectivity script has several of the features of what I think of as 'service grade system monitor scripting'. These are long running scripts that continually monitor the status of some system characteristic, and do something useful with the results. The simpler scripts just record their results to a log file. More complex scripts can also scan results for alarm conditions and fire alarms as appropriate. (There's always an element of reinventing snmp management software functionality when treading this path. But there can be good reason to roll your own.)
These service grade scripts:

check for status while running in a continual loop.
on startup, will not launch a second loop if they're already running (to facilitate relaunch from the OS task scheduler.)
log results to a length limited output file.
can open a channel to the resource in question, typically via the filesystem, telnet, http, ftp or snmp.
aren't particulary dependent on where they sit in the filesystem, or on the current working directory.
tend to provide both positive and negative feedback.
may detect alarm conditions and send alarms as appropriate (say, via email or sms).

I have this kind of script running all over the network. Some in conjunction with mrtg, others as standalone. Some of the network sites we monitor are fairly remote and expensive to get to. (Especially the mountaintops in the dead of winter.) The scripted warning system has helped us to assure sanity as the system grows in complexity.

Whenever we get surprised by a system outage or anomaly, we consider ways to automate the handling of its next occurance. In the case of the outage yesterday, it took us a while to pinpoint the breakage to the specific edge connection, and once we did, we didn't have a precice profile trace of the outage. If that particular breakage happens again, we'll consider adding a watcher to the new logfile to fire alarm messages as appropriate.

Connection Logger Script

here's that logger script I made yesterday.


@goto start
pixPasswordHere




enable
pixEnablePasswordHere
ping 55.111.22.3
exit

exit

(the above cruft is used by nc.exe as telnet session input)
(replace passwords and neighbor IP address as appropriate.)

:: expected output:
10:54a Sun -- 55.111.22.3 response received -- 10ms
10:55a Sun -- 55.111.22.3 response received -- 10ms
10:56a Sun -- 55.111.22.3 NO response received -- 1000ms 
10:56a Sun -- 55.111.22.3 response received -- 10ms
10:57a Sun -- 55.111.22.3 response received -- 10ms


:start
@echo off

:: -----------------
:: pingNN.cmd
::
:: keep a running log of connection state from edge PIX to upstream interface
:: (periodically telnet into the PIX and save response of ping to its neighbor)
::
:: uses: 
::   netcat (aka, nc.exe) for scripting the telnet connection.
::   perl
::   unique.pl perl script to filter out contiguous duplicate lines of text.
::   limitAt.bat keeps a file from growing past the specified size
:: -----------------


set PixIP=10.10.2.2

set delaySeconds=20
set loopDelay=perl -e "sleep %delaySeconds%"

set maxLogfileSize=5000000

set mylogdir=c:\limited
if not exist %mylogdir% md %mylogdir%
set mylogfile=%mylogdir%\pingNN-fromPIX.log

:: check age of %mylogfile%
if not exist %mylogfile% goto checked
for /f %%a in ('perl -e "use File::stat;print time-stat('%mylogfile%')->mtime" ') do set age=%%a
:: quit if already running
if %age% LSS 300 (
    echo Already appears to be Running...
    goto :eof
    ) else (
  echo.>>%mylogfile%
  )

:checked

:loop
for /f %%a in ('time/t') do (
  for /f %%x in ('date/t') do (
    for /f "tokens=*" %%m in ('nc -i 5 %PixIP% ^<%~fs0 ^| find "response" ^|perl c:\bat\unique.pl') do (
      echo %%a %%x -- %%m
      echo %%a %%x -- %%m >> %mylogfile%
      )
    )
  )
%loopDelay%
if exist %mylogfile% call c:\bat\limitAt %maxLogfileSize% %mylogfile% old
goto loop

Outage this morning

Got a call from Erik yesterday morning. The network (methownet.com) was experiencing intermittent outages. Erik had already done most of the troubleshooting. The only additional info needed was specifically where the connectivity broke down. After a bit more poking around, we learned that the break seemed to happen between the device (firewall) on the outer edge of our network and our providers device on that same subnet.

I called our provider to let them know that we were needing some attention, and then wrote a script to keep an ongoing log of the connectivity status for that critical link.

chasing the blog bandwagon

Been intending to do this for ages. Until now, I haven't made time to scrape together the pieces needed. Due to my paranoid control freakish leanings, I won't use one of the free blogging sites. I'd rather stay more in control of how this gets used. Or unused.

I just came across this blog script at blosxom.com, and it looked simple enough to try. So here we are.

Introduction? I'm Steve. Middle-aged geek of the computing persuasion. Here's a picture of me (lower photo, on the right) a couple years ago when I was working with my bro Jeff and friends to build an ISP network into rural Winthrop WA. Jeff and Maria still run the network, and I still help out on the side (wearing my network engineer hat). Nine months ago, I returned fulltime to my primary career, programming. I'm now writing applications to run mostly on cell phones, for UIEvolution in Bellevue, WA. (Java and C++, in case you're interested.)

On the home front, been married to Fon Wen for alarmingly close to twenty years. (That used to sound like longer.) We raise our daughters, Lia and Ursula at our home on Bainbridge Island.