Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I second your objection re the many typos. The errata list is growing on the site []; I have tripped over at least half a dozen sentences with extra or missing words that garble the meaning.

    But much worse: some of the code apparently was not run before the book went to print, and several mistakes leave the reader dead in his tracks.

    Page 28 has command line code for creating a database model that simply doesn't work in Windows, but breaks in a very weird way that the debugger doesn't identify directly. (That one was about an hour to figure out. I'm just now learning to use Perl on Windows after using it on Linux for a long time ... don't include the backslashes in the Windows command line. But even for Linux users, the example has the backslashes appearing in mid-sentence rather than at the end of each line; I guess that would crash even a shell in Linux.)

    Page 44 introduces FormBuilder and tries to show how to get a web page that includes a form... but the example doesn't work. No joy; basically produces a blank page.

    That makes the rest of p. 44 and all of p. 45 fairly useless, if one can't get the form to show up at all.

    Then, after paging through documentation for Catalyst::Controller::FormBuilder, I determine that form.render in the code example should have been FormBuilder.render. That one's not yet in the errata, but I just reported it.

    And fortunately I had read the book's online errata before looking at pp. 44 and 45; once the form is finally up and running, several code examples use $c->form->whatever but should use $self->formbuilder->whatever ... again, fatal errors.

    I thought chapter 2 was a weak beginning; it's an attempt to do a Hello World application, but it contains way too many details that were ambiguous and distracting. Why was the controller named and then a subroutine added to it also named 'hello'? If a controller is named, is that enough to call it up when /hello is in the URL? But then why is the sub named 'hello' too? It turns out to do with :Global vs. :Local in the sub's definition (the module could have been called so long as the 'hello' sub is ":Global") but that point is made only in passing: "(This hello action could have been implemented in as a :Local action, but implementing it in its own file makes it easier to edit without affecting other parts of the application.)" Either come right out and explain, with examples, the difference between :Global and :Local and where the URL-related sub goes, or skip the damned point altogether and just show us a Hello World application that gets up and running using one way or the other. The distinction is further glopped up when the text talks about the resulting debugging output and says "The :Global part is especially important, so be sure that the debugging output mentions it." ... Er, there is absolutely NO "mention" in the excerpted debugging output about "Global." But it's "especially important"? So I spend time trying to find the Global easter egg, but eventually I give up. I still don't know whether that's a mistake or not; I submitted an errata report a while back.

    I wish somebody with very little web application experience had read the manuscript critically before it was published, and had tried to run all the code. I blame Packt for that, not the author. For an author who is one of the principal developers, it's asking a lot to expect the author to recognize all the details that a newbie is likely to trip up on. The problem with knowing something is that you forget what it's like not to know. That's what makes teaching so hard.

    All that being said, I think this book ultimately will work to get me comfortable with Catalyst. There are plenty of chapters ahead of me (I have just finished 3) and I am pleased with Jonathan Rockway's writing style: writing as if he were speaking at the podium with a Powerpoint presentation behind him... like a story. The example applications look to be sophisticated enough to illustrate all the moving parts. And it has me very engaged... perhaps the glitches have had the happy effect of getting me to pay more attention to the subject matter than I would have if the presentation had been as smooth as butter. Still, I'm very disappointed with the show-stopping code mistakes... grrrr.