Simple, Easy, Risk and Change

I’ve been thinking a lot about change lately. Things finally resonated to me after listening to Uncle Bob Martin on No Capes. He made an amazingly interesting point about change and different methods for minimizing the risk over time of change.

I want to share some of what I’ve been thinking about along those lines. What follows is a collection of some of my evolving thoughts relating to change and complexity. Let me know your thoughts in the comments.

Thoughts On The Design Of APIs

Developers as a whole suck at API design. We don’t suck at making APIs. We don’t suck at implementing them. We don’t suck at using them (well, some more than others). But we do suck at designing them. In fact, we suck so much that we’ve made entire disciplines around trying to design better ones (BDD, DDD, TDD, etc). There are lots of reasons for this, but there are a few that I really want to focus on.

Security Issue: Combining Bcrypt With Other Hash Functions

The other day, I was directed at an interesting question on StackOverflow asking if password_verify() was safe against DoS attacks using extremely long passwords. Many hashing algorithms depend on the amount of data fed into them, which affects their runtime. This can lead to a DoS attack where an attacker can provide an exceedingly long password and tie up computer resources. It’s a really good question to ask of Bcrypt (and password_hash). As you may know, Bcrypt is limited to 72 character passwords. So on the surface it looks like it shouldn’t be vulnerable. But I chose to dig in further to be sure. What I found surprised me.

Being A Responsible Developer

Last night, I was listening to the combined DevHell and PHPTownHall Mashup podcast recording, listening to them discuss a topic I talked about in my last blog post. While they definitely understood my points, they for the most part disagreed with me (there was some contention in the discussion though). I don’t mind that they disagreed, but I was rather taken aback by their justification. Let me explain…

On PHP Version Requirements

I learned something rather disturbing yesterday. CodeIgniter 3.0 will support PHP 5.2. To put that in context, there hasn’t been a supported or secure version of PHP 5.2 since January, 2011. That’s nearly 4 years. To me, that’s beyond irresponsible… It’s negligent… So I tweeted about it (not mentioning the project to give them the chance to realize what the problem was):

I received a bunch of replies. Many people thought I was talking about WordPress. I wasn’t, but the same thing does apply to the project. Most people agreed with me, saying that not targeting 5.4 or higher is bad. But some disagreed. Some disagreed strongly. So, I want to talk about that.

A Point On MVC And Architecture

Last week I published a post called Alternatives To MVC. In it, I described some alternatives to MVC and why they all suck as application architectures (or more specifically, are not application architectures). I left a pretty big teaser at the end towards a next post. Well, I’m still working on it. It’s a lot bigger job than I realized. But I did want to make a comment on a comment that was left on the last post.

A Beginner's Guide To MVC For The Web

There are a bunch of guides out there that claim to be a guide to MVC. It’s almost like writing your own framework in that it’s “one of those things” that everyone does. I realized that I never wrote my “beginners guide to MVC”. So I’ve decided to do exactly that. Here’s my “beginners guide to MVC for the web”:

Foundations Of OO Design

It’s quite easy to mix up terminology and talk about making “easy” systems and “simple” ones. But in reality, they are completely different measures, and how we design and architect systems will depend strongly on our goals. By differentiating Simple from Easy, Complex from Hard, we can start to talk about the tradeoffs that designs can give us. And we can then start making better designs.