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?

PHP, minimalism and Occam's razor

Check out my latest blog about PHP, minimalism and Occam's razor at Ibuildings. Today onwards, I'll post longer, more formal posts on Ibuildings' blog while keeping the shorter, more frequent and less formal ones here.

Google Developer Day London 2008

I was at Google Developer Day last Tuesday. The highlight for me was definitely Android and Gears. For Android, Mike Jennings showed-off the yet-to-be-launched Android phone to my amazement, and I am pretty much sold. Also did some code-reading at the Gears CodeLab. I hadn't touched Gears for a while since it was 'launched' sometime ago and thought the session could get me in sync and it certainly did. Got some ideas for some fun things to do with the API and took a photo with Google's London Gears (Mobile) team.

On Google (and) Maps

Google always leave us with little room to wonder why it is so much loved by developers like me. At the moment at least, I guess the model of success for a software company is so much an anti-theses of Gates' original position on evolving software with retail economics in his famous 1981 letter.

Google changed that. So, now we have a company that buys expensive software "by the company" and releases its intellectual property to the public to use, for free. Man, it feels like the scene from Last Samurai where Emperor Meiji, maddened with Omura's monopolising ways, confisticate his estates and fortunes and gives it to the people. Except this time, Omura is obliging.

Liberty, at last, sweet liberty. I got a taste when I was tasked to map offices for presentment in CDs, websites etc. This could be an irritable task, drawing maps, directions, adding on changes (graphically by the layers, if you know what I mean). All sorts of unelegant mouse manipulation involved.. With Google Maps API, heh, we have Semantics and as such, we get closer to reality and thus easier representation. Task completed, with code, not pixels,
less memory used, less time used, more flexibility, the list goes on. Getting it right is always good, or so it seems at least to me.

Here, we see how the creative gale of destruction that is Google gets cracking. Now, we only need a:

var currentVehicleLoc = new GMarker(new GLatLng($lat, $long));

to indicate a position in a clouded map. Imagine what this can do. I think the benefits of proprietary GPS locationing systems gets immediately obsoleted. Here, we have a simpler way of locationing in a common sharable, secure-able realm that is better than the raster or what-not proprietary systems of thousands of Omura-like companies, now gone to waste. Art is futile.

Open source Openspace

Openspace had finally reached a stage of maturity to be released as some sort of alpha-release open source. Justifications:

1. It had been used as the operating framework for up to 5 major projects to-date.
2. It had also proven its use in the fast creation of various widgets and tools. (The To-Do list seems like a popular choice)
3. A pool of developers had emerged to pick it up quite easily and quickly
4. At least a team of developers within a company with established commercial projects using Openspace had committed to open source contribution

Once the code had been cleaned-up, expect it to be available on Google Projects via SVN. Since this is starting up, we would welcome all forms of participatory help in coding, design and etc. The next stage of development involves things like genericisation (especially DB) and more semantics / ontological features. Would certainly not like to reinvent the wheel, will be glad to merge or join any other project teams if we're heading towards the same direction. Do drop me a mail too for such.

Gambit

The Gambit feature for Openspace is ready! Inspired by Automator (for Macs), Scheduler (for Windows) and the unix cron, it is a really useful tool to help automate tasks based on a programmable Action -> Reaction rule. E.g. When the clock strikes 10, throw out the garbage, you get what I mean. There are a range of other Actions (something like a listener), such as OnAdminLogon, OnLogOff and etc.