Lately I’ve been playing around with some functional languages and concepts. I have found that some of these concepts are directly applicable in the OOP code that I’ve been writing. One of those concepts that I think is worth talking about is the Monad. This is something that every functional developer tries to write a tutorial on, because it’s such a cool but hard to grasp concept. This post is not really going to be a Monad tutorial per se, but more of a post about bringing the general concept to OOP, and what that looks like.

Yes, you read that right. If your project aims to provide backwards compatibility as a primary goal, you’re a sucker. Tons of popular software projects from PHP to Microsoft Windows have stated goals of providing Backwards Compatibility between releases. And yes, I am here to say that they are doing it wrong.

I first came across the concept of a Promise about 3 years ago. At the time I was working with jQuery and was rather put off by the concept. It wasn’t that it wasn’t useful, I just didn’t understand it. Then, about a year ago the concept finally “clicked”… I refactored some existing applications and the reduction in code and simplicity of it all was breathtaking. But I never really appreciated the true power until I used them in PHP…

I’ve been playing around with tempting engines a lot lately. For a recent project, I needed the ability to re-use the same template set in both JS and PHP (coupled with the History API, providing seamless dynamic behavior, yet still having raw content pages). Realistically today, there’s only one choice for that sort of requirement: Mustache. I’ve learned a lot while playing with Mustache, and it’s really changed my entire viewpoint on presentation layer construction.

Every developer who studies computer science (and most who haven’t) has heard the phrase “Garbage In, Garbage Out“ before. It’s such a logical concept that it’s almost beyond refuting. Almost. While the phrase still definitely holds true for some situations, it doesn’t hold for most. How can such a logical and straight forward saying lead us down the wrong path?

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:

The concept of generators was recently proposed for addition in PHP’s core (Possibly for 5.5.0). While I believe that this is a great tool, it appears that many PHP developers aren’t familiar with the concept of generators. So I thought I would take a little time and explain some of how it works, and how it can be used to greatly simplify code.

One of the most powerful changes that PHP5 brought to the table was the ability to autoload classes. It’s such a useful tool that it was the first standard the FIG group put forth. Almost every single major PHP framework and library uses an autoloader to include its classes. It always felt somewhat wrong to me to autoload in production at runtime. So I decided to give it a bit more exporation…

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…