I was sent a review copy of Penetration Testing with Perl by . I really didn’t like it. Here’s the review I’ve been sharing on Amazon and Goodreads.
I’ve been wanting to learn a bit about Penetration Testing for a while and as Perl is my programming language of choice this seemed like a great book to choose. Unfortunately, it wasn’t.
I have no doubt that the author knows what he is talking about when it comes to Penetration Testing, but there were several things that prevented this book from transferring much of that knowledge to me.
Firstly, the typesetting in the book is terrible. I was reading the Amazon eBook edition – it’s possible that the printed version is better. For example, there’s a lot of code in this book and it’s in a proportional font. In order for code to be readable, it needs to be in a fixed-width font. Also, there are two or three places where an equation appears in the text, but it appears in an unreadably small font. I have just checked in the PDF version of the book and neither of these problems appear there. It would seem that this is down to a problem in Packt’s eBook creation process.
Secondly, it’s obvious that English is not the author’s first language. At times this really prevents him from getting his point across clearly. I’m very happy to see non-native speakers publishing books in English. But the publishers need to provide high quality proof-readers to ensure that the language is good enough.
Thirdly, the organisation of the book is a little haphazard. The first couple of chapters are introductions to Perl and Linux, but after that we are dropped immediately into a discussion of network sniffing. Later in the book there are chapters on intelligence gathering, social engineering and password cracking. These are all far simpler topics which could have served as a gentle introduction to the book, getting people up to speed on Perl before delving into the complex internals of network packets. Once again, I think this should be the responsibility of the publisher. There should be a good editor working on the book alongside the author and shaping the manuscript so that the story it tells guides the user through the subject as easily as possible.
Finally, the book falls short in its technical content. I can’t comment on the author’s explanations of Penetration Testing (I was, after all, reading the book to learn about that topic), but the Perl code that he uses throughout the book is really bad. He is obviously someone who only ever learned enough Perl to get his job done and never bothered to learn how Perl really works or to keep his knowledge up to date. As a result, the book is full of the kind of code that gives Perl its reputation as a write-only language. The idioms that he uses are often out of date (using ‘-w’ instead of ‘use warnings’, for example), confusing (predeclaring subroutines unnecessarily, using ampersands on function calls) or just plain wrong (‘my ($x, $y, $z) = 0 x 3’ just doesn’t do what he thinks it does). Actually, it’s worse than that. It’s not just Perl he doesn’t understand, it’s the fundamentals of good software engineering. His code is a confusing mess of global variables and bad design. This is another failure by the publisher. There should have been a competent technical editor checking this stuff.
I’ve read four or five Packt books now. They’re all of this standard. None of them should have been published. But Packt seem to have hit on a good business model. They find unknown authors and produce books as cheaply as possible. Their publishing process omits all of the editing and checking that more reputable publishers use. The books that come out of this process are, of course, terrible. But, for reasons I can’t understand, people still buy them.
Packt books – just say no.
I think your last paragraph sums up things nicely with regards Pakt. It does affect certain other well known publishers though, although their business models are perhaps not quite as cut-to-the-bone as Pakt’s. The tech publishing industry has come under tremendous pressure from free info on the Net. Yes, it is down to cost, by forgoing a knowledgable and experienced technical editor and/or copy editor you can save a bundle.
Dave, I’d like to reply to your last comment: “Packt books – just say no.”
Perhaps these books are inelegant, and this is frustrating, but what are we going to do about it? Negative criticism is not going to help them improve their process, or help engage new, younger, people in our language of choice.
Perl has an image/PR issue, with many people expecting, for more than 12 years now, for Perl6 to be the best thing since Perl5. Before anyone jumps in and says “that’s irrelevant”, I think it’s important for us (in the Enlightened West) to realize that these Packt books are coming from a place where a lot of coding work has been sent. India. (if you don’t believe me, read the book credits).
This has a couple of relevant points for us to keep in mind, before we hasten to discard these offense-to-the-senses productions to the flames. While remembering that on the one hand Perl has appeared to be on the wane, also consider for a moment this growing Perl market, consider the numbers of Perl-interested people involved here, and the potential.
Recently I proposed publishing a Perl6 book to co-incide with the long-awaited release at the end of 2015. Of the several people who were recommended to me as competent authors to write such a book, not a single one of them were prepared to undertake this task. At the same time, someone produces a topical book, of interest to people outside the core Perl community, and what happens? It’s fairly slated.
Personally, while I realize this might be satisfying to many, I think this is the wrong tack. Perhaps there are positive things to say about the book too: “not written in the very best coding style perhaps, but certainly includes a number of interesting ideas to help you secure your network with”. “could benefit from a technically experienced publisher, to improve the presentation”. “It’s good to see Perl still at the core of useful solutions in this modern IT landscape”. and so forth.
Call it what you like, some positive feedback on behalf the people writing and publishing Perl books in this, 21st century, would go a long way to promoting the Perl programming language for the next generation.
“Before anyone jumps in and says “that’s irrelevant”, I think it’s important for us (in the Enlightened West) to realize that these Packt books are coming from a place where a lot of coding work has been sent. India. (if you don’t believe me, read the book credits).”
That sounds a tad racist. Especially coming from educated Irish blood, which is quite rare I take.
I am a product manager at Packt. Dave’s review was of course a painful read for me. But I must disagree with Richard: this criticism *will* help us improve our process.
Packt was not established to publish bad books cheaply. We always pursued a low cost approach, but with the intention of delivering high quality too. As a small business we had a good intuition of what made a good tech book, but some of this intuition has been lost as we have grown. We are now working hard to deliver high quality, while continuing to publish a high volume of unique titles.
Dave’s review highlights four key areas of concern for us:
1. Typesetting and reading experience — our books need to be well laid out on every device and in every format.
2. Structural decisions — getting the right content in the right order. We left the good stuff too late in this book.
3. Clarity of expression — we have not helped the author express his intentions and knowledge clearly to the reader in writing.
4. Technical accuracy and good practice — we should have helped the author improve their Perl code.
Many of our books do not have these problems, but too many do. Rest assured: addressing these issues is very high on my and my colleague’s agenda. Dave’s review has helped crystallize them, for which I am grateful.
Unfortunately this review will stick with my book for a long time, so I decided to engage David on Amazon for the review.
I did track down three lines of “predeclared” subroutines that were not needed but cannot find a single subroutine call in which I have “prototyped” and called using an ampersand. He also had a semantic error in his code snippet in which I responded to- as he believed I had no idea how to initialize three variables at once using a single line of code- which he didn’t even address in his follow up response, should be- my ($x, $y, $z) = (0) x 3; – i know what “assign 0 three times to $x” means vs. “assign zero to $x,$y, and $z.” I replied to the reviewer that if I made any errors that he could have submitted it to the publisher’s feedback email address as stated in the beginning of the book.
Also most of the global variables I used were needed by the Perl modules that I had used. I actually used many Perl modules at a time in most applications that he responded with a new complaint- they have “terrible interfaces”. Not sure how that effected my book review… I read through each Perl module on CPAN and used them each just as they were intended in their documentation.
The rest of his arguments- with me- dealt with my coding style and me being “old fashioned,” and the method and style I used to convey to the reader how to create penetration testing tools using Perl. Isn’t one of the Perl sayings “there’s more than one way to do it?” Sorry, but even if my coding style is not advanced or flawless (Perl golfing aside), the code is still 100% functional and all examples worked perfectly throughout the book as I have copied and pasted each programs output directly to the pages and shared with the technical editors my software and even environment for them to test. The penetration testing was done with Perl successfully as the book intended. I feel that if an advanced Perl programmer were reading my book, they would obviously feel that there were better ways to write the code, but still get an understanding as to how the actual penetration testing applications work and get a feel for them using my code examples. I am surprised that I received no credit for that — in fact, in the preface I stated “Through each project I seem to emerge a different person, and this was no exception. I realized this is because with Perl programming, I am constantly learning and no matter how intimate I may feel with the language, I can always do it better. Isn’t that right, Tim Toady?”
He even complained about the books layout, which was available to him in the table of contents before he even read the book. Which, this is also strange, since I wrote in the preface about how much I wanted to show that Perl can do heavy lifting. None of the programs are large in size, either. In fact, I broke the bigger ones up into small pieces and explained what every piece did on a per-line basis. was that really not enough to avoid the reviewer’s confusion?
Also, I’d like to see an example where my English “language is [not] good enough.” Sorry, but I grew up in Pittsburgh, PA, USA, not the UK. And yes, I am not knowledgeable in software engineering. I am not an engineer by any means. I am completely self taught using books, Wikipedia, the Google search engine and other valuable resources, such as IRC. College, as appealing as it is, is just too expensive. In fact, I just write Perl for fun and am just a guy who was contacted out of the blue to write a book about making little Perl scripts that are applied to penetration testing. — If i was the wrong person for the job, is that my fault?
@PacktDavidB – I stuck up for Packt where I could – the books are NOT “produced as cheaply as possible” as they had paid me above average for the royalties and advancement- to which he implied that Packt is not allocating their resources properly- “I’m not entirely surprised that Packt pay the authors well. I expect you’re getting money that other publishers would spend on copy-editors, proof-readers and tech editors.” This may be true, since the editing process was horrendous to say the least. After I wrote my initial drafts, they were sequentially handed around to many people who mangled the code snippets and Linux command-line program snippets by deleting spaces and copying and pasting variable names three or more times in a row making the code unusable. One of the editors literally said he gave up because he couldn’t install a Perl module. A few times, the first version of the draft was sent back to me after we had already made many changes to the chapter, which is very confusing. Also, when the code testing began, the technical content editor sent me an email asking me what “uninitialized value,” “Can’t exec “smbtree”: No such file or directory,” “please provide a username,” and “Can’t locate Net/Frame/Device.pm in @INC” means and how to fix them. Shouldn’t a Perl programmer and technical editor understand this? I am confused as to how he ended up with a free copy of the book since he obviously had a preexisting grudge with the publisher.
Also @PacktDavidB – as far as the typesetting goes, I noticed that with any book that I publish, there are always complaints about the eBook version. In fact, I even went so far as to remove the “Regular Expressions – Simplicity and Power in Code” eBook version from Amazon since the publisher could not make a readable eBook version. I also submitted high resolution images to the content editor for each mathematical equation that the reviewer could not decipher on his eBook, so I am not sure what happened to those.
That’s quite unfair what packpub did with you. I have read many articles about packtpub that how unorganized and unprofessional they behave. Authors spend months to write a book and what they get in return, is too little. You did your best and try to make contract with some good publishers, but it will cost you lot.
My experience with the Packt book on Catalyst by Jonathan Rockway was so bad that I still almost get angry when I think about it. An inexcusable amount of nonworking code. I will never, ever buy another Packt book.
Had the same experience with that book.
Set aside bad Perl and shaky english language proficiency, the author nonetheless succeeds in transfering his network security techniques in this book. Far from being perfect, but still a good reference, this book makes great bathroom reading.
Working on the other side of the fence, it’s always good to have a clue of what’s going out in the wild in order to be able to respond to it. I discovered tricks in this book that will help me strenghten my systems.
Packt gives a chance to new authors to take some experience. The sometimes harsh critics can be taken as opportunities to do things better in the future. There’s still plenty of material out there to write another tome of this book while seriously considering reviewers advices.
Dave,
I’m not sure what has triggered this rancid post.
Let me play the devil’s advocate here.
Packt is surely not be the best publisher out there.
That aside, they only edit and print books – they do not author them.
Authors have to try to make their code understandable to a reasonably large audience.
Maybe simplicity is the right way to go in these circumstances.
Experienced programmers won’t directly copy/paste the code into their projects.
There are a number of good books out there from Packt.
Have a look at some of the reviews.
People actually learn stuff from these books.
http://www.amazon.in/Mastering-Metasploit-Nipun-Jaswal/dp/1782162224
http://www.amazon.com/Mastering-Clojure-Data-Analysis-Rochester/dp/1783284137
http://www.amazon.com/Clojure-Performance-Programming-Shantanu-Kumar/dp/1782165606
http://www.amazon.com/Clojure-Reactive-Programming-Asynchronous-Applications/dp/1783986662
What triggered this “rancid post” was the fact that I had spent several hours of my time reading a terrible book.
You say that people learn stuff from Packt books. Having read four Packt books on subjects that I understand, I would worry about the quality of the information that they learn. I have never read a good Packt book.
And I learned long ago to be deeply suspicious of Amazon reviews of technical books. Most reviews of technical books on Amazon are written by people who know little or nothing about the subject of the book (that is, after all, why they are reading the book in the first place). Therefore, it seems obvious that they are not the right people to be reviewing the technical content of the book.
They might well have enjoyed reading the book. They might well have learned things from the book. But they can’t possibly know how good the information that they learned is.
> Most reviews of technical books on Amazon are written by people who know little or nothing about the subject of the book (that is, after all, why they are reading the book in the first place). Therefore, it seems obvious that they are not the right people to be reviewing the technical content of the book.
Might as well also claim the authors of these books have zilch understanding as well.
Sounds extremely judgmental from a person with your experience and reputation.
“Might as well also claim the authors of these books have zilch understanding as well.”
That makes no sense. Most people who read a technical book will have little or no knowledge of the subject that the book covers (that is, after all, why they are reading the book). So they would have no way of knowing whether the information they are getting is correct or not.
You only have to read the glowing reviews that all the terrible Perl/CGI books from the late 90s got to see that I’m right. I can’t see how anyone can disagree with this.
“Sounds extremely judgmental from a person with your experience and reputation.”
Not judgemental at all. Just common sense.
> Most people who read a technical book will have little or no knowledge of the subject that the book covers (that is, after all, why they are reading the book). So they would have no way of knowing whether the information they are getting is correct or not.
> You only have to read the glowing reviews that all the terrible Perl/CGI books from the late 90s got to see that I’m right. I can’t see how anyone can disagree with this.
> Not judgemental at all. Just common sense.
IMHO a person who bought “Penetration Testing in Perl” would have some proficient knowledge or experience with Perl.
I guess the real culprit is the diversity of patterns in Perl code (aka ‘more than one way to do it’).
That aside, as an author myself, I guess there a few lessons to be learned here.
Packt has published books about practical usage of NHibernate, NServiceBus and ServiceStack 4. None of other publishers did this. Considering that these frameworks/products are rather popular in .NET world but somewhat poorly documented – I think Packt is doing a good job to cover topics that no one else is willing to cover because the market is not that large.
I understand that and I appreciate what they are doing. I just wish they did a better job of it.
Thank you, I was about to subscribe and waste $100 on a yearly subscription.