The Gmagick, Amazon, Windows, techPortal, php|architect and Zend DevZone Hamper Blog

It's been a while since I last blogged so I am packing it all up with a tags-like title for a change.

Over the past few months, there had been several Gmagick releases that incorporate a few fixes and some new features. Check out the release notes on PECL for more info. A big thank you to all that had tried it out and had contributed fixes.

For Windows users, Gmagick is now available for Windows, grab the DLLs from Mikko's valokuva.

On the evangelism side of things, I wrote about using Gmagick along with Amazon's Elastic MapReduce cloud service to do color searching. This appears on techPortal. Yes, it is indeed quite long, according to Cal Evans. It showcases how Amazon's cloud allows developers to be flexible with the precision of both the pixel scope for color quantization and the proximity of colors to search within a 3D colorspace. This burrowing into Elastic MapReduce is part of some other cloud spotting that I had been enjoying while working on an upcoming book with Ivo Jansch.

That's not all!(Intercom speakers) There's an article on Gmagick in the October issue of php|architect as well. In this article, elephpant visits the museum. Curious? Check out the October issue!

For those that are interested in more Gmagick related documentation (besides the manual), Vikram wrote a nice and rather comprehensive tutorial on Zend Developer Zone.

That's about it now.

A quick look at the Tokyo Tyrant extension for PHP

Here's a quick, rough look at the speed of the Tokyo Tyrant extension for PHP released by Mikko 2 days ago. I am using it as an on-memory hash. Profiling done with xdebug on PHP 5.3.0:

Here's the collateral userspace costs of an alternative PHP implementation by Bertrand Mansion (dependent on the sockets extension to PHP):

The Gmagick Extension

I am excited to announce the release of the Gmagick PHP extension, which I ported from Imagick along with Mikko Koppanen, one of the Imagick author who got me to do the extension and guided me along the way.

The extension seeks to make the image processing capability of GraphicsMagick accessible from PHP. GraphicsMagick is forked from version 5.5.2 of ImageMagick and had since developed with important differences and improvements (for more details, see GraphicsMagick's website).

In terms of Gmagick and Imagick, we try to keep the method interface similar so existing Imagick users will find converting to Gmagick a breeze. One major difference however, is that most of the mutator methods in Gmagick are chainable.

We'll leave you to decide which extension is more suitable for your needs. A high level difference that we keep in mind when developing Gmagick is that Imagick's feature set is more extensive and powerful, whereas Gmagick should be simpler and more efficient (see benchmarks).

On techPortal: PHP and the Cloud

I wrote about using Amazon's cloud services from a PHP perspective on Ibuilding's techPortal. Do check it out! I think Cal Evans and the Ibuildings gang has something special going on, and there is a growing list of other really interesting articles and tutorials as well.

What excites me most about Amazon's cloud is the huge computing resource that it makes accessible to practically anyone. So that ceases to be an excuse nor a worry when innovating. There are also a bunch of challenges that I had faced in the past that could benefit from the presence of such easily accessible utility. Really, I could had been more relaxed during month-ends in a previous project when processing and requests spikes due to heavy reporting while operations goes into overdrive trying to hit closure targets.

Another good use of it is to tackle archival and document sharing requirements for legal and billing purposes (the 7 year burden of records). Accountants will love the variable cost conversion effect of cloud pricing and I can already see sales grinning from an easier, more meaningful sell for such 'unavoidable value-add'.

Session-based object instantiation with memcached

I can't help but ponder every so often the amount of objects that gets instantiated for a typical request when a framework-based application gets large and saturated. At runtime, a script sets up everything that it requires, allocating memory for variables and objects and all these gets torn down upon end of execution. There is no persistency beyond the notion of a session. And so a user goes about requesting for login.php and subsequently requests for say, MenuController.php in essence runs two disparate scripts without PHP bothering if they are from the same chap other than the fact that the session remains similar alongside any other information that might be stored in the session. This implies that an object instantiated upon login.php will no longer be present upon MenuController.php and needs to be instantiated again, that is unless it is stored in the session (and the code explicitly uses the object in session). So, there will be lots of object construction and destruction going on while the user of a PHP web app goes about her business dealing with the same app. Here's where object caching with memcached helps, but I thought another paradigm on top of it might be useful or feasible:

class SessionObjectSingleton
{
public static function getInstance($class)
{
if (!isset($_SESSION[$class])) {
    $_SESSION[$class] = new $class;
}
return $_SESSION[$class];
}
}

So, everytime an object needs to be instantiated, we do this$newObj = SessionObjectFactory::getInstance("Some_class_name"); instead of $newObj = new Some_class_name;. Typical of a singleton but using a session as store, we get an object that persists along with the session that is specific to the session. Hence, the object can be user specific and still persist. Garbage collection is inherently managed when session_destroy() is called as usual. Furthermore, memcache can be used as the session handler, speeding up access to instantiated objects. (For more information on doing this, see phpslacker's session-clustering with memcache). Anyway, the objective of the whole shebang is to minimise resource use in a situation where objects are instantiated exhuberently. This paradigm has the utter inconvenience of having to instantiate object without the perennial new keyword, but heck other solutions seems to require expressive effort as well. It is also more useful for applications that needs to instantiate a lot of complex objects and maintain sessions that involve heavy state switching (e.g. back-end CMS-es). It is of course not relevant for applications that shouldn't be bothered with sessions in the first place. What do you think?