In this recent post to his blog Michael Caplan looks at a feature of PHP that's sometimes forgotten when pushing out larger chunks of data - flushing.

As a recluse who prefers hiding behind servers rather than dancing around your web browser's canvas, I was intrigued with their server side recommendations - however sparse they may be. In particular, flushing generated head content early to speed up overall page delivery and rending time was a technique new to me.

Michael looks at what "flushing generated head content" means and includes a scenario - pulling the top palettes from the COLOURlovers site - and some performance stats on page load time and response time directly from the server (complete with graphs).

Derick Rethans one of the go-to guys for working with time in PHP has made this new post about something 2008 picked up along the way to 2009 - a leap second.

The start of this new year started with some buzz about a leap second being introduced between Dec 31st 2008, 23:59:59 and Jan 1st 2009, 00:00:00. I've had people ask where this leap second actually comes from, and whether you need to worry about it in your applications. To understand leap seconds means, unfortunately, understanding how time is actually kept.

He ponints out one of the major problems - how time is kept. With variants of Universal Time, it makes it hard to track down what's "right". He breaks out the difference between other time storage methods and the unix time that PHP can use (that counts the number of seconds since Jan 1st 1970) and how the leap second was handled for each.

On the Experimentalworks blog a recent post looks at using DTrace, the powerful tool to debug and trace problems in an application, with your PHP applications.

Dtrace is really powerful and trying to do an introduction to all it's features is just not possible. Therefore I will just focus on the basics, that are needed to get our stuff working. The basic idea behind Dtrace is that the kernel and userland programs fire probes on a specific location in the kernel or the userland program.

He looks at the structure of a DTrace program as well as a list of probes that you can use to help track down the problem in your application. His "first example" traces the compile time of the app and, when run on the command line, returns the time in seconds.

Paul Reinheimer has a new post to his blog today talking about a special event happening at this year's php|works conference - Pecha Kucha.

The format is a little bit different than a talk (thank god) and hopefully a lot more fun. Basically the presenter gets up there with twenty slides, each are going to be shown for exactly 20 seconds, for a total of six minutes forty seconds. No take backs, no do-overs, no boring slides full of code.

He tosses in a few FAQs for those interested (who can do it, what can it cover, etc) and who to contact to get yourself signed up - drop Elizabeth Naramore an email and let her know you're interested.

In this new post Jani Hartikainen shows a quick and easy method for creating a custom form element in your Zend Framework application. His example is a custom time element.

The alternatives would be creating custom view helpers to output the custom form elements, and using the viewscript decorator. Creating a custom view helper would also require a custom form element class, and it would be a bit tricky. [...] I think the viewscript approach is the most flexible and simplest to implement, so I chose to go with that.

His example defines a time field made up of three drop down lists, one each for hours, minutes and seconds. Included is the code to make the element (including a regular expression for validation) and the view script to display it.

On the PHP::Impact blog there's a recent post that details a statistic Paul Jones found with the Zend Framework's performance - a drop in the response time of the front controller between the 1.0 and 1.5 releases.

The most important factor in making a Web application fast is its basic design. You must also know what kinds of processing your framework is doing, and what its bottlenecks are. The best way to find the performance bottlenecks is to monitor the performance counters and to have a thorough understanding of the framework your application is using.

Federico runs some benchmarks of his own (using the Apache benchmarking tool, ab) both with a default "base app" and with a more optimized "take out what you don't need" version.

Brian Moon had a problem - one of his cron jobs was lasting for much longer (hours!) than it should have been. He tweaked, tested and debugged the script and finally came down to a call to in_array, something he comments on as being "quite slow".

See, this job is importing data from a huge XML file into MySQL. After it is done, we want to compare the data we just added/updated to the data in the table so we can deactivate any data we did not update. [...] We then compared the two arrays by looping one array and using in_array() to check if the value was in the second array. [...] So, that was running for hours with about 400k items. Our data did not contain the value as the key, but it could as the value was unique.

He method, replacing the in_array call that had to do a full array scan for each time through the loop with an isset/unset combo on the unique key, changed the execution time down from about 4 hours to 0.8 seconds.

Hasin Hayder has posted an example of a "world time search" he's worked up that uses the geonames.org and Yahoo! developer APIs to pin down the time at any given location.

I recently came by this site WorldTimeEngine where users can search the local time of any place using the name, street address or just latitude and longitude. Since that time I was thinking how easily you can make your own. As long there are some good people over there (For Geocoding API) - its a not a big deal, you know?

His script pulls the location of the place (latitude/longitude) from the Yahoo! geocoding API and passes that back into the geonames web service to get the local time. The result is an array with the lat/long, address you submitted and the time output in a standard string.

Following on the heels of this post to the SitePoint blog (about "roughtime"), Akash Mehta has posted his own version of providing users with something a little different - relative time.

I understood the merits of the approach, but it struck me that a relative time might be a little more useful for many situations. For example, in a fast moving discussion, a short timestamp (e.g. 8:30 AM) as well as a verbal summary of how long ago the time was (e.g. "4 hours ago", "20 minutes ago") are most useful to the user. [...] Now, I figured this could be achieved very easily in PHP - and it could.

His code is included showing a series of if/else comparisons that change the values to their hour/minute/second counterparts. He also recommends the PEAR Numbers_Words package to help with readability.

In a new post to the Web Tech blog over on SitePoint, Toby Somerville has posted something he calls "RoughTime" - his method for displaying a more "human friendly" output of a timestamp.

When asked the time, we generally don't need to be military accurate with our response [...] we generally communicate the approximate time. i.e. 'its nearly ten' or 'its just gone half past three'. Yet on the web, time is generally shown as '12:24:13 AM', or similar '" not very visitor friendly.

His RoughTime uses two switch statements to map the hour and minute values to different strings. For example, minutes between 15 and 20 become "quarter past" and the hours are changed over from numeric versions to their word counterparts.