Third Opinion: Perennially Mistaken Tech Journalist Overreacts
Honestly, is anybody more consistently wrong in his assessments than John Dvorak? He's like the drunken blowhard uncle of the tech industry: he's family, so he's always invited to the party. But he always makes a scene after his third Dewars.

John Dvorak
The tradition of the troll is a long and storied one, and Dvorak has to be considered one of the old pros. He got his start with opinion pages in the cheap-newsprint free monthlies you'd find at the local mom & pop computer shop, but nowadays, well into the Participation Age as our Fearless Leaders like to call it, he's got to compete with every young buck that has access to a WiFi connection and a blogging service.
Like watching Rod Carew in the '80s at Angel Stadium, we should just sit back and marvel at the hyperbole (worst acquisition ever?) and odd asides (umm, you're still bitter about a marginal acquisition from 1987?), how effortlessly and economically they come. It takes years to shut up the mind's internal censor enough to make clumsy, inappropriate, oh-so-close-to-bigoted comparisons to Mao Zedong, and ominous conspiracy theories darkly hinted at through mid-story headings, so keep practicing kids! The upstart trolls of this generation are as free swinging with the facts as ol' Johnny D, but the kind of willful ignorance of the modern rules of the game he displays (in this case, how the terms of the GPL precludes any company, including Sun, from "wresting control" of MySQL's codebase; also, suggesting that Oracle and Sun have some sort of back-handed and massively illegal accounting pipeline being used to fund the MySQL acquisition)? Well, that's just audacious. He's enshrined under the Big Bridge at Cooperstown for good reason.
So Mr. Dvorak, from this young troll just starting out, I say, "Master."
This week I'm attending the Web 2.0 Expo here in San Francisco. Yesterday I attended two sessions, one about security (or the lack thereof) in Web 2.0 applications, the other about how Facebook redesigned their developer APIs to use a SQL-like language to help simplify things for their 3rd-party developers.
Complicating matters is my chipped scaphoid bone in my left hand, thanks to a bike accident last week.
Luckily I got my plaster splint off yesterday, which was replaced by a wrist brace, so I can type a little bit better, and can shower without a plastic garbage bag over my arm. I'd never had a cast before, and I can say that for the 4 days I had to wear it, it was more uncomfortable than I ever imagined.
Anyway, the first session, "Vulnerabilities 2.0 in Web 2.0: Next Generation Web Apps from a Hacker's Perspective" by Alex Stamos was quite interesting. It turns out that many of the same sorts of security problems that existed in older web apps are still present in Ajax-style applications, but are much more difficult to analyze and track down due to the nature of discreet HTTP sub-calls within a single page in an Ajax app. Some of the fundamental aspects of Web 2.0 applications, like mash-ups, and JavaScript proxies that run on the client browser, allow for many more vectors of attack from malicious users.
The fundamental problem appears to be the lack of standard security profiles on the client-side. All client browser security is handled ad-hoc by the browser vendors. For example, cookies are shared across multiple domains during a session, which means malicious sites could use security credentials embedded within a particular cookie along with the local JavaScript proxy APIs to do things like transfer money from your bank account to another without your knowledge. Unlike phishing, this requires nothing more than simply visiting a site or opening a spam email from a webmail account. Ooops.
It'll be interesting to see how these problems are addressed, or if we will see a migration away from Ajax apps for more security-critical actions.
The second session was less interesting to me. I mostly attended "The Story Behind Facebook's APIs: From REST to FQL" to see what they had to say about REST (it turns out, not much). The story mostly seemed to be about how to design an easy-to-use API, and how they eventually decided to use a SQL-like query language to deal with the data available through their API. I suppose this is a good model for opening an API and the underlying data for a site like Facebook. I particularly liked the discussion of the confusing method names in Flickr's APIs, and the fact that they implemented their conversion to FQL (Facebook Query Langauge) in less than 2 months. But implementation details are sort of uninteresting to anybody not currently implementing anything.
A colophon historically was a page in a book that gave information about how the book was published. It usually listed the fonts used, where it was printed, who printed it, what kind of paper was used, and eventually what technology was used to produce the book.
Colophons are throwbacks now. Most publishers don't bother any longer, which I think is a shame. I'm on a minor quixotic mission to resurrect the practice.
Typography
The title and side headings use the Skia font, Matthew Carter's update of ancient Greek lettering. The monospaced font in the title is Consolas. The rest of the text is determined by the fonts available on the client using CSS. I've specified the following order: Lucida Grand, Lucida Sans, Verdana, Sans-serif (generic).
Design
The photos are of a pair of bizarre boxing frog pens that were given to me as a gift. Their arms are extremely muscular, and you cause them to jab with small levers on their backs. The heads swivel to the sides, and when you press down the nub of the pen, a cheap red LED lights up their torso. Their faces have the maniacal grin of the truly unsettled. I took the photos with a Canon digital camera, and touched them up using Apple's iPhoto and the GIMP. I used the GIMP to create the header, and the side heading graphics.
The color scheme was determined after manipulating the colors of the photos, and was in some small part influenced by a Paul Frank t-shirt.
I coded the HTML and CSS using Apple's Xcode and TextPad.
The name
The term verso means the left page of a book, as opposed to the recto, or right, page. The first page of a book, and therefore all odd numbered pages, are recto pages, while all even pages are verso pages.
