Yesterday, I got in an interesting conversation on twitter about object scopes and what constitutes a global scope. The discussion started around a piece of code that I stumbled upon from Fuel 2.0. I am a firm believer that service containers are not a form of Dependency Injection, and are only slightly better than global variables. That led me to make a few comments that elicited a reply from two Fuel developers. That led to a rather interesting debate that just couldn’t fit into 140 characters… So I’m going to go into topics that are tightly related: variable scoping and service locators.

Or anyone else for that matter. Lately, I’ve been getting a lot of feedback about my posts that I’m suggesting things that are going to get less experienced developers into a lot of trouble. Or that people are going to use my posts as justification for bad practices. Or that people are going to cause major issues by putting experimental concepts into production. My initial response is “That’s their problem.”

Today’s post is in response to an article that I read yesterday entitled They Write The Right Stuff. It’s a very interesting and insightful look into one of the most complex and critical pieces of software ever produced (also one of the most expensive). I think we can learn a lot from what they are doing, but I also think we should avoid copying what they are doing. The point that’s missed is practicality.

Every day I come across code that is insecure. Sometimes the code is so hilariously insecure that any 10 year old could break it. I’ve also gotten into discussions with people who should know better about their practices. It’s very, how to put this, disheartening. It’s sad that the average developer knows (and cares) so little about proper security practices. So, I’ve put together a simple pledge (or manifesto, if you’d like).

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…

There’s been a lot of traffic lately about what’s wrong with PHP, and counter posts about how good it is. I’ve even fallen into the fray in an earlier article trying to step up and defend the language. The problem with almost all of these posts is that they focus on the language itself and what’s wrong (or right) with it. This is not one of those posts.

Yesterday, I read an article about using GPUs to accelerate password hashing: No, Heavy Salting of Passwords Is Not Enough, Use CUDA Accelerated PBKDF2. The article makes some very interesting points about password hashing. But the conclusion of the article really misses a huge point, and get a major point fundamentally wrong (bordering on misunderstanding). Let’s start with the part they got wrong…

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…

There has been a lot of traction lately on the topic of the PSR “PHP Framework Interoperability Group”. They are introducing two new proposed standards: PSR-1and PSR-2, both dealing with code formatting standards. Actually, calling them proposed is a bit of a short-fall, since they both already have enough votes to be approved. I have read both, and actually agree and think they are quite good.

However, there’s a deeper problem. Open Standards is something that the internet was built upon. From HTTP, E-Mail and HTML to ECMA Script (JavaScript), OAuth and JSON, open standards are everywhere. The problem with the entire PSR process is that it is not designed to produce open standards.

I read a rather interesting post yesterday called PHP: a fractal of bad design. It’s been getting a lot of traffic among the PHP community lately because it’s rather inflammatory. But to be honest, it does make a lot of really good points. It also makes a lot of mistakes and misses a bigger picture.