...like a diaper bag!
The start of a project is always a great time to get books. Since I'm learning new stuff, new books are called for. Here's the ones I've picked up so far; I'll try and write more about them individually later:
I'm not sure what server our new platform will run on or if we'll need to create our own for certain parts of the application. And Java 5 has lots of useful additions for concurrency that I haven't caught up on yet. This book should rectify that. The fact that some heavy names (Doug Lea and Josh Bloch, among others) are co-authors doesn't hurt either.
I've only flipped through this so far, no comment yet.
aka, "the messaging pattern book"; I don't know why they didn't put "messaging" in the title (although it is in the subtitle); maybe someone's derived a sales stat:
$sales += $sales * 0.30 if ( $title =~
I've read through a chapter or so of this. Looks great so far -- that they don't use UML for the diagrams is a plus. It also doesn't contain pages on pages of code. Skimming the WSDL/SOAP examples in the implementation section I read (loan broker), makes me glad I'm not planning to go there.
For technologies like this (uncomplicated but lots of uses and gotchas) I find myself leaning toward the recipe-style books rather than the comprehensive manuals. Partly because I have a short attention span and do not have public transportation time to read, but also because ideas stick better for me if I implement them or even review an implementation.
The only downside of this is that it doesn't seem to cover dojo, which I'm considering as a core component.
I also looked at the Ajax book with Dion as one of the co-authors. I like Dion even though I've never met him; unlike many Java people he doesn't think 'Perl' is a dirty word and he's very pragmatic about technology and applications. But it was more of a manual; I already know half the stuff in there. And the dojo coverage looked like an intro only.
To me it sounds weird to get a book on web design. Probably all the tips and tricks here are readily available on the web. But web documents (even tutorials) tend to be really short because, of course, nobody reads long documents on the web. And while you can find a good tip for layout, another for menus, another for pull quotes, etc., they're all presented differently.
This book also looks excellent for showing you the ramifications if you don't do something or if you do it in a suboptimal way. (He has to show you the non-bulletproof way to show the benefits of the bulletproof way.)
It also has excellent graphics and the author seems to have taken his time thinking hard about how to present a particular implementation method.
I also flipped through Non-Designer's Design Book for more general ideas on design. It looks very useful, breaking down designs into what works and what doesn't. But I shouldn't be doing too much of that.
 Actually, it's never a bad time to get books, but at the start of a project it's very easy to justify expensing them.
(aka, "at least he said I'm competent!")
Back in April Mark-Jason Dominus visited Pittsburgh in support of his upcoming book Perl Program Repair Shop and Red Flags. Actually, "in support" doesn't quite capture his intent. Instead of a typical process where the author dictates from his experience about X technology or Y methodology, MJD is creating a book showing standard programming and design mistakes people make and how you can fix them. It's similar to refactoring but the focus is on real-world problems rather than the standard examples (bonus calculations, calculators, scoring games, etc.).
The announcement to the group asked people to send in their code for MJD to fix up. Of course nobody did, I think partly because a lot of code people work on is internal and they're not sure whether it can/should be shared with the world. And partly because nobody likes to see their code torn up in front of a group of people, much less in a book where it'll be preserved forever.
In the absence of volunteered code MJD scoured the CPAN directories of pgh.pm members, finding Class::Observable which fit the bill very nicely:
We didn't know what he was going to review beforehand, and I came in as they were passing out paper copies of the code, just before he started. I sat down and looked at the paper: 'Observable.pm'. "Aww, shit," I muttered, just loud enough for the person next to me to hear. At least I didn't have time to worry about it beforehand.
Now he's written up a good summary of what he said at the meeting. It sounds more painful than it was, honest. Partly because I haven't touched Class::Observable in a while, partly because he was straightforward and professional (non-personal) about it, and partly because I think I took it in the spirit it was intended.
A couple of the questions he had were easily answered. But the main problem he has with the class is that it doesn't use the object to store data about the object. This is so common-sense that it shouldn't even bear repeating, right? It's a little murkier than that, as he alludes to in the writeup. (The fact that he made the same mistake in something he wrote was comforting.)
The real reason I didn't use the object was that I did not want to touch the object. At all. Why not? My original thought was that I didn't want to assume anything about the object's implementation. This is something you need to worry about in Perl that you don't with languages that are built around OO. Since an object is just a reference with metadata about where it belongs, and a reference can be a scalar, array or hash, you can't assume a way to store object data.
But you can assume methods, which is the whole point of the object anyway. And as Mark showed in his implementation, all you need to do is define a default behavior for the common case (object-as-hashref) and let people implement their own uncommon cases by providing method hooks for them to do so. It's a much clearer implementation and makes a lot more sense.
So my reluctance to touch the object was really a type of cargo cult behavior: You can't depend on object implementations so don't put anything in the object. Instead of thinking about the general problem and the best implementation I didn't even consider a set of solutions because "you don't do that" -- a false trade-off. It's humbling when you realize this sort of behavior in yourself; I don't think I'd make the same mistake today, but maybe I already have and just don't realize it yet.
 I heard
he did this same talk at YAPC 2006 a few days ago. Hopefully he didn't
use my absence to be harsher than he was in Pittsburgh
 I seem to remember a great writeup of this from MJD's blog, maybe somewhere else, but I can't find it now. If you have a link please send it on.
Long story short: our feeder flight from Orlando was delayed due to weather (+2.5h), "air traffic control (+1h), and draining fuel because we were overweight (.5h). Making us late for our connection to Montreal by an hour
And every hotel is completely booked because a jillion other people had the same problems today and they had the good sense to get in before 10 PM. So we're sitting in the middle of a bunch of Russians (who seem very nice). At least there's wireless, although you'd think they'd have the sense to turn off the music and the occasional "FOR SECURITY REASONS" messages.
It should be an interesting demo and presentation tomorrow
I'm bummed I wasn't able to get to Chicago this year. (I'm going on a work trip in a few hours.) The talks may or may not have been interesting, but I really miss catching up with all the folks from years past. With beer.
I hope things are running smoothly and that That Guy isn't screwing up anybody's talks!
While reading lots of web services grumblings in recent days I ran across Bruce Eckel's Are Web Services Real? where he talks about his frustrations trying to use a basic FedEx service. In response one of the commenters said:
There's a module on CPAN that handles the actual calls to the FedEx shipping service. This is the url: http://search.cpan.org/~jpowers/...
...and I was not the least bit surprised.
...three minutes, still high, a comfortable $140 cushion between my max and the current amount.
...two minutes, still high, imagining flying up the Allegheny College hill on the end of the MS150 first day.
...one minute, still high, wondering how fast I could get the included computer.
...thirty seconds, still high, thinking of the other stuff we need the money for.
...fifteen seconds -- dammit, outbid five seconds earlier!
I flashed through bumping it up, but that's a dangerous path. My max was my max, and I stuck with it. But: no bike. Ahh well.
So I'm not using Perl at work and will not be for the foreseeable future. And my work is basically taking up all my spare brain cycles. And home life is getting more complicated in the near future.
As an entirely predictable result my perl modules haven't been updated in a while. For some it's not a big deal, for others it is. In particular, I get an email about the Workflow module about every week or two. And I shamefully just let them sit there. (Yes, I can be an asshole.)
So I need to get out of the way. Let me know if you're interested in maintaining:
Once you take it over, it's yours. I won't butt in and tell you how to do anything, cross my heart. (Ask Stevan about DBD::Mock.)
Searching for one of my favorite phrases from "Office Space" returns more than I expected, even with quotes:
A fun exercise would be to find all the people (etc.) named in the results and list them somewhere