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.
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.
The other day, an article popped up in my feed reader that had a very interesting title (to me at least), Simple and Secure Login Script. As usual, I decided to click the link and give the article a read. Not overly shocking was the fact that I didn’t find the content of the article to be, how shall I say this…, overly factual. It’s not really a “tutorial”, but more of a “here’s some code that’s secure”. A quick review of the code found more than one vulnerability, and some significant things that I would change about it (as well as a few “really bad practices”).
So, rather than write a “rant post” about the code, I’ve decided to take another tactic. In this article, I’m going to walk you through my process for performing a security code review. Inline with the review, we’ll take note of any issues that we do find, and number them. Then at the end of the review, we’ll go over each one and look at potential mediation that we can apply and how to fix the issues.
So I got a rather interesting email today. Ever since I put my resume public a few months ago (even though it was taken off just 2 weeks later when I accepted a position), I’ve been getting emails quite often from recruiters looking for help. Most are mildly interesting and the majority I just glance over. But every once in a while I get one that takes me aback and makes me look deeper. Some of those turn out to be really good. And some of those are shockingly bad. This one is the latter…
Today’s IDEs (Integrated Development Environments) provide a lot of features that make development significantly easier. From error checking and debugging to intelligent syntax highlighting and refactoring, there are a significant amount of time saving features available. One of these commonly loved features I have disabled, and found it has made my life easier as well as the code I write better. The feature I am speaking of is autocompletion…
Today an article popped into my feed reader that raise my eyebrows. The article’s title is “Building Secured Web Applications Using PHP - The Basics“. The summary of the item looked interesting, so I decided to open it up…
What I found blew me away. It was filled with loads of bad information including some down-right wrong suggestions. Let me go through point by point and shed some light on the subject…