28 Apr 2008
And my publicist and stylist, oh and Mom and Dad…
But mostly Howard Butler for nominating me and the rest of the Mapserver PSC for accepting me as a Mapserver committer. I guess my crazy ideas and cockeyed schemes didn’t scare them off!
You like me! You really like me!
25 Apr 2008
I
took a day on Wednesday to travel to Vancouver and apply for a US passport. The US passport form is pretty straightforward, but the consulate experience is anything but.
Step 1: Getting an appointment. Last month, before my last trip to Vancouver, I thought I might combine the trip and take care of the passport application at the same time. No dice, appointments for passports are booked up a month in advance!
Step 2: Getting in. I arrive at the building, which has a security checkpoint on the ground floor (consulate is on floor 20):
Necessity is the mother of invention, so I run across the street and ask the counter-lady in a dime store to hold my laptop and phone. She graciously agrees. Now electronics-free, I return, and am allowed in.
Step 3: Going up. Me and a group of VISA applicants (pity the poor VISA applicants) wait for the secure elevator. The doors open, and there inside is a delivery guy with a palette of Dell computers! OK, we squeeze in, and the security guard swipes his card and presses the button for 20th, then gets out. We go up one floor. Someone gets on from the general building population! We go up to 17, and the Dell guy gets off with his computers. At 20, we get off, having traversed the world’s most porous security cordon. However, it does explain…
Step 4: Getting in, again. Despite having gone through a screening on the ground floor, you get screened once more on 20! No doubt because the ground floor screening simply lets you back out into the general building population.
Step 5: Waiting. Even though my appointment is for 10am, the more experienced people with me say that they have waited for as much as 2 hours in the past in order to be served. I am fortunate, and only wait 20 minutes.
Step 6: The envelope please. The staffer who takes my papers and walks through them is very helpful, but at the end he has a strange request. In order for me to get my passport, they have to mail it to me. However, they have cancelled their old courier contract. Would I mind going to the building across the street, buying an ExpressPost envelope and returning it to him, so he can mail the passport.
Step 7: Out, down, buy, back, in, up, in. Getting out and back in is faster now that I now the drill. Rather than asking me my business, the security guards just look at my purchase, nod sagely and say “Ahhh. Envelope.” I am joined on the elevator by two other applicants, envelopes in hand.
Step 8: Done. Back on the street, I put my belt back on, recover my electronics from the dime store and tip the nice lady, and head out.
There is a nice business opportunity available for anyone who wants to stand outside the US Consulate in Vancouver and run a phone check business for $1-per-phone. You could probably sell ExpressPost envelopes while you were at it.
21 Apr 2008
One of my favorite software articles ever is Joel Spolsky’s “Law of Leaky Abstractions”, which is about the (unavoidable) dangers of building on software abstractions. Unavoidable, because the whole edifice of programming is built on layer upon layer of abstractions. Dangerous, because not having an understanding of what is happening below your working abstraction can lead to unintentionally terrible mistakes.
The release of Google’s App Engine and earlier releases of various components of Amazon Web Services (storage, queueing, database, computing) serve as a reminder that the process of adding abstraction has not come to a stop, but it has migrated for the moment to a new field. Instead of adding a programming layer, Google and Amazon have added a deployment layer of abstraction – you no longer need to know or care what machine your application is running on, or where that machine is.
As with other layers of abstraction, this new deployment abstraction will introduce new (yet to be discovered) programming pitfalls, but it will also liberate developers (and the businesses that hire them) to spend less time (and money) mucking with operating system set-up, database tuning, fail-over and replication systems, and other necessary details of server administration. The tasks involved in setting up a reliable server farm are both irrelevant to most aspects of application development and highly repetitive – ripe for being abstracted away, in other words.
As with previous abstractions (microcode, higher level languages, operating systems, object/relational mappings) the “platform as a service” (PaaS) abstraction removes a category of complication and replaces it with a new choice: what web service platform (abstraction) shall I use for my application?
Do I tie myself to Google? Amazon? Sun? Microsoft?
If all this sounds vaguely familiar, that’s because it is exactly the same decision process involved in choosing which implementation of a persistence abstraction (Oracle? MySQL? PostgreSQL?) or process management/filesystem abstraction (Linux? Solaris? Windows?) or O/R abstraction (Hibernate? JPOX?) you are going to use for your application.
And the same trade-offs apply. Do I like the implementation of this abstraction? Do I trust the vendor (to not screw me, to not go out of business)? Can I afford it?
If there is one thing missing from the PaaS tapestry so far (not counting Microsoft’s no-doubt-forthcoming entry to the field), it is a strong “open source” thread. Unlike open source software, open source PaaS can’t be replicated at zero cost (servers must be purchased, plugged in, cooled, etc) but PaaS can go “open sourceish” via: standard service APIs, allowing users to migrate easily from provider to provider; standardization on some open source components that fit the PaaS model (like Hadoop and Linux virtualization as already demonstrated by AWS).
Open source tends to be fast-follower, so I expect third-party deployable versions of the App Engine and AWS APIs will come soon enough. To me, the last couple years feel like 1995 all over again – just when you think you understand the structures of computing, the core premises are overthrown and everything is fresh again. In 1995 it was the internet and Linux shaking the foundations of the Windows hegemony; this time it is the cloud, wiping away the last vestiges of local computing context.
19 Apr 2008
Very odd. This evening, I want to read Chris Schmidt’s latest blog post, and what I saw was this:
What? Apparently Chris is distributing “badware”. I’ll be interested to see how this shakes up, if Chris’ site got schmutzed or if the “anti-phishing site” Firefox is aligned with made a mistake.
What is very odd is that Firefox resolutely refuses to take me to Chris’ site. Safari, on the other hand, cannot display anything at all from the site, which perhaps means “bad things afoot”. Glad I am not Chris’ sysadmin tonight (or Chris, assuming sysadmin == Chris).
18 Apr 2008
Daniel Morissette spills the beans on the mapserver-users list:
IIRC, LOG only logs some info on the mapserv request status at the end of its execution. I don’t use it much and don’t know much about it.
To get debugging output, with MapServer 5.0+, set:
CONFIG “MS_ERRORFILE” “/var/tmp/ms.log”
… and then set DEBUG level (ON, or number between 1 and 5) at the top-level in the mapfile and in each layer for which you want debugging output.
More details are available in RFC-28: http://mapserver.gis.umn.edu/development/rfc/ms-rfc-28
If there is something definitively “bad” about modern Mapserver it is the migration of configuration directives into “magic string” blocks of the map file, which are much less well documented that the “official” elements of the file.
CONFIG, PROCESSING, METADATA, that’s right, I’m looking at you.
