@TheKeyboard Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.

Most developers who have worked with PHP for any significant period of time have heard of the LAMP application stack. Linux, Apache, MySQL and PHP. This is probably the most common PHP application configuration out there, and I’ve been giving application stacks a lot of thought these days for a variety of reasons. First of all, I’m giving a talk on application deployment at Open Web Vancouver, and the stack plays a big role in that. Secondly, I’m always looking at new technologies and trying to figure out where they might fit in.

Thirdly, there seems to be a trend towards providing “drop-in-place” PHP stacks for developers trying to figure out things locally. I’m talking about things like MAMP and Wampserver.

So the next thing I’ve been wondering about is about what future PHP stacks will look like, at least on the open source side of things. Have we gotten to the point where this is as good as it gets? I know for my own personal stuff, I’ve started moving away from the AMP part of LAMP, instead using Postgres for database stuff and nginx as my webserver. So, what is that now? LNPP? That doesn’t roll off the tongue as nicely as LAMP.

Also, are we limiting ourselves in the description of a stack by just going with PHP as part of LAMP? With the rise of Javascript on the client-side and the increasing use of frameworks by developers (I’m *not* getting into that MVC argument again) do they need to be considered as part of the stack now?

So, my question to my readers is this: what do you see as the future stack for PHP? Is LAMP the combination likely to continue to see the most usage? To spark things off, here are some of the PHP stacks I’ve been working with lately:

• CakePHP + PHP + Apache2 + Postgres + Gentoo Linux
• jQuery + Code Igniter + PHP + Apache2 + (eXist + Postgres) + Debian Linux
• jQuery + CakePHP + PHP + MySQL + nginx + Gentoo Linux

Let me know your thoughts about the PHP application stack in the comments. I mean, are we going to see something like an application server for PHP (like Mongrel for Ruby folks) or is mod_php or FastCGI (for the nginx + lighttpd folks) as good as it’s gonna get?

I like to check out the programming section on Reddit on a regular basis because it usually contains some interesting links. Yesterday I came across a link that discussed the fallout surround a presentation at phplondon08 where panelists on a discussion of frameworks got heckled but some guy claiming to be an expert on what a real MVC framework is.

All major Rails clone PHP frameworks that exist on the market today are a complete and utter failure. All of them call themselves MVC frameworks and none of them implement actual MVC. In fact, some of the worst ones merely resemble MVC, and have no right whatsoever to be called frameworks. Whatever benefits of sexy ORMs and flexible build systems and scaffolding and other secondary tools these frameworks have are nullified by the fact that using them results in architectural chaos which is no better than your usual spaghetti code. This is because the people who wrote Rails didn’t bother to understand MVC, and the PHP amateurs who were excited about the idea of getting done more in less time blindly tried to clone Rails into PHP and in so doing not only replicated the stupidity of Rails into PHP but also multiplied it by their own incompetence and PHP’s shortcomings as a language and a platform.

No, tell us how you really feel about it.

Anyhow, this guy apparently works for the Agavi project, a (wait for it) MVC framework written in PHP as an “evangelist”. Well, he certainly talks like you would expect an evangelist too.

The comments for that post are really interesting too, as people take their usual swipes at PHP, and CakePHP, and the Symfony guys come out in droves to talk up Symfony, and on and on it goes. Sadly, this is not a unique occurance on the web.

So, back to the topic of the post. Is this guy right? Is *nobody* except Agavi doing it right on the PHP side of things? I took a peek at their documentation. Lots of statements about what a framework should and shouldn’t do.

(Author’s note 03/10/08: removed code example as, well, it’s not really relevant to the discussion, other than making me giggle about mixing business logic with presentation logic)

Digging through the documentation some more, it’s quite dry. Short and sweet, not a lot of tips on building an Agavi app from scratch. Again, to be fair, that might not be the point of the documentation. But it’s approach is very, *very* different from the “Rails way” that CakePHP has been following. Before you flame, there is nothing wrong with the “Rails way” because, if nothing else, it has forced developers to crank their skills up a notch and actually *think* about what they are building.

I knew one of the original developers of Mojavi (of which Agavi is a fork) and he was a really smart guy (Hi Shawn!). My early forays into framework use was with Mojavi, when trying to convince a previous employer that we needed to rewrite this monster PHP application with Mojavi so we could get things like a private branding version of the site done a lot easier.

When I compare this to Cake, they are as different as night and day. Agavi (and Mojavi) are heavily configuration-oriented (XML *everywhere* for config files), while Cake uses conventions to try and speed things up. But the real truth is this: they are both trying to separate your business logic and your presentation logic to make things easier for the poor saps who have to build these applications.

Our lovely heckler has missed the forest for the trees, as far as I’m concerned. It’s like complaining that you can’t call it a forest because the trees aren’t growing straight up and down, but tend to branch out in different directions. They’re still trees, right?

Frameworks are designed to try and help you to get things done faster *and* to organize your code in a much more consistent manner. Cake uses the Model-view-controller design pattern, and I think that the quote below makes it clear that Cake is doing it the right way:

Model-view-controller (MVC) is an architectural pattern, which at the same time is also a Multitier architecture, used in software engineering. In complex computer applications that present a large amount of data to the user, a developer often wishes to separate data (model) and user interface (view) concerns, so that changes to the user interface will not affect data handling, and that the data can be reorganized without changing the user interface. The model-view-controller solves this problem by decoupling data access and business logic from data presentation and user interaction, by introducing an intermediate component: the controller.

If you are trying to tell me that CakePHP does not follow that practice, then I am calling you a fucking idiot who is more interested in pedantic minutiae than understanding that there is more than one way to implement MVC.

A work project is getting close to 0.1 status. Pretty underwhelming, I know. One of the last 'milestones' for 0.1 is taking these wonderful XML documents that my web app creates (and stores in eXist and sends them to an internal web service that reads in the XML and breaks it apart for use by a wide variety of other company applications. This web service will accept documents via an HTTP PUT (you know, GET, POST and it's neglected siblings PUT and DELETE) so I dug around a bit on the web (ignoring one cranky co-worker's complaints that real programmers read RFC's, or at least *know* what an RFC is) and put together some code

The only tricky thing here really is the use of the end function to grab that last match of the status codes. I got the code for doing the preg_match from this site and it seems to work just fine. The reason to use end(...) as far as I can tell is to make sure that I only get the last match of the group. Neat little trick and the link I posted demonstrates it.

I'm also quite proud that it's cURL free, as cURL seems to be the first option that most people use when doing this kind of thing. There is some existing code that is using cURL that I *might* refactor to use the streams-driven stuff that I've been playing with.

While speaking with nate last night via IM, he told me about the latest set of changes for CakePHP 1.2. There is simply just too much to mention, so I suggest heading on over to the brand-spanking-new CakePHP home page and checking out the changelog. There's a lot in there, but take the time to go through it. Besides, you might find that a particular bug that had been bothering you has been fixed.

My own modest contribution to the latest release was contributing some work in the 'bake' utility to allow you to select what database configuration you wanted to use (it was hard-coded before), and allowing you to bake a plugin (which is sort of like a stand-alone module within an application. Yes, there were a few tweaks afterwards by gwoo but he told me (or maybe lied to me to soothe my ego) that a lot of my code was still in there.

So, CakePHP 1.2 stable looks like it's getting closer and closer, so don't be afraid to move from 1.1 to 1.2. The improvements are worth it as 1.2.x is probably the most stable piece of "alpha" or "beta" software I've come across.

Since the summer, something had been bothering me about PHP. I couldn't put my finger on it but over the holidays I finally figured out what was wrong. After ten years of working with PHP, I'm bored with it. Every professional programming job I've ever had has involved PHP as the main language, with a smattering of things like SQL, Perl, Ruby and Javascript. But it's always PHP at the core.

So what is there left for me to do with PHP? I'm not about to write my own PHP framework as I have one I already like, one that I use for my simulation baseball league's web site. I'm not a C programmer, so diving into the internals of PHP to contribute that way is a no go. No, it's time to put PHP aside (so to speak) and pour my energies into something else.

A while back I tried the Rails thing. I liked it...because it was so different from PHP. Ruby has such elegant syntax, reading like English in many ways. I even got asked to create a training course for Ruby on Rails, but never got far with it (sorry Marco). Once I started poking around more about Rails, I started to see things that made me uneasy about it: issues about performance in high-traffic environments, the attitude of some of the more senior "core" guys in Rails, and the zealotry displayed by users of it.

Slam PHP all you want for it's syntax ($object->chaining->looks->weird()), it's inconsistency in function parameter order, the still-ongoing debate about how to implement namespaces, and the combo of powerful functionality combined with a low barrier of entry (thereby infuriating programming snobs). But it gets shit done, plain and simple. That's how Rasmus Lerdorf started off using PHP, that's how it will always be. Elegance in code and proper programming techniques are the domain of the developer, not the language in my not-so-humble opinion.

Sure, Ruby is nice and Rails has all those cool magic functions but some stuff I read by Zed Shaw (the creator of Mongrel put into words a lot of what I had felt about Rails: just not for me, I guess.

So what's left? Not gonna go the Java route: too much pain and suffering lies down that path. So, I'm left looking at a language that is rock solid, has a great object model, has a good web application framework to help me get up to speed and lots and lots and LOTS of great documentation and tutorials: Python.

I won't be giving up getting PAID to do PHP code any time soon because I have a great job with a great bunch of guys, and I get to work from home. But I just feel it's time to focus my energies on something else. Python is very similar to Ruby, and let's be honest here: I've got enough programming experience that there shouldn't be much of a learning curve for me to figure out Python. Python code just looks nice and clean, less writing to get more done. That's what I'm really looking for these days.

The simball web site continues to grow and get new features, so I will be leveraging CakePHP to the hilt in that respect. It's an exciting time for CakePHP as they are heading towards 1.2 and preparing for 2.0. But I am not sure what my contribution to the project will be any more, which hasn't been much lately but I am interested in helping push the CLI tools forward as not only can they help me, they can help other developers as well. But it is time for a change. Maybe one of these days I find a job programming in Python, or even manage to push Python in through the back door where I currently work. But the time is absolutely right for me to start learning Python and make it a tool I want to use on a regular basis instead of it continually being on my list of "things to do when I feel up to it".

I've got my copy of "Dive Into Python" in PDF, been going through the Python tutorials (wow, the interactive interpreter is great) and getting ready to bust out a Django install. But make no mistake: PHP pays the bills, but it's time to start using other people's tools to get the job done. Time to quit fooling myself that I'm going to make some sort of earth-shattering contribution to PHP, and save my brainpower for learning Python the way I've learned PHP.

Wish me luck!