This morning I was asked a question that took me by surprise: “Your examples for PasswordLib are in OOP style, how do I write it in procedural style”… This took me by surprise, because the examples actually are in a procedural style. So I felt that I should write a post about the real differences between OOP and Procedural coding styles. Hint: whether you use classes and objects or not has very little to do with the answer…
A few weeks ago I was sparked into a twitter conversation with Larry Garfield (@Crell) about the value of comments in code. Really, twitter is not the best place for that conversation, so I decided to write this post to illustrate my beliefs on commenting. Let’s start this story with the tweet from Larry that set off the conversation:
Nothing drives home the need for good code comments like working on code that doesn’t have them.
A pretty innocuous comment that is quite insightful. But that led me to respond with:
Nothing drives home the value of good, clean code by working on code that doesn’t need comments.
That led to an interesting discussion that just couldn’t fit on twitter. So let me explain…
Here are the slides from my presentation at NYPHP on STUPID vs SOLID development. Click through to see the slides.
The other day I announced the release of my new password hashing library, PasswordLib. As I’ve come to expect, Reddit was full of interesting commentary on the topic. Some was good, some was bad and some surprised me. What surprised me was the insistence on a global salt (otherwise known as a “pepper”). So, I started thinking about it some more, and I figured I’d write a post on why I don’t use peppers in my hashing algorithms (and why you may want to rethink it too).
Lately, I’ve found myself in a number of discussions about Technical Debt and how it applies to project development. Overall, I think it’s a very powerful tool that – when used wisely – can be a great asset to any team. It seems to me that most of the people that I’ve been talking to really don’t agree, and see Technical Debt as a plague that should be eliminated at first sight. So, I figured I’d share my opinions, and see what you think…
I came across a rather interesting post yesterday entitled The MicroPHP Manifesto. The author made clever use of a very interesting analogy (drum players) to try to prove his point that less is more. The article makes a very interesting read, and I would suggest that everyone reads it. Go ahead. I’ll wait.
With that said, I have to disagree with the article rather vehemently. I think the message is somewhat right, but for all the wrong reasons. Let me try to explain:
Recently there has been a rather heated and intense discussion on whether the PSR-0 autoloader “standard” should be included as part of the PHP core (in ext/spl to be exact). I’ve tried to stay out of the discussion and have successfully done so. Until today. I feel that there’s something that’s been missing to the discussion. So rather then posting this to the internals list, I feel it’s better served by a blog post on the subject. So here’s my take on it.
TL;DR:
I don’t think it should be included in the core.
A tool is only as good as how it’s used. It seems like such a simple concept, yet it’s amazing to see how many people get caught into the trap of thinking that because a tool is there, they are safe. We see it all the time in almost any industry. Company X pays untold millions of dollars for a product, just to find out later that it didn’t do what they needed. It’s such common sense that it’s hard to think of someone logically arguing against it. Yet the same mistake is made over and over and over and over again. And on August 18th, we saw a really blatant example of this with PHP’s 5.3.7 release.
When it comes to optimization, there are two competing viewpoints in the PHP community. Some say that optimization should only ever be an after thought and to avoid premature optimization at all costs. Others will say that this is impractical, and you should make your application fast as you write it, since then you won’t have to go back and clean it up to make it faster. While I can understand the viewpoints of both sides, I am firmly in the former category. Given the number of discussions that I’ve had as of late on the topic, I’ve decided to write a post as to why I believe my viewpoint is better and more sustainable in the long run.
Let’s face it: error handling in PHP is crap. Actually it’s worse than crap, it’s craptastic. The core has almost no support at all for handling errors. Sure, PHP has a robust error reporting and logging system, but it has no real way of handling those errors. If you want to write robust code, you need to be able to actually handle errors. So how can we handle errors in PHP?