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…

As you can probably tell, the title of this post is based off the common saying “The Grass Is Always Greener On The Other Side.” I’ve always been amazed by this saying, because while we can find countless cases of it being true, we can also find countless cases of it being completely and utterly false. Take smart-phones for instance. People are quite dogmatic about which they choose, and they believe that the grass is definitely not greener. This is something that’s bothered me for a while. But yesterday, I think I’ve made a cognitive leap towards understanding why it works for some things and not others…

In response to last week’s ask for questions, I received a number of questions that I’d like to address. Since it would only do the question justice to have a dedicated post for each question. So I’m going to try to do one post per week on a user-submitted question (probably on Wednesday, but no promises). This week’s question is a rather abstract one:

I’ve been learning a lot about service layers and managers and domain objects and one thing really confuses me. Why is MySQL being turned into a non-relational database? It has so much power, so much flexibility, but it seems like many programmers want to abstract it to the point of near uselessness.

Now, there are so many facets to that question that it’s hard to find a starting point. But let’s try:

I was asked an interesting question via email yesterday. The question is fairly simple. The answer, not so much… So, rather than reply in an email, I figured that I’d write a post about it instead. The question, simply stated, is: When comparing a float to an integer using ==, where does the conversion happen?

So, let’s begin…

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.

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.

Here are the slides from my presentation at NYPHP on STUPID vs SOLID development. Click through to see the slides.

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?

The other day I had read an interesting post by 37 Signals entitled Why We Don’t Hire Programmers Based On Puzzles, API Quizzes, Math Riddles or Other Parlor Tricks (say that 10 times fast). Then I was pointed to another article by C for Coding entitled Interview Programming Problems Done Right. That got me thinking about the interview techniques that I’ve used at my current and prior jobs. It’s a different style than either of those two posts, so I figured it was worth talking about.