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…

I’ve been using Jenkins to manage builds of my projects for a while now. This was fine for a while, but now that my projects need to support multiple versions of PHP, it left something to be desired. I wanted a system that could build against multiple versions of PHP. And more so, I wanted to be able to build against multiple compiles of the same version (different options, etc). This is how I built just such a system…

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.

As recently as 5 years ago, I barely understood the meaning of Open Source. I had been working with computers for my entire life (I was using a Commodore 64 before I could walk). I had been programming them nearly as long (I wrote my first program before I started grade school). I was an early adopter of Linux (I still have a Red Hat 1 disk somewhere). But I never guessed the impact that open source would have on my life. I never appreciated the impact that open source would have on the world. The past 5 years have changed me forever. This is my story.

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…

Very often when we look at a class diagram for a new application, it’s quite overwhelming. There are tons of classes, all interacting with each other. These interactions are everywhere. It actually resembles a spider web of interaction. Trying to decode this web to figure out what the application is doing can be a lesson in futility for some applications.

How then, can we design an application such that it’s easy to follow? How can we build an application that’s easy to understand on all levels? The answer is deceptively simple: by using layers. Let’s explore how we can use layers to help build our applications in a clean, easy to follow and maintainable manner.

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.

Here are the slides from my presentation at NYPHP on STUPID vs SOLID development. Click through to see the slides.

Time for some more shameless self-promotion… I’ll be doing a talk at the New York PHP group on Tuesday May 22, 2012. I’ll be discussing some Object Oriented design principles and how to apply them to your projects. We’ll specifically discuss the STUPID and SOLID principles. Here’s the full abstract: