A common problem that developers face when building applications is how to allow the application to be “plug-able” at runtime. Meaning, to allow non-core code to modify the way an application is processed at runtime. There are a lot of different ways that this can be done, and lots of examples of it in real life. Over a year ago, I wrote a StackOverflow Answer on this topic. However, I think it deserves another look. So let’s look at some patterns and common implementations.
As any of you who follow the PHP internals list know, scalar type hinting has been a hot topic as of late. You’ll also know that I’ve submitted two new RFC (Request For Comment) proposals for inclusion of two new major features in the PHP language. I figured it was worth going into both RFCs and patches a little deeper, explain my rationale and (hopefully) garner some more visibility of the proposals.
The other day I had read an interesting post by 37 Signals entitled Why We Don’t Hire Programmers Based On Puzzles, API Quizzes, Math Riddles or Other Parlor Tricks (say that 10 times fast). Then I was pointed to another article by C for Coding entitled Interview Programming Problems Done Right. That got me thinking about the interview techniques that I’ve used at my current and prior jobs. It’s a different style than either of those two posts, so I figured it was worth talking about.
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:
One of the most frequent questions that I get asked is “How can I become a better developer?” I think that it’s a very good question to ask that deserves a good response. But how can you respond to something like that? Becoming a better developer depends so heavily on past experience (where to grow), interests and rationale (why do you want to grow), that it’s really hard to answer without a fair bit of discussion. This post reflects my experiences from both my own growth and the growth that I’ve seen in others.
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.
Last night I was discussing the SPL Iterators with @go_oh in the PHP StackOverflow chat room when I came across something very interesting. We were talking about why some of the SPL Iterators accept only an Iterator as the constructor argument (Such as LimitIterator), and others accept either an Iterator or an IteratorAggregate as the argument (Such as IteratorIterator). Feeling that this would be a useful feature to add (having all of them accept an IteratorAggregate), I opened up the PHP source and started looking at how hard of a change this would be. What I found was… Interesting…
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.
Well ok, not really. But you should not be securing hashes against rainbow tables anymore, you need to secure them against brute forcing. Rainbow tables are still very effective for simple hashes (md5($password)), but just because an algorithm is hard to use for a rainbow table doesn’t mean that it is safe, because the rainbow table is dead…
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.