January Meeting

I introduced the new PUG site…now powered by the geeklog site-in-a-can solution. I wanted to discuss some of it’s internals, available modules, etc…but instead just rambled a bit. 😉 There is already an intro article out there, so read that for more info if interested. After the meeting, Doug pointed out that codingtheweb.com has a portal-portal with RSS/RDF feeds. And, oh yes…they have a PHP feed (which I think is just stuff with the letters PHP in them). I added the RDF Portal box to the PUG site. Enjoy!

Everyone is invited to write articles/comments/etc for our PUG…you can even submit one anonymously!

Other Topics

We had a general Q/A section and discussed things such as our favorite editors (VIM, komodo, ftpedit, and dreamweaver MX to name a few), some of PHP 4.3’s new features, using GD and ionCube’s PHPAccelerator.

Image_Transform

In answering a question, I introduced Image_Transform…a PEAR class for abstracting various image manipulation libraries. I have used it to scale images down on the fly but without the headaches involved with different GD versions or pixel math manipulation.

This abstract factory style library provides member functions such as: resize, scale, scale to a max height/width, add Text and others. Having this in an abstraction layer allows you to switch libraries out depending on what is available on you system or based on what performs the best for your needs.

For example, I had always assumed that GD’s imageCopyResampled would be the fastest way to size images on the fly. As it turns out, I actually got better performance letting Image_Transform use the mageMagik command line utilities.

We all know that PHP is bashed by “other” developers because a PHP script is usually compiled every time before it is run. When using single scripts or even small libraries, this compilation takes so little time it goes unnoticed. However, as you site grows, frameworks are implemented and your compile times start getting up there into the .5-.8 second range…you might start thinking that you need to invest in more hardware. This just usually isn’t the case.

Sometimes, all you really need is something that will cache that compiled byte code. There are several alternatives available, such as the ones from Zend. However, as money is sometimes hard to find we have to go in search of other solutions. Enter ionCube and their PHP Accelerator

There are some restrictions: It requires PHP 4.0.6 or higher (and you should too) and Apache 1.x in *nix, but if that is your setup…then enjoy!

It also may not play with other Zend/PHP modules. For instance, the Komodo debugger did not work when I used it in the same server as PHPA. No big….I doubt that you will want to use it on a dev machine anyway as it can lead to a little “weirdness”. For instance, say you had an abstract class called Fruit and it is in a file called fruit.inc. Then you have a class called Apple which includes fruit.inc and extends Fruit. Now, all is good and the cache works great. Until, say, you add a member function to your base class: Fruit. PHPA will notice that THAT file has changed, and will recompile it. However, the functionality will not propagate down to the Apple class. Apple will still be the compiled version from before the functionality was added to it’s parent.

If this doesn’t make sence…then you probably won’t have a problem with it anyway. 😉

While I didn’t bother to write down exact numbers, when I was implementing this for our framework I noticed response times (from start of request to page render, using the advanced “time lynx -dump www.yourwebsite.com” command) were easily cut in half. Of course, I have written a fairly sloppy framework built on top of another big framework…but hey…like I said: in half. 😉

Behind the scenes it uses apache shared memory segments and a directory on your filesystem to efficiently cache your PHP byte code. If your code wants a pick-me-up…this might be an afternoon alternative to a major rewriting effort.