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.

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…

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:

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).

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.

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…

As a PHP developer, I find myself referencing PHP’s source code more and more in my normal everyday work. It’s been very useful in everything from understanding what’s happening behind the scenes to figuring out weird edge-cases to see why something that should be working isn’t. And it’s also very useful in the cases when the documentation is either missing, incomplete or wrong. So, I’ve decided to share what I’ve learned in a series of posts designed to give PHP developers enough knowledge to actually read the C source code behind PHP. No prior knowledge of C should be necessary (we’ll cover some of the basics), but it will help.

This is the first post of the series. In this post, we’ll walk through the basics of the PHP application: where to find it, the general structure of the codebase and a few really fundamental concepts about the C language. To be clear, the goal of the series is to get a reading comprehension of the source code. So that means that at some points in the series, some simplifications will be made to concepts to get the point across without over-complicating things. It won’t make a significant difference for reading, but if you’re trying to write for the core, there is more that will be needed. I’ll try to point out these simplifications when I make them…

Additionally, this series is going to be based off the 5.4 codebase. The concepts should be pretty much the same from version to version, but this way there’s a defined version that we’re working against (to make it easier to follow later, when new versions come out).

So let’s kick it off, shall we?

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.