The Accidental Author

It looks like it's finally official and I can publicly announce it. I'm listed as one of the authors of Perl Hacks, with chromatic and Dr. Damian Conway. Oddly enough, I hadn't expected this. When a call for contributions went out, I just contributed a bunch. O'Reilly contacted me out of the blue and asked if I wanted my name on the cover. Interesting way to become an author, eh?

(To forestall the obvious question: yes, there are royalties, too)
  • Current Mood: happy happy
  • Current Music: Squirrel Nut Zippers | The Kraken
Will you sign my copy?

(did you want this public? the site it links to lists your full name and city of residence)
Re: congrats!
I'm not worried about it being public. I'm well known enough for my Perl work that anyone who's even remotely curious can track me down.
Congratulations! That's an *awesome* way to become a published author! :-)
Hey, you and I still need to get together. And I need to find my camera cable so I can get some party photos to you.
Well fuh sure! You got enough articles in that to warrant being on the cover.
Hopefully those are articles that folks will find useful, too. I'm not sure that "naming anonymous subroutines" is the first thing people are going to flip to :)
No, I actually like that one. One of them, L I'm not fond of. It's a nice article but doesn't seem like a hack and it uses Class::MethodMaker about which perlmonks has given me the impression should be avoided.

I liked learning about Class::BuildMethods. The one thing I worry about is what happens to global inside-out objects during global destruction. Their innards are usually stored in file-scoped my()s or real globals. In either case, when global destruction happens all globals are cleaned up in arena-order and not the usual reference-counted order.

So now the inside-out object's DESTROY method has to avoid caring whether its private data has been reaped prior to the object that being reaped.

I seem to recall seeing this in practice while implementing Data::Postponed. That's inside-out of necessity. I covered my code in assertions and got tripped up when I asserted that my object's innards should exist before I deleted it.
That can certainly be a problem. I was bit with that with some ISAPI code I had written years ago. A security object had a DBI handle and the DBI handle was going out of scope before the security object. Naturally, the security object had a DESTROY method which required the DBI object. I was not happy. For some reason, the code worked on the production box, but it failed on a test box. Fortunately, the success/failure was deterministic for a given box so we were able to keep things working until I rewrote the code.

A more pressing problem is that I need to update Class::BuildMethods to allow for serialization and to make it thread-safe. Those were two things I didn't think about (because I didn't need them when I wrote this), so I forgot 'em.
If you noticed, xdg wrote something on perlmonks about making such things thread-safe.
Hugs bro! You deserve it! I hope you go far in life! But not so far I can't say hi once in a while :)
Re: Spiffy!
Why do we need to be bookstore employees? Everyone should take part in my blood pact to rearrange the shelf so the cover is facing out instead of the spine, when we find the book at a local bookstore. ~Kino Kid
That's awesome!

Do you know if it's going to make it into Safari as a rough cuts title? The new rough cuts thing seems neat and I'd love to get a sneak peek before proper release. :)