DrBacchus' Journal

I saw Yoav's blog entry on Tidy and for a brief moment, in the first paragraph, thought that there was actually a phptidy utility. Alas, it was not to be.

Perl has had perltidy for some time, and, as I understand, it's a pretty hard thing to do. But I keep hoping that someone will do the same thing for PHP.

Meanwhile, fortunately, php syntax is enough like perl that I can use perltidy to reformat php code about half the time (I have a vim macro that runs perltidy on the selected block of text) - the other half, it complains about syntax errors and screws things up pretty well.

After many years of saying "I really should take a look at CakePHP", I'm finally doing something useful in it. And it's marvelous.

What's fascinating to me about shiny new technology like this (new to me, that is) is that I'm almost always reluctant to get started, and I'm almost always thrust into it by a co-worker who says that it's the way to go, and starts doing stuff in it. This was the case with Apache, Perl, mod_perl, POE, PHP, AJAX, and now Cake.

Also, as usual, I am incapable of learning anything in it until I'm doing an actual useful project in it. I can't just work through the tutorial, or make up a project. It has to be something that's important to me, and is at least a little interesting.

And, as usual, my reaction here is, why the heck didn't I jump into this years ago. Can you imagine the time and pain it would have saved me?

For those of you who don't know, CakePHP is an MVC framework. Which is to say, it's just like Ruby on Rails, or Catalyst, or any of a dozen other frameworks out there.

And for those of you who aren't geeks, when we say "framework" it means "someone else did the boring work for me so that I can focus on the interesting part of the project."

As it turns out, with most web applications, 90% of the work is doing the stuff that you've already done before on every other web application that you've ever written. Database connections, getting data, creating data, updating data, deleting data, asking the user if they're sure they want to delete the data, etc, etc, etc. Very boring. Cake (and other frameworks) do that stuff for you, so that you can focus on the actual business logic of the application - that is, the things that make this web app different from the last 28 that you've already written.

We use Plug n Pay at $work to conduct our financial transactions. It's a great service, but the example code that they provide for PHP and Perl developers leaves something to be desired.

I spoke with a tech support guy there, and, while he was helpful, and clearly very knowledgeable, I found that we differed significantly on a particular point of philosophy. He seemed to be somewhat perplexed as to why I would want a full OO interface to their API, because, as he said, any PHP programmer worth their salt can take the API documentation and write code that sends arguments via Curl, or PHP sockets, or whatever, and get useful results from it.

To this end, they offer one PHP file, containing a partial implementation of one of the API methods, as an example of how one might do this. The example manually builds a query string, rather than using http_build_query, and manually splits the return value, rather than using parse_str - not crimes in themselves, but it seems that ecommerce code should be held to higher standards than this.

While I don't disagree that a good programmer could indeed do this, I disagree that any would *want* to. Good code is reusable code. Having thousands of programmers writing exactly the same code, and having many of them, no doubt, doing it really badly and insecurely, is not in the best interests of anyone - the programmers themselves, the companies they work for, or even Plug n Pay (or any other financial vendor). They are wasting thousands of hours, and they are very probably writing code that is insecure, confusing, poorly documented, and, in many cases, just plain wrong.

Having a complete API implementation, and providing that to customers, is a service to everyone. It saves my time as a programmer, it saves time and resources on tech support, and it results in more secure code that is guaranteed to do the right thing every time.

Now, the folks at PnP offered to audit my code and possibly offer it for download on their site, given certain licensing requirements, and I may take them up on that. I haven't decided yet. But, to be honest, I find their attitude about the whole thing to be quite at odds with my view of how software development should work. Encouraging every individual programmer to find their own way is not the way to improve the overall security stance of ecommerce websites. In fact, I would say that the huge daily number of compromised ecommerce websites is a direct result of this stance.

So, anyways, to this end, I offer my starter implementation of a full PHP API for PnP. So far, it's incomplete, but exposes the most frequently used methods, and does it in such a way that it's pretty difficult to get it wrong. Of course, you need a PlugNPay account to use this, but one hopes that if you found this article by a Google search, this is the solution you're looking for.

Now, it's possible that I'm the only person that cares about this kind of thing, but if you're interested in receiving updates of this code, or possibly in participating in the ongoing development of this code, please let me know, and we'll work something out. Collaborative development of reusable code seems like the only sane way to implement a financial transaction codebase.

Jim blogged about the PHP credits list, and so I took a look. I was amazed to notice that of all the people listed, I know at least half of them, and have met most of the others. I've been very lucky to be in the right place at the right time, and meet some amazing people, and get associated with a pretty amazing organization, and by extension, a bunch of others.

In the early days, when the term Open Source wasn't quite as well known as it is now, I managed to meet a significant number of the folks responsible for Perl, and become friends with several of them. A few years later I started spending more time with Apache than with Perl, and that's developed into speaking opportunities, books, interesting projects - but most importantly and lastingly, a bunch of friends.

Every now and then, I get a glimpse of just how lucky I've been over the last ten years, and the truly astonishing opportunities that have been available to me by virtue just being in the right place, and being willing to volunteer a little of my time.

I've been less involved for the last year, since there's somewhere that my attention has needed to be focused. I'm gradually getting back into spending time on Apache things, but it's given me some time to think about where I want to spend the few cycles that I have, and I expect that my involvement will be a little different from what it's been in the past.

But time will tell.

Add another one to the list of things that I've put off for a long time, only to realize that they're simple to do, and have a great pay-off.

Today I installed and enabled APC, which immediately doubled the speed of my PHP applications. And, more importantly, the load on the server immediately dropped by a factor of 10.

I understand that there are other php caching accelerating thingies out there, and I expect that everyone has their opinion of which one is the best. But I'm very impressed with APC.