php

APC 3.1.9 has a nasty bug, causing a frustrating error: "PHP Fatal error: Unknown: apc_fcntl_unlock failed: in Unknown on line 0" to appear when installed with PECL on Mac OS-X (and reportedly on a variety of Linux platforms).

There's an easy fix.

It's not always easy, in PHP, to figure-out which PHP ini files are actually parsed and loaded. CLI may use diff set than web, and if you are using NginX with FPM, there may be yet another set.

Following extremely simple piece of code can greatly help in clearing-up the confusion:

print_r( php_ini_loaded_file() );
print_r("Scanned: ");
print_r( php_ini_scanned_files() );
exit();

It's a pretty common need to format an array as a proper comma-delimited string for use in SQL's "WHERE ... IN" clause. Following is a simple solution that demonstrates how closures in PHP 5.3+ make writing such code pretty elegant. A unit-test is included to demonstrate several edge cases:

Install prerequisites and latest Erlang

RabbitMQ can install Erlang for you, but it does not install latest Erlang/OTP, which can cause problems when you try to install Admin UI, so it's the best to just compile latest Erlang/OTP

$ sudo apt-get update
$ sudo apt-get install build-essential
$ sudo apt-get install libssl-dev zlib1g-dev lsb-base 
$ sudo apt-get install ncurses-dev libncurses-dev
$ sudo apt-get install libcurl4-dev libcurl4-openssl-dev 
$ cd /usr/local/src/
$ sudo wget http://www.erlang.org/download/otp_src_R14B03.tar.gz
$ sudo tar xzvf otp_src_R14B03.tar.gz 
$ cd otp_src_R14B03/
$ sudo ./configure 
$ sudo make && sudo make install

Erlang compilation will complain about jinterface, odbc, wx and xsltproc and fop. We do not need any of that for our purposes, so please feel free to ignore.

Install RabbitMQ from Repo

Add the following line to your /etc/apt/sources.list:
deb http://www.rabbitmq.com/debian/ testing main

I am not a fan of MAMP, XAMPP or other pre-packaged Apache/PHP distributions, in general. Ever since OS-X started moving towards being POSIX-compliant operating system and equally importantly HomeBrew recipes started providing easy installation of required linux packages, I try to stay away from MAMP & Co. Additionally, OS-X comes with pre-install PHP/Apache (and adding MySQL is very easy with HomeBrew) so installing a parallel Apache/MySQL/PHP stack feels dirty.

One big problem: there's no APC with the pre-installed Mac PHP, which can make large PHP projects very slow.

Thankfully it's easy to fix, once you already have HomeBrew:

With the VPS expansion you can now get a (very) small virtual private server (VPS) for a very affordable price. However, when you get a server with something like 256MB or 512MB RAM and a portion of CPU power, using default MySQL/PHP/Apache settings is a pretty bad idea.

Performance and scalability tuning of a server is more of an art than science, in the sense that there're no ready-to-use formulas. Optimal server settings depend on many unique factors: web-app code, traffic to the site, site's information architecture among other things. It's virtually impossible to really optimize server settings without thorough understanding of the web application and a lot of testing.

That said, you are not going to run newsweek.com or huffingtonpost.com on a 256MB slice. Also, the default settings are typically so off that it is possible to give you a much better starting point. I'd like to share with you some settings that have worked well for me. I am assuming you are running a small site or a blog, with the traffic of several thousand page-views/day, using Wordpress, Drupal or something of that kind. I highly recommend getting at least a 512MB VPS, but these settings are better than the default for a 256MB server, as well.

Following are some variables for various settings files that have been modified from their default values.

Even though you may find xdebug in a yum repository, due to version incompatibilities you may need to compile/install it using Pecl. Following are several easy steps to achieve exactly that:

check the output of the command above, if everything went well, you should see something like :

at the end of the output. Note the location of the .so file and using it create /etc/php.d/xdebug.ini file that rads something like:

If you want to use xdebug for profiling you can also add configuration like:

Whenever you want to run profiler, you can change xdebug.profiler_enable to one, but be careful not to forget it on, when you are not profiling since it will cause each page load to produce megabytes worth of debug output file.

Please also note that for profiler to run properly /xdebug/ folder must exist and be writable by Apache process.

Once you are done with the installation, restart Apache and check the PHP module list with: "php -m", you should see "xdebug" appear in the list.

PHP error messages are quite helpful, most of the time. Sometimes they do fall short of telling us what went wrong, however. It's especially common when and if you use a development framework (e.g. Drupal). Frameworks often do output buffering and/or code eval()-ing, making debugger output incomprehensible.

In such cases PHP's debug_backtrace() function is a real savior. debug_backtrace() is also very helpful if you want to look at the execution stack in a complicated code, to better understand the code. This function shows the execution stack that lead to the current function and does it pretty well... "too well" sometimes :) Out-of-the-box version of the function shows the list of invoked functions, source files they belong to, line numbers in the source file and the argument values being passed. The latter can be a huge problem, if code is passing around large variables. Output on the screen may get so garbled (esp. if HTML is used in variables) that the entire exercise may lose its meaning.

Short snippet below sanitizes debug_backtrace() output to make it slimmer and more comprehensible:

$trace = debug_backtrace();
foreach ($trace as &$t) {
  unset($t['args']);
}
echo "<pre>".print_r ( $trace,true)."</pre>";
exit();

UPDATE: instructions for Espresso 2.0 at: http://freshblurbs.com/espresso-and-syntax-highlight-custom-file-formats

Espresso From MacRabbit (you may remember them for their splendid CSSEdit eidtor) is a new Web editor, for Macs, worth paying attention to. It handles the usual suspects: PHP, CSS, HTML, servers over SFTP, Amazon S3 etc with style out of the box and has numerous extensions for other things like Python, LUA, SQL, Regular Expressions etc. And it's only 1.x version, so you bet you can expect much more in coming versions.

One little shortcoming it had, for Drupal developers is that, there's no easy way to configure custom-for-Drupal PHP extensions: .module and .install to make Espresso recognize these as PHP files.

Joe Shindelar of Dreamformula has posted a nice blog post detailing the configuration of custom PHP extensions in Espresso.

Thank you, Joe!

Yum is a standard installation utility for CentOS 5.2. One of the reasons I favor CentOS over other Linux distros is actually because it comes with yum. It is that good!

Unfortunately, CentOS 5.2 does not generally include the latest versions of libraries, because it follows conservative path of the RedHat Enterprise. Which is not that bad of an idea, for a server OS... until you need that latest version of something and you are stuck... or: not necessarily.

If you a are a Drupal developer, there's a very good reason why you need the latest version of PHP: 5.2. The reason is called FileField module. This module is required by another absolutely essential module ImageField making it a matter of life-or-death (just kidding) to have PHP 5.2 on your server. But the latest CentOS release (ironically also 5.2) only comes with PHP 5.1.6.

What to do?