I speak a lot on design patterns. This year, I’ve given nearly a dozen talks on design patterns, relating to my book, Practical Design Patterns in PHP. One of the questions I get the most often about design patterns is, “how do I pick a design pattern to use in my project?”
My answer is always the same: you don’t.
There’s a large group that seems to think I’m against frameworks of any kind, telling beginners that instead of using a framework they should learn straight PHP, build stuff from scratch.
I’m definitely not interested in that.
Towards the end of my talk at phpDay in Verona, I was asked by two developers which framework I thought they should learn: Symfony or Laravel. I understand the pressure that developers feel like they’re under to learn a framework, and to somewhat “predict the future” by figuring out what is likely to be popular in PHP for the next few years.
But my answer to them wasn’t what they expected. I told them that if they were new to PHP, that they should focus on learning PHP.
This summer, I’ll be touring with The Crafting Code Tour to 18 different cities around North America. Since I’ll be in some cities for more than one day, I’m using that extra day to organize an in-person training for interested developers.
The training seminar is called Mastering Object Oriented PHP, and focuses on beginning to mid-level object-oriented application development skills. We’ll cover PHP-specific behaviors, the SOLID principles in depth, basic design patterns and more.
It’s a pretty standard thing: take a new job, sign a new employment contract. The contract usually pretty boilerplate – no creation of a partnership, no guarantee of future employment, the employment is at-will, your salary is $X, etc.
But there are often provisions hidden in these long, multi-page documents that can create limitations on your future opportunities, whether you plan to go to another company or you plan to start your own firm. What are these provisions and how can they affect you? Let’s take a deeper look…
Despite what His Majesty, David Heinemeier Hansson may have said, unit testing is by no means dead. And, in fact, system testing is no more a complete testing strategy than 100% test coverage with unit tests. Let me explain.
Test Driven Development (TDD) is a philosophy that asserts testing is so important that the tests should be written first, to emphasize the design of the code. The idea is that by writing a failing test, and then writing code that passes that test, you end up with an overall better architecture.