Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Re: Re: Matt's Script Archive Strikes Again!

by footpad (Monsignor)
on Jul 04, 2001 at 07:50 UTC ( #93772=note: print w/ replies, xml ) Need Help??


in reply to Re: Matt's Script Archive Strikes Again!
in thread Matt's Script Archive Strikes Again!

They are free as in beer.

And like cheap beer, they are bland, offer no flavor to speak of, and pass through your system and are (hopefully) quickly ejected.

They are trivial to install -- no modules, no dependencies.

And the security they provide is just as trivial. Be careful what you wish for, you may get it.

They are easy to use, just paste in the form supplied.

Just sign here and your soul, I mean, job, I mean server is ours. Also, don't forget to place this convenient "Hack Me" sign between your shoulder blades.

They cover a good range of jobs designers want done.

So does a raw silk blanket, but that doesn't mean you can't see everything there is to expose.

They usually work as expected.

No, they work as invested. If you go for the quick and dirty solution, you should expect to see some stains in your access logs. There *are* secure alternatives available, if you're willing to invest some education, some <local currency units>, and some time into learning better ways to do things. Sure, MW's free...but so is advice. People worth listening to are rare. Ignore their advice at your peril.

--f


Comment on Re: Re: Matt's Script Archive Strikes Again!
Re: Re: Re: Matt's Script Archive Strikes Again!
by legLess (Hermit) on Jul 04, 2001 at 08:29 UTC
    I agree with most of what you say about Matt's scripts. I've been hacking Perl for less than two months, and they give me shudders just the same.

    But your secure alternatives link game me pause. I actually bought that book (Writing CGI Applications with Perl, by Kevin Meltzer and Brent Michalski), and I wouldn't recommend it to anyone.

    Now, I'm not trying to trash Kevin or Brent, both of whom I'm sure know far more about Perl than I do, but I thought the book was weak. Points:

    • It looks like a nice thick book, but it's very padded; this verges on dishonesty, IMHO. The font is huge (12 to 14 points), there's a lot of padding (most code samples listed twice, 40 pages of appendix material that could have been 8 URLs), the margins are huge, and there's an awful lot of repetition (the 10 lines justifying -wT are repeated nearly every time it's used in a program).
    • Some chapters belong better in a Perl book ("Tied Variables").
    • Some inclusions/exclusions and focus choices are very odd. There's a very detailed chapter for Mason, but no mention of templates (literally - not even in the index).
    • Their style is very choppy. They'll present a couple lines of code, then a paragraph talking about it, repeat. It's very difficult to get a cohesive view of the program this way - it's spoon-fed to you rather than presented whole.
    • The cover's odd. What are we supposed to call it, "The Spiky Ball book?" ;)
    In short, the book is much more vocational than educational. Need to hack up some code fast? This book will help. If you really want to learn CGI, to know why and how it works, to have a broader grounding in the technologies used with it, and to build a firm foundation for future self-teaching, then IMHO nothing beats the Mouse book (CGI Programming with perl, an O'Reilly book). I bet that the Mouse book squeezes twice as much content into 450 pages as Spiky Ball does in 525.
    --
    man with no legs, inc.
      Amidst all the great comments on the book here at TPC, I was alerted that someone bashed the book here. So, of course, I had to look and respond :) Not only because that is my personality but because I tend to find bad reviews (about many books, not just mine since there have only been two, and this is one) based from people who basically the book isn't for. Anyways, on with the show...

      It looks like a nice thick book, but it's very padded; this verges on dishonesty, IMHO. The font is huge (12 to 14 points), there's a lot of padding (most code samples listed twice, 40 pages of appendix material that could have been 8 URLs), the margins are huge, and there's an awful lot of repetition (the 10 lines justifying -wT are repeated nearly every time it's used in a program).

      Well, I can't comment on your taste of fonts, that is too subjective. When code samples are listed twice (which you didn't give any example of this, and I can't think of any which were) it would have been done for clarity. Sure, the appendix could be a list of 8 URLs, but then again, almost any book on Perl (c, Python, etc..) could be one page saying RTFM. Appendicies are meant for reference mateials. So, while reading (or whenever) you can quickly look some things up instead of needing to get on the web to look at a URL, and maybe have to print it. As well, it shows what was current when the book was written. Things on URLs may not be the same as you find in a book. So, you need the context. The bits repeated on using -wT are repeated a lot, why? Because it is important. If someone learns nothing from the book but to use -wT in CGI, then the book served a purpose. Sometimes, people need to see things many times before they remember and understand it.

      Some chapters belong better in a Perl book ("Tied Variables").

      Um... it is a Perl book. Refer to the title. Of course, if we didn't cover tied variables, and just used them, then people would complain that we didn't cover this topic (which many people don't know about).

      Some inclusions/exclusions and focus choices are very odd. There's a very detailed chapter for Mason, but no mention of templates (literally - not even in the index).

      Because it covered Mason, not templates. There are too many templating systems and, IMO, if you cover one, you need to cover them all. If there is a 2nd Ed. I do want to cover TT.

      Their style is very choppy. They'll present a couple lines of code, then a paragraph talking about it, repeat. It's very difficult to get a cohesive view of the program this way - it's spoon-fed to you rather than presented whole.

      When you have a 100+ line program, it is quite hard (and ugly) to list all the code then explain it. An explination of code which was shown 5 pages before isn't very friendly, or helpful. If you want to see the full code, you look at the end of the chapter in the section titled Listings. One of the points of the book was to explain what was happening in digestable chunks. So, you have to spoon feed large scripts if you want to actually encourage learning.

      The cover's odd. What are we supposed to call it, "The Spiky Ball book?" ;)

      Actually, some people call it that. It has no name, and is mostly refered to as 'the book with that cover', or the M&M book.

      rest of comments not quoted

      Actually, I think you have it backwards. I think the Mouse book and this book are good compliments of one another. I (and most I speak with) find the book to be educational, then vocational. It teaches many concepts (of CGI, DBI, graphics, Perl, etc...) Then, once you learn, you can refer to it.

      I bet that the Mouse book squeezes twice as much content into 450 pages as Spiky Ball does in 525.

      If you are to blurt something like this out, please back it up, or remove it. As a (new) author, I find that when people simply spew out comments like this, it doesn't help anyone. What does the Mouse cover that we don't? What do they cover in more depth? What do we cover they don't? What do we cover in more depth? Do the books seem to go after different audiences? Do they compliment eachother?

      You say you wouldn't recommend this to anyone, but really haven't given any good (IMO), reason as to why. Because you don't like the font? Because we repeat important concepts like tainting and warnings? Because we cover Mason and not templates? Because we give code in digestable amounts, and then give detailed explinations of that code? Because you don't know what is one the cover? These really aren't good reasons. Good reasons would be: we got things wrong, the code is bad, it is unsafe, we don't cover important and interesting topics (which we do, DBI, XML, POP, graphic manipulation, cookies, embedded Perl, security, etc...) Maybe the book simply isn't for you, but that doesn't mean it isn't good for someone else and you should really consider if your reasoning to not recommend (especially in a public arena like this) is valid. If you have some valid gripes, send email to us so we can take them into account for future printing/editions. If you do not, and you simply didn't enjoy or 'get' the book, keep in mind that others may.

      Cheers,
      KM

        I wrote a long, detailed response to your post, giving point-by-point rebuttals to most things you said, and they thought ... why? It's pointless. The last thing you say is:
        If you have some valid gripes, send email to us so we can take them into account for future printing/editions.
        But you clearly can't mean this. After reading your defensive rampage I'm even less likely to raise concerns with you. I have every reason to believe that you'd respond the same way you did here, by saying "The book's obviously not for you, and you're wrong anyway." You're not likely to get "valid gripes" if your definition of "valid" is "must agree with me."
        --
        man with no legs, inc.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://93772]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (5)
As of 2014-08-30 04:10 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (291 votes), past polls