Straylight Run

Here’s a good reason to keep all your development and production environments the same.  The task was simple enough.  I wanted to strip a UTF-8 encoded string of all punctuation.  Here’s some example code that does it, using PHP’s PCRE library.

On PHP 5.2.4:
% php -i | grep PCRE
PCRE (Perl Compatible Regular Expressions) Support => enabled
PCRE Library Version => 6.6 06-Feb-2006
% php pcre_test.php
ss

On PHP 5.2.6:
% php -i | grep PCRE
PCRE (Perl Compatible Regular Expressions) Support => enabled
PCRE Library Version => 7.6 2008-01-28
% php pcre_test.php
TAGholy moley     báts were killed by  dogs for 50 ümlauts

Only took me a day to figure out.

Xdebug is an indispensable PHP tool. It is a PHP extension that adds a wealth of capabilities to your PHP development.  There are so many features, I’ll dive right in.

var_dump() Replacement

Xdebug replaces PHP’s var_dump() function for displaying variables. Xdebug’s version includes different colors for different types and places limits on the amount of array elements/object properties, maximum depth and string lengths. There are a few other functions…

My favorite part about this: the output is already pre-formatted, so no more echoing <pre> before every var_dump().

Stack Traces For Free

When Xdebug is activated it will show a stack trace whenever PHP decides to show a notice, warning, error etc. The information that stack traces display, and the way how they are presented, can be configured to suit your needs.

Even if you have display_errors off and all errors are sent to a log, the log will still contain the stack traces of any errors.

Function Traces

Xdebug allows you to log all function calls, including parameters and return values to a file in different formats.

This is the ultimate debugging trace. It will create a file with every function, including third-party libraries and PHP internal functions, that was executed along with its arguments. It also displays the execution time the function was called at (where 0 is the start of the request), and the total amount of memory used at that point.  What I like to do is insert xdebug_start_trace() in the bootstrap file at the start of the page request.  I wrap a condition around it to enable it by giving a secret GET parameter on the query string.

if ($_GET['debugflag'])
{
   xdebug_start_trace();
}

Profiling

Xdebug’s built-in profiler allows you to find bottlenecks in your script and visualize those with an external tool such as KCacheGrind or WinCacheGrind.

Xdebug, in conjunction with KCacheGrind, can generate a profile call graph which serves as the ultimate profiling report.  First, generate a cachegrind file from Xdebug by appending XDEBUG_PROFILE as a GET pararmeter to the URL of the page you want to profile.  After the page loads, you will find a cachegrind output file in the output directory (specified in xdebug.ini).  Run KCacheGrind and open the output file. You can then generate a call graph which looks something like this:

Limitations:

• KCacheGrind only runs on some kind of Unix. I attempted to run it on Windows/Cygwin unsuccessfully. There is a WinCacheGrind, but it does not offer the call graph feature.
• The call graph feature requires that the source code be local (this info is contained in the cachegrind file). Which means you have to run KCacheGrind on the server, or synchronize the code on the server locally.

I don’t know if it’s true, but I thought I read somewhere that opening and closing the refrigerator wastes energy.  Maybe that’s why, the other day when we were unloading groceries, I caught myself trying to minimize this waste.

Here is the layout of our kitchen.  We usually bring in all the groceries from the car and put them down in the Grocery Unloading Area.  From here, we grab a handful of items put them away.  If some go in the fridge, we open the fridge and put them away.

If opening and closing a refrigerator incurs an overhead, just like opening and closing a network or database connection incurs an overhead, this is very inefficient.  So I found myself bringing refrigerated items near the fridge, in a Refrigerator Staging Area, or refrigerated items buffer, if you will.  This way, I could quickly put away all fridge items, flushing the buffer, and only open the refrigerator once, saving the setup and teardown refrigerator opening costs.

Too much of a stretch?  I deal with this kind of crap all day long, so maybe this was inevitable.

I was browsing through some junk mail the other day, when I came across an ad for this INCREDIBLY ADVANCED photo storage device. If you’ve already seen the TV commercial for Wallet Pix^TM, showing a bunch of older women showing pictures of their grandchildren to each other on this thing, then you know what I’m talking about. I mean, WOW!

This thing is thicker than an iPod and most phones, probably so it can hold UP TO 58 PHOTOS!  That’s like… a ZILLION photos! I’ll never be able to fill up that kind of storage.  AND it comes with a built-in stand, for, you know, when you want to display family pictures on your end table on a screen that’s smaller than a credit card.  Act now!  Only $19.99!

In MySQL (and MySQL only AFAIK), INSERT has a clause called ON DUPLICATE KEY UDPATE. When ON DUPLICATE KEY UPDATE is used with INSERT, the insert will update the record if a value for a unique or primary key already exists, or else create a record if the value does not exist. So now when a form can either create a new something or edit an existing something, you can use one query to do it, and not have to query to see if the something exists already.

So instead of this:

$num = $db->getone("select count(*) from events where event_id = 15");

if ($num > 0)
{
   $sql = "update events set name = 'New name' where event_id = 15";
}
else
{
   $sql = "insert into events (event_id, name) values (null, 'New name')";
}

you can do something like this:

$id = (empty($_POST['id'])) ? null : $_POST['id'];
$sql = "insert into events (event_id, name) values ($id, 'New name') on duplicate key update name = 'New name'";

Neat, eh?

In case you’re wondering what the difference is between ON DUPLICATE KEY UPDATE and a REPLACE query, a REPLACE fires a DELETE followed by an INSERT query, as opposed to a real UPDATE.