Older blog entries for chromatic (starting at number 167)

Feelin' Productive:

Today was really productive. Here's what I did:

• Moved one load of laundry to the dryer and folded it
• Changed my bedding and towels
• Washed and dried another load of laundry
• Wrote a bit of JavaScript to navigate between HTML slides using the space bar, the backspace key, and the backtick key</a>
• Went to the MOSS meeting, though it meant dodging Rose Festival traffic. (Several people were impressed by my SimpleList and TempMail projects — more on those later.)
• Cooked a spaghetti dinner for four other people besides myself
• Wrote the CGI protocol translator for Jellybean, meaning that Jellybean::Wiki is now ported and working
• Fixed a path-handling bug in Jellybean
• Fixed a bug in CGI::Simple, sending a patch plus updated tests to the author
• Wrote a program to convet last year's Test::Tutorial slides from AxPoint to Text::WikiFormat format
• Updated my resume online to be explicit that I'm gainfully and very happily employed while linking to Onyx Neon Consulting, where I occasionally consult

I didn't write any of my talk for next Wednesday, nor did I proofread any of my book, which is also due on Wednesday. I'm still counting the day as a fantastic success, because it'd have been really tough to cram any more in there.

Yeah, This Here's the Problem:

If 80% of software developers are brilliant enough to write better code faster, cheaper, and more efficiently than they can reuse existing code, why does software still suck so much?

Me, I'm wearing my dubious pants.

What Are Two Years of Study Worth?

It's been almost two years since I last did any work on Jellybean. It's not that it wasn't a good idea. It's not that it got too difficult. It's not that I couldn't have made time.

Part of it is that I'm easily distracted. I also didn't really know what to do with it. My theory is, at some point, writing frameworks becomes deathly boring to a good programmer. You need to stay grounded in the practical. (That may just be the way I learn, though; Perl 6 grammar stays in my head only with extreme effort. If I can't play with it, it doesn't stick.)

The house was empty except for me and the cat today and I have a very clever plan for my next talk that requires a tiny, controllable web server, so I hopped back in the candy factory and banged out some newer code. (If you're really curious, download it from the site above. It only serves files — a bit naively — but all of the pieces fit together.)

I've discovered two big mistakes. First, though I had a test suite, it wasn't very maintainable. If you're not using Test::Harness to its full advantage, you're really missing out. (It's okay to use Test and not Test::More and friends, as long as you use a good harness.)

Second, I was trying to make my code too flexible. Since I didn't really have a single grand purpose in mind, I was trying to code all things for all people. That's a good way to tie yourself in knots. That's partly why it took so long to get back to it.

I'm a big believer in releasing working code, but I'm starting to believe very much in releasing simple code without apology. I know there are flaws. I know there are limitations. I'd love to be deluged with patches to smooth down all the rough spots and to sand all of the sharp corners. That probably won't happen, so I'll get to them eventually.

I do hope my code is useful to other people, but I'm not going to lose sleep trying to make that happens. If it needs a little attention to work for you and you want my help with that, that's great. I'm happy to do it. If you don't need me, it'd be nice to hear that too. If it doesn't meet your needs, I hope you find something that does, even if you have to write it yourself. I hope you're inspired by my ideas or my code, though.

It takes a lot of work to write good software, but it's a lot easier when you stop trying to meet an impossible goal or two and accept that you can do good things in smaller steps.

link fixed the next morning

Brown Paper Bag (Or How I Became My Own Customer):

My mailserver went offline late last Friday night. Of course, it was the start of a holiday weekend in the US. As you'd expect, the T1 between the two main work offices also went down that weekend, so Tuesday was low on e-mail as store-and-forward systems struggled to catch up.

I usually do a final bit of real-world monkey-testing on my software before I release it. I didn't do that with Mail::SimpleList 0.50, though, since the tests all passed anyway and I couldn't get to my server.

After trying again and discovering buggy example code and a body-eating bug, I'm much more pleased to present Mail::SimpleList 0.60, with bug fixes and new features. It's just about everything I'd envisioned when I started the process and I'm very pleased with it.

I'm also tremendously happy with the Customer tests. These are different from the Programmer tests. (You may remember them from their old Extreme Programming names: Acceptance and Unit tests.) They're high level. I use the same testing framework, but I have to exercise different muscles and I get to see how everything works together.

Because I'm my own customer and I'm working alone on this, I've been writing the customer tests first, then moving to programmer tests. It's a slightly different approach for test-driven development. It's stack based. I find that I have to revise the customer tests after the programmer tests all pass. Part of this is because I've only now started to feel the need to refactor the customer tests into more expressive testing verbs. Part of it is because I have to think in slightly different ways. It's great!

I've agreed to speak about this project and my development process at the next Portland Perl Mongers meeting, on 11 June. We'll see how it goes. I know understand why Rael is having so much fun with Blosxom.

Easy Mailing Lists:

Mail::SimpleList (perhaps not the final name) is ready for early adopters. You may remember it from an earlier diary entry.

It has programmer tests (of course), customer tests (a new feature I'm trying), and a README file that describes everything you need: your own mail server, a user account, a couple of other Perl modules, a .forward file, and resolveable extended e-mail addresses.

We've been using it successfully for a while here, but in packaging it up, I may have messed things up. The tests all pass, but I've been writing them long enough to know that's never the whole story. There are also plenty of features to add, but it's been interesting to write, so why not share with the rest of the world?

Uneasy Free Time:

I finished the book last night; it was due today. Ward Cunningham has very graciously agreed to write the foreword. For a little 80-page guide with no code snippets, it's sucked up quite a bit of time over the past several months.

In my copious work time, prompted by reactions to an author's first impressions of Python web programming, I've produced a short essay called What I Hate About Your Language. Only the title is intentionally provocative, I promise. I harbor no illusion about being the first kid on the block to realize some things, but there's room to discuss real issues about language features and philosophies. Hopefully it'll spark some interesting discussions.

Aside from the inevitable book-related stuff (remember, after you turn in your manuscript, it still has to be produced, copy-edited, proofread, indexed, proofread again, page broken, and printed), that leaves me with copious free time. I remember lots of little projects that need some attention. I'm tired tonight, though, so we'll have to see what happens tomorrow.

Representation:

amars, the people criticizing the Dixie Chicks are exercising the same rights as the Dixie Chicks themselves. Freedom of speech doesn't mean you're immune from having people disagree with you. It's always struck me as ironically amusing when people who say strong things complain about other people's reactions.

What I find more interesting is the debate over what an elected representative should do. There seem to be two main schools of thought. One says, he should follow the will of the people he represents because he represents everyone. The other says, he should follow his will because he was elected for his beliefs.

I'm not completely comfortable with either interpretation. (When I'm completely uncharitable, I'll say that President Clinton exemplified the former and President Bush the second exemplifies the latter.) That may be because I have severe doubts that any one person can be completely right all the time.

I can understand, somewhat, the idea that it's disenfranchising to be "represented" by someone with whom you disagree strongly. I don't really understand the notion that you absolutely must have someone who looks a lot like you to be represented sufficiently -- superficiality is the bane of representative democracy.

There was a point here, but it seems to have eluded me. Maybe it's still "the USA has never really resolved the debate over individual versus community interests."

Relief is...

It's a relief to write the last word of the last sentence of the last paragraph of the last chapter of a book.

It's quite a relief to write the last word of the last sentence of the last paragraph of the last revision of a book after a grueling tech review.

It'll be quite a relief to deliver a final manuscript after editing the whole thing once more.

It'll be quite a relief to sign off on the last typo of the last proof check.

It'll be even nicer to see the book in print.

That's eleven days to the next major sigh of relief. At least this time, I know there are more.

lvalue typeglobs:

I've always wondered if this would work, but never tried it until now. It worked on the first try. Does that say more about me or Perl?

#!/usr/bin/perl -w

 use strict;

 sub installsub: lvalue
{
    my $glob = shift;
    no strict 'refs';
    *{ $glob };
}

 installsub( 'foo' ) = sub { print "Foo!\n" };
foo();

Of course, that's not bad enough:

for my $sub (qw( bar baz ))
{
    installsub( $sub ) = sub { print "$sub\n" };
    __PACKAGE__->can( $sub )->();
}

Worse yet, I have an actual factual practical use in mind.

apm:

I think the Waterbed Theory might apply. For example, I could explain Lisp syntax to my mother in fifteen minutes or so. It's very simple, just (f a b). However, the complexity that makes Lisp useful has to come out somewhere else. To be productive, she'd have to understand tree structures, code as data, car, cdr, list processing, and so on.

A language with simple syntax has to have a hefty standard library or it's not practically useful. The nice thing about syntax is that it's documented. In the case of Perl 5, we're talking about thousands of pages of standard documentation, indexed and searchable, organized by topic. Perl 6 will likely have similarly complete documentation.

Unless you're dealing with a program so very simple (or badly written) that it has no functions or modules or architecture, you're still at the mercy of the documentation or, failing that, the code itself. I'm not convinced you can really understand someone's code without reading it anyway.

If someone modifies the grammar in a Perl 6 module, you'll know. You'll have to read the grammar docs just as you would for any other library.