Summary

I’ve met one of the Authors, Lorna, at a few (4?) PHP conferences. She has been very supportive, friendly, honest and welcoming. That and her contributions to the PHP community made me check out the book.

The book is solid, well written and covers the most important topics that people need to think about when starting off with PHP. It is one of the few PHP book on the market that you can pass on to your trainees/junior developers without having to “unteach” them half of the taught bad practices afterwards. This is a great achievement in my mind and I’d definitely recommend checking it out and passing it on to your trainees and ‘junior developers’ … maybe read it first yourself and rip out a few pages in chapter 4.

Long Version

The book: PHP Masters – Write Cutting Edge Code.

First off: I really like the flow, structure and scope of the book. It touches upon a lot of important points for current php development while keeping it simple enough so that it can serve as an introductory book.

I’ve tried to write a more fluent list of impressions but it always came back to a list of points about the single chapters so that’s what I’m going with.

1. Object Oriented Programming

The book starts off describing the very basics of OOP and mixes in the special points to consider for PHP. The decision to use __autoload instead of the more current spl_autoload_register for most of the book strikes me as a little odd but I assume it was done for the sake of simplicity. In my opinion it could have been put in the appendix altogether though.

The chapter continues describing namespaces, statics, inheritance, type hinting, polymorphism, visibility, references, interfaces and exceptions.

The whole package is written in a very compact but understandable fashion that isn’t to find elsewhere. If I really had to I could nitpick a lot but in general I’ve only seen worse printed which is one of the points that makes this book so great for beginners. But the one paragraph that explained statics and started off with “When to use a static method is mainly a point of style.” made me cringe and wish that either a more verbose discussion would have been included or that it would just have been left out. That might as well just be my pet peeve as “a little static never hurt anyone” is what i find prohibits people from reaping the benefits of good OO.

Apart from that it was a really nice read summing up a lot of the complexity a grown language like PHP brings to the table while being concise and readable.

2. Databases

The book choose PDO as the API to explain and it is, imho, the best choice for a book like this. Personally, I prefer mysqli over PDO and a DB API Abstraction over both but for the book PDO made the most sense.

I like the explanation of the PDO API a lot and the book took the time to touch upon the finer points, for that scope, of MySQL like explain, foreign keys, m:n tables and inner vs left join and normalization. Those can be hard to tackle the first time and just mentioning them can save the reader a lot of trouble as they now know the concepts to look into

3. APIs

APIs as in web services to be more precise but that gets pretty clear on the first page. I was initially wondering if that would cover class design, naming methods and parameters and so on as it was pretty early in the book and before ‘Patterns’ but this chapter is talking about “Web APIs”

That’s a big one. I’m glad it is in the book as API design is getting more important nowadays and explains all the basic terms everybody should know quite well.

Starting of with a small explanation of what SOA meant before it became an enterprise-bs-bingo-word it explains the common data formats, xml and json, and common service types like RPC, SOAP and REST quite well showing nice examples for each one.

The thing I like the most here is that json and xml where explained and that it was shown how to use them from PHP. While I don’t like choosing SimpleXml over Dom for any task I can understand that it might be more readable for the examples. Calling it “Simpler” doesn’t relate to my experiences though but that’s a minor issue. (Did you know that if you rearrange the letters of “Simple” you can get “Broken” if you also swap out 5 of them.)

Of the service types the first thing explained is HTTP, the second is cURL and php streams. In my opinion that’s a great introduction as it first gives people a basic understanding of what is going on and then gives them a tool to play with and make sure everything works and everything is reproducible!

Explaining status codes, headers and HTTP Verbs on just a few pages isn’t easy but it came well so that everyone should be able to quickly follow along without needing to read an extra book on the subject.

With a sidestep into HTTP debugging going over RPC and AJAX, showing nice examples, the book is stepping towards the glory of REST!

It is prefixed with a, maybe questionable, disclaimer that REST is ‘quite academic’ which I choose to read as ‘quite hard to do right’ and then agree too. Due to the scope of the book it is understandable (even preferable) that it falls a little short explaining REST in all its glory touching upon HATEOAS (calling it url design) but not going further.

All things considered I can’t argue much against anything in that chapter as it delivers a good overview of all current possibilities for creating web services!

4. Design Patterns

sigh .. this is the only chapter I found myself disagreeing with heavily. Please don’t let that deter you in any way from buying the book. I liked every following chapter and while I’m really not happy with the choices in this chapter I’m sure they put in a lot more thought into this than I did for the review and decided that it was important to explain even the patterns that have a lot of issues associated with them.

You can skip this part of the review without missing out to much but I didn’t want to skip writing it.

The chapter starts of nicely describing what patterns are and why they are useful but then proceeds to slap me in the face by starting with Singleton.

I’m all for explaining Singleton as an example of “that’s what the people that came before you really fucked up” but the pages read like there could be use case for a Singleton in modern PHP. Really, there isn’t. The big disclaimer after the pattern description helps a lot but starting off with THE ONE MOST HURTFUL PATTERN that is common in PHP really annoyed the heck out of me.

I know/assume the order of patterns was chosen deliberately to show of the evolution of concepts, I just don’t agree with the order or the conclusion it leads to.

While I could come to terms with the decision to structure it like that turning the page made me believe I’ve picked up a fake “let’s fuck with the file sharers” copy that ended up in print by accident. I’d like to say this more nicely but this really was my honest response to seeing a SingletonTrait.

The whole chapter about Traits is a short explanation “This is a sample Singleton DB Trait”. We used to joke that the first thing traits would be abused for was to implement a Singleton with it and my own attempt at it was, rightfully, disregarded as ‘trolling’ by everyone I sent it to.

Then we get into the Registry pattern, the next most hurtful pattern down the line to continue the journey from Singleton to DI. Registry is only a little less broken than singleton and breaks with way to many OO concepts to be endorsed. The sample even goes into late static binding which again is just breaking with proper OO practices.

With a short side note on Factory there is the agreeable section about Iterator in which I’d only was annoyed by one point that was made:

“it is not uncommon to have an object that represents both the business logic—for example, basic CRUD (create, read, update, and delete, the four fundamental database interaction functions)—and storage of a dataset”

It is not uncommon, yes, that is true. It’s a bad idea though and CRUD is not a good example for business logic. People have enough trouble not doing MVC completely wrong and that sidenote didn’t help that case at all!

Continuing with small section about Observer, a pattern I don’t find any use cases in php but that is very valid here, we continue to Dependency Injection.

I wish I could end this chapter here but I can’t. It starts off with

“Dependency injection is one of the simplest patterns”

and while it can be quite easy I always found that Inversion of Control is one of the hardest to grasp OO concepts.

The very next sentence states

“For each dependency, you specify a setter method (and it’s nice if you add a getter too!) that will accept an argument that’s able to fulfil the dependency requirement.”

and if you explain DI to me like that in an interview that is the point where I will ask one or two clarifying questions and then ask you to leave! Not having any clue about DI is fine, especially for ‘junior developers’ but that explanation is beyond good and evil. For me that is completely unacceptable and hurtful to the readers. Especially the suggestion to even include a GETTER…

DI is a massive subject with many variants and setter injection is the most useless one. The sample even combines it with the Registry just to make it completely unusable. It doesn’t show of any benefit it has for separation of concerns and overarching application architecture.

The impact of using DI on the design of individual classes is way greater than the decision to use MVC and I feel that was cut horribly short, It should have been explained in more detail or at least left out completely if no somewhat acceptable explanation was possible in the scope of the book. Maybe I’m being to pedantic here but I feel that if the focus of the book here was to teach people about the existence of patterns one sample just showing of constructor injection in combination with a factory and not the mostly pointless setter injection could have sufficed.

MVC

I’ve spent way to much time on that chapter to I’ll keep that one short

• Your Model is not your data access layer
• MVC is NOT(!!1eleven) your application architecture
• Stop telling that to people, it did enough damage as is. The PHP community is slowly climbing out of that hole. Don’t throw it back into it!

After ordering a couple of copies for other developers I feel that I should cut out that chapter (and the last one) or at least put big disclaimer in it. Thankfully the rest of the book is good enough to make up for everything I disagree with here.

*Keep in mind that this is just my take on that chapter

There is no ONE TRUE WAY of writing PHP code. “What works for us” is a very good choice and please don’t take offensive with the way I’ve expressed my opinion here :)

5. Security

Amazing!

Everything that needed saying was said. The structure (Problem, Sample attack, Fix) is really great. While there surely can be nitpicks it tells developers everything that they need to hear before deploying their first websites. It’s a great read with nice thought out attacks and fixes.

If now we could get people to just stop using

<form action="<?php echo htmlentities($_SERVER['PHP_SELF']); ?>">

and use

<form action="?">

or the related methods ;)

6. Performance

Yay! No micro optimization but showing what matters!

AB and JMeter get us started continuing with APC and Session Storage options leading to xDebug and XHProf delivering a very nice chapter that I enjoyed.

7. Automated Testing

The testing section starts of good showing basic phpunit usage and suggesting an ok folder layout. I missed the “test suites organization though the phpunit.xml file” section as this is something people tend to struggle with but all in all it’s a very solid start.

It goes into “testing views and controllers” and while I wished where wasn’t any need for that section a lot of frameworks struggle with making their controllers testable. They are just normal classes they should be testable like everything else… well :)

I don’t draw the same conclusions as the book but it’s nothing too far off, unpractical or hurtful that I feel the need to go into it. It’s a good read rounded off by all the integration testing options that exist. Showing tools for front end, db and even load testing.

8. Quality Assurance

Showing of most of the phpqatools and I found myself agreeing with pretty much everything that was said. Especially the suggestions that having a coding standard is more important then which one and that it’s not hard to build your own standard are very close to my heart.

Talking about SCM with svn AND git is a very welcome additions to the book that I didn’t expect at first but was very happy that it got included. It makes it even more useful to pass it to trainees.

Finishing up with automated deployment this chapter of the book touches many many important points of an projects live cycle.

A. PEAR and PECL, B. SPL: The Standard PHP Library, C. Next Steps

Icing on the cake. Using pear and pecl is easy once you know what to do but can be a major pain if nobody ever showed you. I was very happy to find this included in the book. Going to deep to even show off how to create PEAR packages and compiling extensions by hand.

The SPL section is solid and the suggested “next steps” are great!

Conclusion

I can only recommend the book to everyone. Tread with care in the OO sections but apart from that this is one of the view PHP books that should be read by everyone.