low expectations surfing

Rules of thumb for re-learning to surf when thirtysomething:

• Beginner surfing is almost equivalent to playing in the water... so you might as well just play in the water and enjoy yourself.
  
  
• No one is paying any attention to you. Be as dorky as you want.
• Getting tired in the ocean is bad. Therefore, get out of the ocean before you're tired.
  
  
• Getting cold in the ocean is to be expected. Don't worry about it.
  
  
• Pretend that everyone else in the water is either a beginner or as old as you or both.
  
  
• Pretend that everyone else in the water is very nice and mellow.
  
  
• Pretend that everyone else in the water is trying to kill you, and stay well out of their way in the breakers.
• Never turn your back on the sea. (This feels like an old sailing safety tip, but I can't remember where I would have heard it. I've never done any ocean sailing.) The waves in the shallows can still bowl you over, and getting held under in one foot of water really hurts.
  
  
• If you're scared, go to someplace that scares you less. This is the fucking Pacific Ocean we're talking about here, and what will it prove to be a tough guy? The ocean can always kick your ass. get in the water whenever you might possibly have a chance. Even in November. With a beginner's mind, it will always be worthwhile.
  
  

If anyone surfs at Linda Mar and sees me playing in the breakers, please don't disillusion me. Except maybe about the "you're trying to kill me" part.

powered by performancing firefox

A java applet that actually works

Java applets on web pages haven't worked properly for me, pretty much ever. Educational applets work, but if there's any b2c relationship going on, it never works. Usually if a web page even tries to launch an applet, I kill my browser before java takes over my entire machine. When I have actually tried to complete a transaction using a java application, I lost money. (It doesn't take losing much money on a technology to decide not to use that technology again. About forty dollars, in my case.)
The only reason I tried another java applet was that the alternative was waiting on hold for "the next available representative will be with you shortly." So I watch incredulously as Comcast (my internet service provider) launches an applet for chat with a live representative. I waited a few minutes, watching the West Wing Season 7 on dvd, then an analyst appeared. I described my problem, and s/he asked a few more questions to verify my identity and to pin down the problem. Then (mirabile dictu!) she sent an updated signal to my cable box, and said that should fix it within the hour.
This sort of technology was totally workable nine years ago, 1997, when I worked on a java applet for playing (ahem) the Dating Game over the net. It was totally workable four years ago, when everybody in educational technology was writing and sharing applets. Four thousand ways to learn the pythagorean theorem! I'm down for that. What was missing before was enterprise integration. The tech support rep got my information via the applet, and moved that information quickly into the cable tv service monitoring system, wherein she took action and solved my problem. (I hope.) The purpose of this interaction was getting my service fixed, and the applet worked for me, because I find internet chat more convenient than phone hold. They used ten year old technology integrated with their core systems to create a better user experience for a paying customer. So we're back to the fundamental lesson of usability: it's about the people, not the technology.
In the time it took me to write this blog entry, my cable box has indeed received new information which corrected the problem I was having. And... the technician was in Colorado. (Another Turing test variant: is the tech support person located in the same country as you?) Comcast, I salute you for providing excellent customer service tonight.

stanley tucci can be sexy -- who knew?

The new CBS medical drama, 3 lbs, is my favorite new show of the season, beating Aaron Sorkin's latest effort and the other nbc show about nbc shows. When I heard about this obvious take-off on Fox's House, I thought, "Stanley Tucci? Why would I want to watch him for 47 minutes in a row? And why do I need another doctor drama?" It doesn't sound good, but there was a free download on iTunes, my dvr is on the fritz, and netflix is in a dull period. I turned it on an hour ago and couldn't move from in front of the screen, entirely forgetting the pasta on the stove and my home-rewiring projects.
Remember what happened in Pulp Fiction, when Bruce Willis makes his first appearance onscreen, and we all thought, "Christ, where'd he get thirty pounds of muscle at his age?" Same thing here with Stanley Tucci, but instead of a sweaty boxer pulling off his handwraps with his teeth after killing his opponent, we've got a gratuitous shot of Tucci as he changes into scrubs. The writers went a bit far to make sure we noticed Stanley's physique; they actually put a beautiful woman in the locker room with him, and gave her the line, "you look hot!" The writers can relax: we get it. Strange but true, Stanley Tucci is hot.
If you don't care about medical drama or well-defined biceps, this show is still worth watching for the use of music. The illness = dissonance / health = harmony metaphor is well-traveled, but 3 lbs connects the music back to the characters' narratives with a sincerity I haven't seen since yet this century. With DEVO and Talking Heads and Lisa Simpson and TMBG, music became defiantly ironic. Crooners weren't cool anymore. Which brings me to the 3 lbs coup de grâce: 'Fix You' by Coldplay. This song is so perfect accompanying the episode's climax that I hesitate to write about it here and risk spoiling the moment of recognition for my few readers who intersect the emo/indie music world with the new-fall-season crowd. 'Fix You' features an Edge-like guitar riff that reminds me of the best bits of All That You Can't Leave Behind, and a clarity of vocals that recalls, no shit, "Sweet Baby James." The song fulfills and unites themes of vulnerability and interdependence crafted with Poe-like attention to detail from the first notes of the opening scene. (Wasn't there a 9/11 movie which tried to use this song as the anthem for "the defining moment of our generation"? Sorry, no.)
My Grandma Bea would have liked this show. Perhaps the only thing about which I ever actually related to her as a human being was our shared adoration of George Clooney. Stanley Tucci would have been just right for her. But she probably wouldn't have understood the Coldplay reference.
Note to relatives: no, I am not going back to medical school.

Open Laszlo 3.x vs Open Laszlo Legals: About that tablecloth...

Jim Grandy wrote

the magician yanks the tablecloth out from under the place settings for an elegant meal, leaving the wine glasses and candlesticks in their places, unperturbed. A neat trick, but even better would be to replace the tablecloth with a new one, all without touching the candelabra or the crystal goblets. I’m not usually given to hyperbole, but with our latest Legals snapshot, PR3, we are nearing the end of a process that feels a lot like replacing the tablecloth.

Developers have started looking at the preview releases, and they're noticing that not only is the DHTML runtime incomplete, but the swf runtime has major regressions. "What's with all these regressions? Isn't that a bad indicator of code quality? Is the next version of Open Laszlo going to be worse than the current one?"
Well... I can see how this is worrisome. Let me offer this adjustment to Jim Grandy's analogy: Legals doesn't just replace the tablecloth; Legals sends the chef to culinary academy. The chef comes back from culinary academy, and changes the sautée pans, the waiters' uniforms, the produce supplier, and the actual furniture... but he leaves the menu the same. And, yes, he keeps the same silverware and china. That nasty ceviche appetizer is made with tuna instead of snapper, and the house salad uses butter lettuce and hothouse tomatoes instead of iceberg and cherry tomatoes.
What I'm trying to say here, while perhaps pushing the analogy too far, is that Legals changes the compiler and the Laszlo Foundation Classes. A lot. We refactored the Laszlo Foundation Classes into the runtime-independent parts and the runtime-dependent parts. In 3.x, the LFC code assumed that it was executing in a flash runtime. The 3.x LFC wasn't shy about reaching down to touch the flash movieclip directly. Legals inserts a portability layer between the LFC and runtime-dependent code; we call this portability layer the kernel. Everywhere that LFC code, components, and examples assume a flash runtime needs to be refactored to call the kernel API. So, you see, just about every line of the LFC has changed, even for the swf runtime. All that change was bound to cause regressions and introduce new bugs.
Here's the good news: we're software engineers with a track record of shipping solid software. We manifest our commitment to high-quality software by fixing bugs properly not just expeditiously. This stage right now is the right time for fundamental architectural changes and thorough discussion and investigation thereof. We have a large set of unit and integration tests, which we run, and ever-improving tools for tracking, assigning, reviewing, and fixing bugs. At any given time, several team members are devoted full-time to either increasing test coverage, improving test tools, or fixing known bugs.
When you sit down to eat at the new restaurant before opening night, the table might wobble, and there might be too much cayenne in the chili. But we're fixing the table by switching to a three-legged design, not just shoving a wad of napkin under one leg. We switched to venison and buffalo chili, so we're fine-tuning the spices with every batch we cook. We're working hard on getting it all back to solid and tasty, and we won't open the kitchen until taste-testers have approved every dish.

"there's more than one way to do it"

TMTOWTDI is pronounced tim-todd-ee and it means there's more than one way to do it. I think I picked this up from Programming Perl or Learning Perl. I didn't really learn to program or learn perl, from consulting those books, but I did learn TMTOWDI... which is kind of a problem.
I'm working on a relatively simple task: measure, store and analyze benchmarks for Open Laszlo runtime performance. The problem is that there's so many ways to do it! My thinking started with Java, because most of the OL server is written in Java. Indeed, I implemented the measure-and-store part of the problem with Java Server Pages (JSP). Now it's time for log analysis, and ye gods, Java has been through major honking changes in its support for logging, regular expressions, and XML. There is a surfeit of XML API's for java; in java 1.4 or so log4j-ish behavior became part of the java platform, in java.util.logging; Xerces, Xalan, SAX, JAXB, and JAXP all seem to do pretty much the same thing (parse XML) but Xerces and Xalan were merged into another project, and JAXB and JAXP seem to be just implementations of SAX. Maybe. And how does this all relate to java.util.xml? On the way-back machine that is the WWW, projects from 1999 and Java 1.1 can be nearly indistinguishable from a project from 2006 and Java 1.5. And how can I distinguish between an abandoned project and a project which is so stable that it hasn't needed an update in two years?
...Then the java code that does seem relevant seems to require a heckuva lot of boilerplate. All I want is a bit of regular expression support and math!
That sort of thinking leads directly to perl. Perl has superpowers and was designed for just this sort of task, but I'm not a perl programmer, and I don't want to be. Sorry. Does that make me a bad person? Lazy, maybe: I'd rather spend my time learning and working with a language that I like. I'm not talking fundamental goodness here; I'm talking personal preference. I don't like the idioms of global variables with names like "$_".
Personal preference leads me to Ruby and JavaScript. Ruby, oh you tasty jewel, would be a pleasure to write this log analysis and reporting in -- but ruby is one of the few languages that isn't required by the Open Laszlo tool set yet. A disciplined software engineer wouldn't add a new language requirement to the development environment on a whim. JavaScript would be darn nice, too, especially using E4X, ECMAScript for XML. Is E4X supported by the version of Rhino we use for unit tests in Open Laszlo, rhino 1.5R3? I just spent ten minutes browsing mozilla.org trying to figure this out, and I still don't know. (This feels like what I'll end up doing, though.)
My high school fencing teacher used to say, "don't parade your ignorance" and maybe as a career web programmer I'm hurting my future prospects by confessing confusion with all these API's. So I'll skip rhapsodies on python and bash and XSLT, and just get to the point: TMTOWDI, so let's just get it done! All of these languages and libraries can get the job done, with a complex set of trade-offs between brevity, readability, maintainability, portability, external dependencies, and personal preference. It doesn't matter. Just pick one and get on with it. Stop trying to figure out which one is best; stop trying to grok new technologies while standing in an aisle at Barnes & Noble. What would get me from here to performance benchmark analysis by tomorrow? Straight-up java parsing. Forget XML, just use line-based text parsing with a string tokenizer. Forget object serialization. Forget XSLT. Forget trend graphs of benchmarks over time. Just use plain old text files, and get the job done.
(If I get to producing a simple report with single-number reports on the performance of three different builds, today, then I can play with Ruby while watching Desperate Housewives.)

UPDATE (eight hours later): I wrote the tool that I need in a few hours, using java's StringTokenizer and JUnit. I also went for a walk along the beach and took a nap. Shiny things: IntelliJ IDEA 6 integrated JUnit support. I'm in love with the green bar.