In the PHP core development community there has been a tiny bit of good-natured grumbling about a clamp down on code merges. The experienced developers actually recognize the need for this restriction.

Restricting what can be merged prior to release is important. Why? Because any code change has the potential for unforeseen destabilization or could introduce a whole new set of problems. Also any change distracts the RMs (and others) from review and testing of more critical areas. The voice of experience speaks.

Think about the worst case: merging a brand new feature. If this happens just before the production release, then there is no time for the feature to be evaluated, documented, tested . . . . New features typically aren't allowed to be added after the Alpha release of a project (PHP is actually a little lax about Alpha/Beta terminology here). As the production release date approaches, bugs must be increasingly more critical in order for fixes to be merged.

On the other hand, merge restrictions introduce one big problem: somehow the team needs to revisit changes merged by eager developers to the other PHP branches (PHP 5.2, PHP 6). Someone has to come back and merge them into a future 5.3 patchset. This is one of the reasons programs need good source code control reporting and tooling.

What can you do for PHP 5.3 today? Test it. Snapshots of PHP are at http://snaps.php.net/ .

Start by reviewing the UPGRADING guide. And give a yell if you come across a feature change that isn't documented or if something breaks. The PHP bug database is at http://bugs.php.net/.

Last night's San Francisco PHP Meetup would have proved them wrong. A big crowd was paying very close attention and asking lots of questions to the SonicLiving crew, whose talk covered the whole gamut from implementation details to how they do business.

One of the questions towards the end was how they hired. Anecdotes were told about a programmer with a corporate "let's spend a month writing a design" attitude and, at the other end of the spectrum, about the programmer who turned out not to be able to work in team "I deleted this function because I didn't understand it". For a start-up company it's important to get people who are able to put ideas in production quickly so user uptake can determine good from bad, and resources allocated to enhancing the successful ideas.

Later, in the post-talk group announcements, three other people stood up and said their companies were looking for good PHP developers. Looks like there is demand for your skills out there . . . .

And how exactly do you hire? There was no real consensus on where to find people. Good people already tend to have jobs. Use all the channels from Craigslist to word of mouth. Maybe even agencies!

Afterwards, I was in a post-talk discussion on interviewing techniques. Mariano Peterson (the assistant/co-organizer of the meetup) said that when interviewed, he had found it more interesting when he was told to write and brainstorm on a whiteboard instead of just being allowed to talk. I've always liked being able to have a free flowing discussion too.

But one of the verbal techniques I've found successful for first interviews is the "STAR" system: Situation-Task-Action-Result. You can use it as a interviewer. You can also use it to showcase yourself as an interviewee.

The method is designed to find out what you personally have done in the past. An interviewer might ask for a situation you've been in, what your exact task was, what action you physically took, and what the end result was. Much information on the STAR technique is available on the web.

For interviewees used to working in teams, it can be hard to stop saying "we" in every sentence: "we implemented a widget". As an interviewer this is frustrating since you have no idea what the person actually did on the project. Patience is needed.

Me: "Oh a widget you say? What was your role in creating the widget?".

Them: "We worked on a fantastic color scheme that added great value to the appeal and success of the widget".

Me (thinking): "Arrrrrgh!"

At this stage the interviewer still has no idea what the interviewee actually did on the project - did they do research, mix paints, coordinate the project etc? All those are valuable skills but the interviewer wants to understand what the interviewee is capable of and what their interests, strengths and weaknesses are.

Thinking about your skills in the context of STAR is also a great way to prepare yoruself for interviews.

Thanks to CBS Interactive (formerly C|Net) for hosting the PHP Meetup and the Gabe and Steve from SonicLiving for sharing so much information.

In the last 12 years PHP has progressed and grown in many directions. Along the way, the "oci8" extension replaced "oracle" to become the recommended Oracle database extension for PHP, and the "pdo_oci" driver was introduced for the PDO extension. Many fine people have contributed. I'm proud for Oracle to be part of the PHP community.

Here's looking to the next 12 years.

Despite hearing the "disk is cheap" mantra most of my professional life, sometimes less is more, such as when it comes to reducing deployment and backup costs. Although IC isn't particularly big - and it's getting relatively smaller all the time - there are two ways to reduce its size:

1. Use the Basic Lite instead of Basic package. This is much smaller because it only supports common character sets and only has English error messages.

2. Remove the JDBC, ODBC and OCCI libraries. These libraries are not needed by PHP OCI8.

The IC Basic package libraries needed for PHP OCI8 are given in table 1-3 of the OCI Manual:

On Linux:

libclntsh.so.11.1
libnnz11.so
libociei.so

Or on Windows:
oci.dll
oraociei11.dll
orannzsbb11.dll

The IC Basic Lite package libraries needed for PHP OCI8 are given in table 1-5 of the OCI manual:

On Linux:

libclntsh.so.11.1
libnnz11.so
libociicus.so

Or on Windows:

oci.dll
oraociicusll.dll
orannzsbb11.dll

If using the ZIP files on Linux, don't forget to create the symbolic link:

ln -s libclntsh.so.11.1 libclntsh.so

before building PHP OCI8.

Excuse me only offering guidelines here and not a definitive best-practice: signal handling is port specific; there are many ways to configure PHP; there is much choice in which extensions to include; and there are many different web servers that PHP can run under.

The old heuristic for OCI8 users was to configure PHP with --enable-sigchild if you saw defunct Oracle server processes - the process that handle the work for each connected user. Each PHP process communicates with its own server process.

There are some side effects with --enable-sigchild. On my OS I know pclose() returns failure; several PHP bug reports exist for this and PHP code has been patched and broken (?) in this area.

My New --enable-sigchild Usage Heuristic:

Only if you see defunct "zombie" Oracle server processes then start PHP/Apache with the Oracle Net option BEQUEATH_DETACH=YES in your sqlnet.ora, or, to keep the setting specific to PHP, set your environment starting Apache:

    export BEQUEATH_DETACH=YES

If this doesn't help, then consider building PHP with --enable-sigchild.

Defunct processes might happen if the Oracle code in PHP forks the Oracle server process (called "bequeathing") and the signal handlers in PHP, as the parent of the server process, do not correctly clean up the server process when a database connection is closed. The BEQUEATH_DETACH=YES option causes the server processes to do a double fork and be inherited by "init", which prevents defunct zombies. Oracle 10g onwards check for signal handler clashes and automatically turn on BEQUEATH_DETACH, reducing the need for you to set it. It's not on by default because it adds a few extra CPU cycles and the OS parent process id becomes 1, making it slightly harder to identify the relationship between a server process and the application process using it. You might need to manually set it on if signal handlers are changed after Oracle has done its heuristic check.

You should never need to configure PHP with --enable-sigchild or set BEQUEATH_DETACH=YES if PHP is "remote" from the DB server. PHP can be "remote" physically or because PHP is linked with Oracle Instant Client or linked with different Oracle libraries to those used by the DB - where you use an Easy Connect or tnsnames.ora connection string. You also don't need to change signal handling if you use Shared (MTS) or Pooled Oracle servers. These are the cases where PHP does not fork the Oracle server process directly. The Oracle Net listener does the forking instead and PHP's signal handling won't affect Oracle server process cleanup.

So the new heuristic is the same as the old heuristic. But the suggested remedy is different, and I feel the frequency of seeing zombies is low because of the uptake in improved versions of Oracle and because of the common separation of the PHP mid-tier from the database servers.

Customers with metalink.oracle.com accounts might care to look at Note 452122.1, "The use of Client signal handlers and Oracle BEQUEATH Connections" which explains more about BEQUEATH_DETACH and forking.

Let me know your experiences.