Older blog entries for chromatic (starting at number 171)

GROSSS: Get Rid Of Slimy girlS in Software:

I should have stopped reading comments on Slashdot years ago. Expecting insight into software or programming there is like expecting my eight year old cousin to drive an ambulance. Even if he did successfully back it out of the driveway, he'll do more damage than anyone could predict.

While I'm still occasionally surprised at the lack of depth of discussion (for the most part), I've rarely been shocked into responding to the awfulness I saw. That is, until last week.

In a story about the release of Perl 6 Essentials, I know to expect really lame discussions. "Blah blah unreadable", "blah blah not done yet", "blah blah mod me down suckers." I didn't really expect to see this comment. (If you're sensitive, you might not want to read the thread. I was offended.)

It boggles my mind that, in a profession and a community that realizes and laments a lack of women, the burning question when a woman enters the community and does something significant is "Got a full-body shot of her?"

I respect LinuxChix (and occasionally work with a couple of the members) and I've heard hfb talk about the subject of sexism and hostility many, many times. I'm really starting to believe that being silent doesn't help. Maybe the right solution is to say, without sarcasm, malice, or anger, "That was rude and I don't agree."

Maybe I'm oversensitive, but I just want to shake people and say "Be nice!"

Coding Despite Travel:

I've a lot of small projects to finish. That tends not to stop me from taking on more work. Fortunately, I've continued to be productive lately.

Wednesday night, at a post-YAPC party, Leon gave me permission to upload yet another Acme module. I already have Acme::Pr0n. It is with great pleasure that I announce Acme, Inc., a module that replaces your boring old modules with shiny new modules from Acme, Inc. You might remember this as the company that produces all of the nifty toys in the old Road Runner cartoons.

Thursday, on the plane, I wrote several bits of documentation for Jellybean in anticipation of an impending release. Before that happens, however, there must be a new release of CGI::Simple (not my job; I've already sent the author a code and test patch) and Text::WikiFormat. The latter is my responsibility, though I am waiting for feedback from (my approximately only user) Kake to see how well it passes her tests. It also needs a documenation update.

Yesterday was a day of severe jet-lag, though I did whittle down my work inbox quite nicely. It was at 0 messages before I left and is somewhere around 25 now. That's workable. Processing any more would have required much more brainpower than I had. As you'd expect, it was a day without coding.

Today has been pretty laid-back, though I did get the basics of Mail::TempAddress in place. It has 5 customer tests and 80-plus programmer tests. All of them pass. It only creates new temporary addresses at the moment, but that requires just enough framework that adding the other few features is very simple. There's one remaining Mail::* hack in mind and I hope to get to it soon.

Another nice thing I did was to automate the process of creating a new test file. I now have a little program that writes out all of the boilerplate I usually use. It saves a minute or so of typing. Since it took about two minutes to write, it'll pay off within the week.

If you need a moral to the story, how about "resolve to automate things you really should automate"?

On Improving a Protocol:

Everybody knows it, but nobody wants to admit that HTTP is a completely broken protocol. Anybody in the world can initiate a connection with your web server and request absolutely any file or path that you may or may not have available. If you've run a web site for any amount of time, surely you've seen worm tracks and fake referrers in your logs.

You really can't fix HTTP — it's beyond repair. I'm sick of being told "just ignore malformed requests and broken links". The real solution is to throw out HTTP completely and rewrite it from scratch to keep in mind authentication, authorization, and security.

That might take a while though, so here are some other ideas that will tide us over.

• Require a token micropayment from everyone who requests a page. After you review the request and decide it's legitimate, you can refund the payment.
• Require an authorization step, where any incoming connection immediately receives a challenge. This could be performing a small-but-significant mathematical operation or it could be a manual response step. Anyone who performs this step successfully will be added to a whitelist and never challenged again. Of course, you can add people to the whitelist if you have regular traffic from friends or family.
• Maintain a list of filters that deny requests that conform to certain parameters. Some people prefer to reject requests that are obvious forgeries — requests that match Code Red, for example. Other people are more aggressive, subscribing to services that publish the IP addresses of known bad Internet citizens.

I think it's time we got serious about the Internet.

Mail::SimpleList Slides Online:

Last Wednesday (11 June), I presented a talk on Mail::SimpleList to the Portland Perl Mongers. I've written my own presentation software, of course, so it took about ten lines of Perl and LWP::Simple to query Jellybean Wiki for the HTML and to save it in the proper fashion.

MailSimpleListTalk is online for your reading pleasure. Now to write some POD.

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.