Last week, I wrote A Beginner’s Guide To MVC For The Web. In it, I described some of the problems with both the MVC pattern and the conceptual “MVC” that frameworks use. But what I didn’t do is describe better ways. I didn’t describe any of the alternatives. So let’s do that. Let’s talk about some of the alternatives to MVC…

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.

To some of you, this may not be new. But to many of the people preaching “Agile Software Development”, Agile is not what you think it is. Let me say that again, because it’s important: You’re Doing Agile Wrong.

There has been a lot of talk about typing in PHP lately. There are a couple of popular proposals for how to clean up PHP’s APIs to be simpler. Most of them involve changing PHP’s type system at a very fundamental level. So I thought it would be a good idea to talk about that. What goes into a type?

There is a lesson that I was taught many years ago that I think everybody who contributes to Open Source projects should learn. Back when I was a volunteer firefighter, I had a rather interesting conversation with one of our ex-chiefs. Let’s teleport back to when I was 21 years old.

As many of you likely know, I have a “thing” for password storage. I don’t know what it is about it, but it fascinates me. So I try to keep up as best as I can on the latest trends. In the past few years, we’ve seen the rise of a new algorithm called scrypt (it’s 5 years old actually). It’s gaining more and more adoption. But I don’t recommend its use in production systems for password storage. Let me explain why:

This is the fourth post in my “Beyond” series. The previous three posts focused on re-imagining OOP and questioning some of the core beliefs that we have come to take for granted. This one is going to be slightly different, in that I want to talk about another angle of writing code: the process itself. We always talk about how code should be clean, but how do you write clean code?

In the last post Beyond Inheritance, we talked about looking past “types” and reasoning about objects differently. The conclusion was that inheritance wasn’t necessary for OOP, and often results in more problems than it solves. Well, let’s go beyond that and explore more of what will come from treating objects as containers of behavior. Let’s look at what this means for various kinds of classes:

In my last post, I talked about revisiting the concept of Design Patterns and questioned how useful it is to “learn” them. The conclusion that I came to was that you are better served by focusing on how objects communicate rather than traditional patterns. Well, that’s not the only “traditional concept” that I think we should move beyond. So, let’s talk about inheritance…

Many people teach design patterns as a fundamental step to Object Oriented Programming. They are so universally seen as important that almost every single conference that I have been to has had at least one talk about them. They are quite often used as interview questions to test a candidate’s OOP knowledge. However, just like inheritance, they are not needed for OOP. And just like inheritance, they are a distraction rather than a foundation. Instead of focusing on patterns, I suggest focusing on learning about abstraction and communication. Why? Let’s talk it out…