Keeping It Simple

Month: December 2007

  • Idea for “pure” mysqlnd interface

    When I first heard about the mysqlnd project at the MySQL Camp in 2006, somehow I thought it was going to be 100% PHP code. I can’t remember now if I was making an incorrect assumption or if they planned to write it in PHP but changed their mind.

    What we have today is a DLL that is a drop-in replacement for libmysql. This has a few nice advantages. It means the replacement library will be API-compatible with all three PHP extensions for MySQL, (mysql, mysqli, and pdo_mysql) so it requires no one to change their PHP application code. The libmysqlnd is licensed under the PHP license, so it can be distributed with PHP core without any license conflict. All in all a good solution that will help both PHP and MySQL.

    But what about my (mistaken) impression of a MySQL client written in PHP, instead of implemented as a DLL? Essentially this would implement in PHP code the MySQL client/server protocol.

    It’s certainly possible that implementing this protocol in a language like PHP would be hopelessly inefficient and not suitable for any real world development. But it would have a few nice advantages:

    • Providing a platform-independent MySQL client.
    • Deploying easily in hosting environments with no access to configure php.ini.
    • Allowing PHP debugging tools to inspect at the protocol level.
    • Serving as a model for similar drivers for Perl, Ruby, Python, etc.
    • Licensing with the same license as the respective language, e.g. PHP License, Artistic License, or GPL.

    Writing a driver in the host language has precedent. A JDBC type 4 driver is supposed to implement the vendor’s client/server protocol in 100% Java code, so as to appear to the RDBMS server as indistinguishable from the vendor’s own client library.

    So for now, this is just an idle idea. Please don’t anyone ask me where to download this imaginary software, it doesn’t exist as far as I know!

  • How to Save $100 Million

    Last night I listened to an interesting interview on public radio, relating a story from the New Yorker magazine about Michigan Dr. Peter Pronovost saving millions of dollars and hundreds of lives of patients.

    How did he do it? He taught doctors and nurses to use checklists to avoid mistakes in the intensive care units of hospitals. Mistakes that could put patients’ health or lives at risk.

    What’s interesting about this story is that it’s an extremely low-technology solution to a type of problem that exists in virtually every field. In this case, it applies to medical care. But it easily applies to manufacturing. In Japan, they call it poka-yoke, or mistake-proofing. Check out this book too: “Mistake Proofing: Designing Errors Out” by Richard B. Chase and Douglas M. Stewart.

    Do checklists and similar techniques mean hamstringing the creative process in these fields? Absolutely not! On the contrary, effective use of checklists can free our attention from repetitive details, so that we can devote more of our energy to innovation and creativity. We don’t need to keep the details of well-understood procedures in our short-term memory, if we write down the steps so that we can do them without burden, or delegate the work to a teammate.

    Why not go the extra step and create technology to automate those procedures? Because a checklist doesn’t necessarily remove the requirement for human attention, to exercise good judgment and critical thinking. Some steps may require analysis, or may be performed conditionally based on the result of a previous step. It’s usually very expensive to make a machine that does that kind of analysis.

    Procedures are inexpensive to modify and prototype when humans perform them. It might turn out that the whole procedure is revealed to be incorrect, and needs to be re-thought. If automation technology had been developed for that procedure, the cost of developing that technology would be wasted. If the procedure were merely a checklist, then we just need to re-train the operation staff and voilà!

    Notice that books like David Allen’s “Getting Things Done” focus on non-technological methods for organizing and avoiding letting things fall through the cracks.

    If checklists and other easy organizational techniques are such a good idea, why don’t we employ them more? In the article about Dr. Peter Pronovost, he remarked that it’s surprising that it has taken so long to adopt his methods, and if there were a drug that achieved the same positive results he does, it would be mandatory in every hospital. A clue to the explanation is in if there were a drug. Follow the money! The solution that is marketed most aggressively is not the one that is most cost-effective; it’s often the one that is least cost-effective, because its vendor stands to make the most money from that one.