Everybody likes “the new hotness.” Everyone loves a new car, or a new computer, or the state-of-the-art video gaming console. It’s why people camp out for days to get their hands on a new iPhone, when they could just buy one the next week off the shelf. People love to have the hot thing, right now.
Perhaps, then, it shouldn’t be so surprising that people get tremendously excited when a new version of PHP comes out. People look forward to the new features, whether they be the trailing commas in list() syntax or counting of non-countable objects.
For many, the beginning of a new year heralds an opportunity for improvement in our life through the creation of new year’s resolutions. Even though January 1 is an arbitrary date (and we are able to make change anytime we see fit), the roundness of a new year’s start brings about the will to initiate change for many. For me, I appreciate the start of a new year as a benchmark, a demarcation point between old and new, and I like to make resolutions of my own.
Of course, only 8% of people actually keep their resolutions. I’m not immune from this failure, as I made several resolutions in 2013 that I was unable to keep. But this has been the exception, not the rule, and I have kept resolutions in the past.
When it comes to best practices, there’s always a healthy debate, and that’s never more true than in the PHP community. The “best practices” that have been written about, agreed upon and talked about don’t exist out of thin air, but are hard-won knowledge derived from experience, plus a little bit of not following best practices.
I want to talk a little bit about what PHP’s best practices are, where they come from, how you can get involved in the next generation, and the best way to use best practices in your day-to-day coding.
Hiring is perhaps the most challenging thing that any manager can ever do. Getting it right is half skill, half luck. Making a good decision on a candidate can be the difference between moving the project forward and setting it back.
So what happens when you’re hoping to hire mid-level or senior engineers, and you end up with a staff of juniors? This isn’t all that uncommon a problem; I’ve seen it at least a dozen times in my career. What do you do next?
Recently there’s been a great deal of discussion as to the merits of isolated testing versus integration and acceptance testing. Some proponents argue that integration testing far outweighs the value of isolated testing. While this is a perfectly valid position, I feel oversimplifies the complexity of testing in the same way that the “isolated testing only” crowd does.
Integration testing is wonderful for testing how components come together for a particular task. And it’s perfectly acceptable (and reasonable) to test how a model interacts with a real database, or to test how a controller interacts with the lower levels of an application.
Any time software and business come together, there is an inherent conflict between “get it done fast” and “do a good job”. This conflict often comes to a head when deadlines are missed, whether through unrealistic expectation or underestimation on the part of the developers.
The dilemma between quantity, speed and feature set isn’t going to go away any time soon. It’s an inherent dilemma in software. But there are approaches we can take to help solve it.