Back in 2011 I wrote a series of three articles about “Modern Perl” for Linux Format. Although I mentioned allthreearticles here as they were published, I didn’t post the actual contents of the articles as I wasn’t sure about the copyright situation.
But now I suspect that enough time has passed that copyright is no longer going to be an issue, so I’ve added the full text of the articles to this site. The articles are all about writing a simple web application to track your reading. They use DBIx::Class and Dancer.
I was sent a review copy of Penetration Testing with Perl by Douglas Berdeaux. 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.
London.pm is undergoing one of its periodic reorganisations. We’re in the process of moving our web site over to a new server and as part of that move, we’ve decided that we’ll move our mailing list infrastructure to a third party system. Both the main discussion list and the announcements list will be run on Sympa.
But that’s not all the lists we currently have. In particular, we had a London Perl Jobs list, which anyone could use to post details of Perl jobs in London. It’s been decided that this list is too much hassle to keep up. Apparently, it needs a pretty high level of work from moderators. So that list isn’t going to be migrated and it will quietly die.
I thought that was a bit of a shame. I think it’s a useful list. And, in particular, I think it would be easy for outsiders to misread the reasons for the closure – given the current discussions about the death of Perl. Perhaps the list was killed off because there are no longer any Perl jobs in London (you and I both know that’s not true, but not everyone is following the situation as closely as we are).
So I decided to do something about it. I just happened to have a useful-looking domain sitting around not doing very much, so I’ve set up a jobs mailing list over there. Feel free to subscribe if you’re interested in Perl jobs in London. And, more importantly, please encourage people who are looking for Perl programmers in London to post their jobs to firstname.lastname@example.org.
Currently, the list is configured like this:
Archives are public
By default, replies go to the poster rather than the list
Posts are accepted from anyone
All posts are moderated
I’ll be happy to reconsider any of those settings once the list has been running for a while. I’m also considering setting up an associated jobs discussion list, if people think that would be useful.
For many years (since the end of 2007, apparently) I’ve been uploading the slides from my talks and training courses to Slideshare.
This morning I got an email from them, telling me that they had made their analytics pages freely available. I don’t know if this is a permanent change or a special offer, but the link (which will only work for logged in users) is http://www.slideshare.net/insight.
There’s a lot of information there and I look forward into digging into it in a lot more detail. But I thought it would be interesting to share the list of my top ten most popular slide decks.
A couple of days ago, I updated to my laptop to Fedora 21. One of the new features was an application called DevAssistant which claimed that:
It does not matter if you only recently discovered the world of software development, or if you have been coding for two decades, there’s always something DevAssistant can do to make your life easier.
I thought it was worth investigating – particularly when I saw that it had support for Perl.
Starting the GUI and pressing the Perl button gives me two options: “Basic Class” and “Dancer”. I chose the “Basic Class” option. That gave me an dialogue box where I could give my new project a name. I chose “MyClass” (it’s only an example!) This created a directory called MyClass in my home directory and put two files in that directory. Here are the contents of those two files.
print("The hotel name is ".$myClass->getHotelName()."\n");
print("The hotel street is ".$myClass->getStreet()."\n");
print("The hotel is booked on the name ".$myClass->getGuestName()."\n");
print("Accomodation starts at ".$myClass->getBookedDate()."\n");
It’s great, of course, that the project wants to support Perl. I think that we should do everything we can to help them. But it’s clear to me that they don’t have anyone on the team who knows anything about modern Perl practices.