When was the last time you were silly? Well, more specifically, when was the last time that you wrote code that was downright silly? I’m not talking about writing code that’s dirty, or hacking something together. I’m talking about writing code that you know before writing won’t work, or is wrong or is just plain silly… I’m talking about the kind of code that you think that if you show other developers, they’ll just sit back and go "Why the #@$% would you do that in the first place?"… Well, I do it quite often, and let me tell you why you should do it more as well!
Brandon Savage has recently posted two blog posts portraying his opinion that using private visibility on class methods can be considered harmful in a lot of situations. While I understand the point he is trying to make, I can’t say that I agree with it. I do like private visibility and think that it’s actually under-used in a lot of software. But it’s not because I think Brandon is wrong…
So, for the past few days I’ve been talking about a secret project that I’ve been working on. Well, today I’m pleased to announce the project. I’ve been working on starting a series of YouTube videos about programming. The first of these videos is about Paradigms (Procedural, OOP, Functional). Plenty of future ones are planned, but the topics, order and even if they happen is completely up to you! I want your feedback on the concept. Is it something worth pursuing? Any topics you’d like to see? Any other comments about the concept? You can reply to this post, or to the video itself. So, without further adue, here’s the video:
The other day, PHP 5.5 Alpha 1 was released to the public for the first round of testing the new features that are coming out. One of those new features is the Simplified Password Hashing API that I proposed (and was accepted). I have received a lot of feedback and criticism of the new API in the months since it’s been committed. I figured now that Alpha 1 is out and people can play with it, I should respond to some of those items, and give a little bit more insight into why it was built the way it was…
Yesterday, I got in an interesting conversation on twitter about object scopes and what constitutes a global scope. The discussion started around a piece of code that I stumbled upon from Fuel 2.0. I am a firm believer that service containers are not a form of Dependency Injection, and are only slightly better than global variables. That led me to make a few comments that elicited a reply from two Fuel developers. That led to a rather interesting debate that just couldn’t fit into 140 characters… So I’m going to go into topics that are tightly related: variable scoping and service locators.
If you’ve been following me for a while, you’ve likely heard me use the term “N-Tier Architecture” before. Today’s question comes from Arno. He basically asked “What is this N-Tier Architecture thing you keep talking about?”… So, to answer his question, a N-Tier Architecture is one that uses more than one tier. Of course there’s more to it than that…
In this day in age, it seems that the community trend is completely and unequivocally trending towards the use of web application frameworks. So much so that the defacto first comment to someone asking how to do something seems to be “Just use a framework, and it’ll solve the problem for you.” While I completely understand why this is the case, I can’t say that I agree with it. And while I do believe that frameworks serve a purpose, I think that they are vastly over-used. Let me explain why…
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…
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.