On the Hack blog there's a new post talking about async, a feature in Hack that allows for code to "cooperatively multitask". This gives the language a way to keep moving on in the execution without having to wait for things like database queries or remote file fetches to finish.

This is somewhat similar to threading, in that multiple code paths are executed in parallel, however it avoids the lock contention issues common to multithreaded code by only actually executing one section at any given moment. “What’s the use of that?”, I hear you ask. You’re still bound to one CPU, so it should take the same amount of time to execute your code, right? Well, that’s technically true, but script code execution isn’t the only thing causing latency in your application. The biggest piece of it probably comes from waiting for backend databases to respond to queries.

She gives the example of pulling in a remote file (HTTPS, where there's a bit more latency) and how to use async, await, WaitHandle, and Awaitable to work around the timing issue. She shows how to make a method asynchronous and how to join the results of the operation back up with the rest of the script. This includes the use of various "handles" including RescheduleWaitHandle, SleepWaitHandle and the AwaitAllWaitHandle. She shows the integration of a custom cURL handler that makes use of this processing, marked async, to multithread the requests to the remote server(s).

On DevShed today there's a new tutorial showing you how to build a basic ORM layer on top of a MySQL database. It includes all the code you'll need (cut&paste-able, not as a download).

Obviously, with so many ORMs at one's disposal for free, it seems pretty pointless to develop a custom one; are we trying to reinvent the wheel? No, of course not. But if you need to create a simple application that performs a few CRUD operations on some related domain objects and don’t want to climb the learning curve of a third-party library, then implementing a custom ORM might make sense. There's alos the educational aspect of the process (yes, learning one or two things never hurts).

They start you off with the creation of the "data persistence layer" (an interface first) to connect to the database, building a MySQL-specific one on top of it. Next up is the data mapper layer making things like "fetch by ID" and the insert/update/delete possible. Their simple example doesn't include anything about ORM relationships, though - just fetching simple rows.

On Script-Tutorials.com today there's a new article introducing you to using APC caching in your PHP applications. Their simple example sets up a caching class that handles the dirty work for you.

Today I have another interesting article for PHP. We will talking about caching, and practice of using caching in php. I will make review of APC caching and will show you how you can use APC in PHP. [...] Now people have learned to use the server memory for data storage. RAM much faster than hard disk, and the price of memory falls all the time, so let’s use all these advantages of this.

Included in the post is the code for a few different files - the caching class itself that implements the APC functions in PHP and some examples of it in use: saving objects, fetching data from the cache and removing things from the cache.

In a new post on his blog Timothy Boronczyk has a recommendation for developers working in PHP with databases that have a "fetch object" method - use it correctly or avoid it all together.

Lately I'm finding a lot of instances of the mysql_fetch_object() function being used in a particular codebase I help maintain. Unfortunately, I've yet to see it used correctly. It always seems to be used to retrieve a stdClass object from a query result where mysql_fetch_array() or mysql_fetch_assoc() would be the more appropriate choice.

Most of his complaint is that, despite pulling out the data as an object, most scripts continue to use it like you would an array, looping over it. There's extra overhead generated from the object creation that could cause issues, especially with large return data sets.

The best advice I can offer is to educate yourself and others how the function should be used so its abuse isn't perpetuated. Then, be cautious when using mysql_fetch_object() correctly and understand the process it follows to create and return an object. If not for yourself, then do it for the kittens.

Gonzalo Ayuso has a new post to his blog today with the results of some performance analysis he ran when fetching data with PHP and PDO.

Fetching data from databases is a common operation in our work as developers. There are many drivers (normally I use PDO), but the usage of all of them are similar and switch from one to another is not difficult (they almost share the same interface). In this post I will focus on fetching data.

He includes his sample scripts - one using just fetch() and the other using fetchAll() - that include some timing and memory checking logic and includes the results of his "limit 10000" queries from his tables. Not surprisingly, the fetchAll required more memory than the fetch call. Event changing it to a loop of fetch() methods results in about the same amount of memory as a fetchAll.

Michelangelo van Dam has a new post to his blog today with an example of using the Zend_Service_Twitter component of the Zend Framework to set up a simple Twitter client to connect and grab the latest tweets from an account.

Although the Zend Framework manual extensively describes how to set up a true Twitter application with the new OAuth implementation of Twitter using Zend_Service_Twitter and Zend_Oauth (since ZF-1.10.0), this is not what you're looking for. You need a simple approach, using the single user OAuth implementation of Twitter.

He shows (complete with screenshots) how to register for access to the Twitter API and how, once you've grabbed your access tokens, to pull the latest tweets from the selected account - complete with a code sample to show you how. It's a Zend Framework-specific example, but the components can be used outside the framework for the same effect.

On his blog today Brian Moon takes a look at the mysqlnd driver that comes with PHP 5.3 by default and some strangeness he found when trying to fetch results.

I have spoken in the past (see my slides and interview: MySQL Tips and Tricks) about using mysql_unbuffered_query or using mysqli_query with the MYSQLI_USE_RESULT flag [...] So, my natural thought was that using MYSQLI_USE_RESULT with fetch_all would yield the most awesome performance ever. The data would not be buffered and it would get put into a PHP array in C instead of native code.

He had hoped that the fetch_all would cooperate with the MYSQL_USE_RESULT setting, but it seemed to only work with the MYSQLI_STORE_RESULT default. He even filed a bug on the matter which was marked bogus and then reopened. He hopes to show, based on test results, that the result could be much faster.

Mihai Corlan has put together a list (ever growing) of AIR applications that use a PHP backend:

I want to maintain a list with RIA applications created using Flex and PHP (could be web apps or desktop apps). While this list is unlikely to be a complete list, I hope there will be enough applications to serve as a reference point or to inspire any PHP programmer.

On the list already are apps like Shifd, Flex.org, Kizoa and a Stock Fetcher. Keep checking back on the list for more great AIR/Flex and PHP apps as they're added to the list.

Lorna Mitchell has an introduction to Zend_Db, the Zend Framework database abstraction layer posted to her blog today:

I recently worked on a project which was based on Zend Framework - I haven't worked with it before and I was temporarily confused by the existing implementation of some of the database-level stuff. After much reading and untangling of code, I'm now pretty clear how this should look, so here's my overview. I'm not going to go into setting up a whole application, but this is a quick primer on how data models go together.

She talks about table modeling, fetching rows/data from the model and working with rows/rowsets.

On his CodeUtopia blog Jani Hartikainen gives an inside look at a feature of Doctrine, nested sets.

The Doctrine library comes with a feature called nested set, which makes saving trees in a database easy. However, it's quite easy to accidentally cause a lot of extra unneeded queries if not being careful. Here are some pointers to keep in mind while working with the nested set, and some example queries to make understanding it easier.

He gives an example, showing how to get rows from the database - parent and child - and some optimization tips to keep things light. There's also some pros and cons included for doing it either way (the standard fetching or using the more optimized versions).