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

One of the things that I see repeated over and over again is the simple question “What books should I read to become a better developer?“. Or “How did you learn about that?“. Or even “What does a coding standard matter?”… OK, so that last one was a bit of a sentinel question, but the point is clear. Where should you look if you want to read to improve your development abilities? Well, I figured I’d take a few pages out of my library and share which books worked for me, in order of significance. If you remember from a prior post, I indicated that you should choose concepts over implementations. This list should illustrate that.

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.