Internet Alchemy

Something that Kevin Burton recently wrote triggered an idea:

PPS. I used tinyurl.com for the URL to shirky’s article so it wouldn’t be included in pagerank, daypop, etc. I’m going to start doing this to articles I find suboptimal. Consider it a negative cert (or lack of approval).

That’s a great idea! What if we had a tinyurl service that let you write urls like this:

http://thisurl.is/great/123456

and

http://thisurl.is/crap/567466

Typed hyperlinks without any new syntax. Google and other citation based systems would quickly be able to latch onto these and adjust their rankings.

This looks hairy, but very powerful. Unit testing Oracle procedures and functions using some custom PL/SQL functions. Looking at the examples makes me want to cry:

/*file ut_truncit.pkb */
CREATE OR REPLACE PACKAGE BODY ut_truncit
IS
   PROCEDURE ut_setup
   IS
   BEGIN
      EXECUTE IMMEDIATE
         'CREATE TABLE temp_emp AS SELECT * FROM employee';
   END;

   PROCEDURE ut_teardown
   IS
   BEGIN
      EXECUTE IMMEDIATE
         'DROP TABLE temp_emp';
   END;
   -- For each program to test...
   PROCEDURE ut_TRUNCIT IS
   BEGIN
      TRUNCIT (
            TAB => 'temp_emp'
            ,
            SCH => USER
       );
      utAssert.eq (
         'Test of TRUNCIT',
         tabcount (USER, 'temp_emp'),
         0
         );
   END ut_TRUNCIT;
END ut_truncit;
/

Notice the setup/teardown/test metaphor is all there, hidden under ugly layers of PL/SQL.

An interesting example from a world where transactions cost next to nothing.

The “2 Phase Commit Puzzle” application is a little Windows Forms puzzle that doesn’t use Indigo or the Longhorn bits, but rather employs a little lightweight 2PC transaction manager that Steve Swartz and myself hacked up when we were on our Scalable Applications tour this spring.

The puzzle uses four resource managers (transaction participants). The TileWorker keeps track of the tiles as they are moved around, always votes “yes” on Prepare, does nothing on Commit and rolls all tiles back into their original (shuffled) state on Abort. The TimeoutWorker votes “yes” if the puzzle is completed (pressing the “Done” button) within the preset time-span and “no” otherwise. It does nothing on either Commit or Abort otherwise. The GridWorker votes “yes” on Prepare if the puzzle is completed (order is correct) and otherwise “no”. It also does nothing on Commit or Abort. The OutcomeContingentMessage is a participant that will always vote “yes” on Prepare and shows a “Congratulations” message on Commit and a “You failed!” message on Abort.

It’s worth reading the transaction deck presentation too (not linked since it’s a compressed PowerPoint file. You can find it on Google if you search for the exact phrase “figuring it out on safe ground”)

As software craftsmen, we have rules. Sometimes we feel bad when the rules must be broken. They’re just rules though. What’s important is that we have a moral center, a professional core, that refuses to compromise the quality of our work.

Robert C. Martin, on software quality and professional standards. One of the comments raises an interesting counter-argument: what if the client wants you to ship shit? In that case, there could be a mismatch between yours and their definitions of shit. If the msmatch is too great you’d better start looking for a new client.

Here’s an article introducing test driven development which is short enough that even the busiest developer can find the time to read.

The point of TDD is to drive out the functionality the software actually needs, rather than what the programmer thinks it probably ought to have. The way it does this seems at first counterintuitive, if not downright silly, but it not only makes sense, it also quickly becomes a natural and elegant way to develop software.

One of Ron Jeffries‘ many interesting ideas is that of exceptionless programming. In this thread from the XP yahoogroup, he and others go into more detail on this technique.

The principle is that since exceptions are essentially non-local gotos, it’s preferable to avoid using them as far as practially possible. If you can test for failure first, do that. If you can return a null object that satisifies the caller’s expectations, do so. If the caller passes in invalid parameters, write a test and correct the calling code or make your function handle the incorrect parameters. Use exceptions only when you cannot find out whether an operation will succeed without trying it. Using exceptions for flow control is especially evil.