[San-Diego-pm] Meeting today (Monday, March 13th, 2006)
tkil at scrye.com
Tue Mar 14 02:26:10 PST 2006
In attendance were: Joel, Emile, David, Menolly, and me.
Notes from memory:
* Joel and I discussed GPS geodes and datums (that's /got/ to be
wrong!), especially w.r.t. his experience of not having google maps
grids mesh with what he was observing in the field with his GPS
No conclusions were made, but I did link to this pic, made from a
bike ride I did last weekend and www.gpsvisualizer.com
FWIW, my GPS unit (Garmin eTrex Vista) has a setting for which datum
to use (Main Menu -> Setup -> Units -> Map Datum) with... a *lot* of
options. J reports that his GPS unit and his survey maps (mostly
NAD'27 datum) seem to coincide, so good for him -- but it's
something to watch out for.
(In this particular case, he's looking for a particular location; it
sounds like he needs to ascertain which datum that location was
surveyed against, and either set his GPS for that datum, or
translate the given location to the datum used by his current GPS
settings and maps.)
* We discussed some aspects of the inside-out object pattern, and I
tried to come up with an example on the spot. Sadly, between having
little creativity and having spent *WAY* too much time with java
lately, it took me a while, but I eventually had a primitive example
that demonstrated the three advantages of i-o objects:
- compile-time field name checking
- lexical hashes to hide data within a package
- subclass field names can't collide with superclass field names
The example can be found at:
Note that this does *not* implement the necessary DESTROY functions,
so it will leak memory. Presumably with a leg raised.
I actually have lingering questions over the proper way to implement
DESTROY; the way described in his internal presentation and in the
article seem to want to call grandparent class destructors too many
times, but I need to stare at it some more before I'm sure.
* Emile had an interesting problem where he was trying to factor
presentation away from business / processing logic when the subject
is a highly recursive structure (in his case, physical locations,
mount points, nfs shares, filenames, oh my!).
I suggested the "Visitor" pattern from the "gang of four" book:
And there is indeed a Simple::Tree::Visitor class (Emile is using
S::T in his current work.) I was also a sick little monkey and
recommended XSLT, but I'm a bastard like that. We look forward to
hearing the results of his experimentation. (Hint hint.)
Odds and sods:
* Joel mused about upgrading his hiking GPS. I'm happy with my Garmin
eTrex Vista, although I lust after the eTrex Vista C and the new Cx
model (the latter having an expandable memory slot). Or their
one-notch-higher GPSMAP 76Cx. Mmm. Unfortunately, entry into those
clubs is in the 300$ range; J was looking more at lightly used
models in the 50$ range. Fair enough.
* J also mentioned my editing environment on my [work related!
honest!] windows laptop. I've managed to get 95% of my unixy
environment on this box, mostly through:
A free SSH client + VTxxx/xterm emulator for windows (also
pagaent, an ssh-agent)
GNU Emacs ported to win32
CVS for nt
A port of many common unix utils (i use mostly grep and perl) to
windows, as well as a bash shell.
I also installed a bunch of Java utils (JDK, Tomcat, NetBeans) to
c:\java; it's probably best to avoid paths with any spaces for that
Anyway, if anyone else is an emacs fan that would like a comfortable
light-on-dark editing experience, my current _emacs file is
Lots of cruft has accumulated there, but the font-lock and faces
bits are releavant for the editing experience I was "showing off" at
* J further related some issues he was having sending mail to Juno
e-mail subscribers. Indications pointed to him being on the
Spamhaus.org RBL, but that hadn't been fruitful.
The best we could suggest was for him to get a juno account himself,
and see what it took for him to receive mail from his external
Did I miss anything? Updates and corrections welcome.
More information about the San-Diego-pm