blog.shrub

My session is Putting the Quality in Quality Web Applications.

Here’s the blurb:

A misspelled word, stray pixel or errant semicolon can erase your data, confuse your customers or put you on the front page of the New York Times. Learn what’s important when it comes to web app quality and how to make your site test itself while you sip margaritas.

This is going to be a presentation, not a panel. I’ll cover diverse aspects of web application testing — from CSS bugs to typos to buffer overflows. What are the most common problems? How can you fix them? How can you avoid them? How can your computer do the work for you—how can you automate as much of this as possible? Lots of demos, code samples, real-world best practices.

Sen. Barbara Boxer is having email problems:

Tony is a UI engineer. He gets a lot of recruiter spam. Usually it’s related to his skillset.

This time, however, the recruiter was looking for a filesystems engineer.

They had this hilarious exchange:

Recruiter: We’re looking for somebody with 7-10 years of experience writing filesystems.
Me: The only person I know with that level of experience writing filesystems is Hans Reiser.
Recruiter: Have you worked with Hans before? Can you send me his resume?
Me: http://www.idiom.com/~beverly/hans_resume.html
Recruiter: You are too funny! We’re willing to let our developers telecommute but the state penn. wasn’t quite what we had in mind. Thanks for making me smile though :)

If it costs you more in employee time to screen bug reports and mark them as duplicates than it would to actually fix the bug, fix the bug. Now.

In 1999, the high-end Mac was a 500 MHz Power Mac G4 and cost $3500.
In 2006, the high-end Mac is a 2×3 GHz Mac Pro and costs $2500.

That’s more than 12X faster for 30% less.

In 1999, I was paying CAD$36/month (then worth US$25 @1.47:1) for broadband (Bell Canada).
In 2007, I am paying US$43/month for broadband (Comcast).

That’s maybe 2X faster for 75% more.

Why does US broadband suck?

Robert Cringely dives in.

But I find it hard to remember any company or industry segment ever going zero for 51. This is a failure rate so amazing that any statistician would question the motives of those even entering such an endeavor. Did they actually expect to succeed? Or did they actually expect to fail? We may never know and it probably doesn’t even matter, but one thing is sure: they expected to be paid and they were.
…
There are no good guys in this story. Misguided and incompetent regulation combined with utilities that found ways to game the system resulted in what had been the best communication system in the world becoming just so-so, though very profitable. We as consumers were consistently sold ideas that were impractical only to have those be replaced later by less-ambitious technologies that, in turn, were still under-delivered. Congress set mandates then provided little or no oversight. The FCC was (and probably still is) managed for the benefit of the companies and their lobbyists, not for you and me. And the upshot is that I could move to Japan and pay $14 per month for 100-megabit-per-second Internet service but I can’t do that here and will probably never be able to.

At this year’s Apple Worldwide Developers Conference, I’m giving version 2.0 of my Bug Reporting Best Practices talk.

The official blurb:

Bug reports that are complete and reproducible help to isolate known issues in system and application software, making a solution much more likely. Learn the bug reporting best practices that Apple has developed in partnership with our third-party developer community. Observe the key components of a great bug report, and how they could expedite your bugs through our processes. You’ll also learn to apply these practices to your own bug processes.

The sound bite version is “I’m teaching developers how to write bugs.”

It’s Wednesday, June 13 at 9 am in The Marina.

Here are some comments from people who’ve attended my previous talks:

• “Paul’s presentation style kicks ass.”
• “Great lively presentation and very interesting content!”
• “Flows well, Paul is a great presenter!”
• “Great information.”

I wrote one of these for Mailman last fall, and finally got around to putting together a quick script to back up your MySQL databases. It optimizes and repairs all of your tables, then creates a directory for today, dumps each database into a SQL file and zips it up, leaving you with a directory of .tgz files.

The script requires the Python MySQL module. If you’re using DarwinPorts, port install py-mysql; on Debian, apt-get install python-mysqldb. With fink, install mysql-python-py24 (or mysql-python-py23, or mysql-python-py25, etc.).

The script is called mysqlBackup.py, and its syntax is pretty straightforward:
Usage: mysqlBackup.py <backuppath> <password> [<user>] [<hostname>]

If the username isn’t specified, it defaults to root. Likewise, the host defaults to localhost.

Typical use would be to place a helper script like this /etc/cron.weekly:

#!/bin/sh
/usr/local/bin/mysqlBackup.py /home/backups/mysql/ mypassword


mysqlBackup.py is available under a CreativeCommons-Attribution license.

At this year’s SXSW Interactive festival, I’ll be moderating the panel Getting to Consistency: Don’t Make Your Users Think. The blurb:

Predictable and consistent software is much easier to use. This session explores interface consistency, examples of consistency failures and their consequences.

This is going to be a really interesting discussion. I have three fantastic panelists:

• Steve Johnson, Senior Manager, User Experience, Adobe
• Jennifer Fraser, Lead User Experience Designer, Corel
• Alex Graveley, User Interface Engineer, VMware

We’re going to explain what consistency really means to you and your users and show what it can do for you. What happens when you’re not consistent? We’ll demonstrate examples of failures from the silly to the catastrophic and list the obvious (and hidden) costs of inconsistency.

Sometimes, however, you don’t want to be consistent. We’ll explain why.

Come to this session and be the new best friend of your performance, security, accessibility, tech support and product documentation teams. (Then, go to the session on managing social networks and information overload.)

“The best code you have is the code you didn’t write.”

“Legacy code is any code without tests.” (likely paraphrasing Michael Feathers)