Commonly known as .htaccess, AllowOverride is a neat little feature that allows you to tweak the server's behavior without modifying the configuration file or restarting the server. [...] Beyond the obvious security problems of allowing configuration modifications in a public document root there is also a performance impact. What happens with AllowOverride is that Apache will do an open() call on each parent directory from the requested file onward.

He includes the output from a strace call in the post - first showing the function calls with it set to "none" then the same request with the setting on "all". More "open" calls are being made in the second run, increasing the execution time by a decent amount.

Normally this tool would be used on your development environment, or in rare occasions on some remote environment that is similar to the production environment. [...] Since you are adding extra overhead it is very likely things will run slower. But how significant is this difference. Would it be something worth considering?

To lay the ground work, he describes the hardware he's running the tests on and the software he used - PHP 5.2.6 (Suhosin) on Debian with Xdebug 2.1.0 - and the script he used to run the tests. Several tests were run multiple times (3) showing quite a difference in performance when using the debugger versus not. He also suggests a more practical testing scenario with WordPress and ApacheBench. The numbers still support the other results.

In a side note, the Twitter account for Xdebug has mentioned some updates that have been made to the version currently on their SVN server that can help with some of these performance issues.

If you were not aware, Zend_Log provides facilities for writing to multiple logs through the same log instance. Additionally, you can do this via configuration options when using a Zend_Application resource plugin. Together those make for very powerful logging mechanisms. "How?" you ask? It's really easy.

The trick lies in the application.ini file configuration. He includes an example of how you can set this up showing how to make two different environments log differently - development writes to log/firebug and production just writes to the log. He includes some sample code for a basic controller showing you how to use it.

A question that comes up again and again in web development companies is: 'Should the developers have access to the production environment, and if they do, to what extent?' My view on this is that as a whole they should have limited access to production. A little disclaimer before I attempt to justify this view is that this standpoint is in no way based on the perceived quality or attitude of the developers '" so please don't take it this way.

He talks about common excuses from developers like "we've had access before" and "we need access to troubleshoot" as well as some of the process restricting the access could create. He touches on a few other issues including developer concerns vs those of the sysadmin, change control issues and the responsibilities of the sysadmin administrators if they want to allow the developers to poke around their servers.

Be sure to check out some of the other great suggestions in the comments too!

This is the method I used to move my local copy of magento store from WAMP on windows to a shared hosting account. In my case am using magento1.3.x.

The instructions are detailed right down to which configuration values to change, how to update your database for the move, what will need to be removed before you and push everything over. There's even a bit of instruction on what to change if your database structure is slightly different.

There are four primary systems that need to be set up and isolated. And they are described by the acronym DTAP-Development, Testing, Acceptance, and Production. One thing that has changed recently, though, is that these systems no longer have to mean separate hardware.

He gives an overview of each, setting out definitions to be used for the rest of the series with the next part discussing some of the "smaller moving pieces" of the process.

HP's OCI8 1.3.3 has support for Oracle's DRCP connection pooling and Fast Application Notification technologies giving it improved scalability and high availability. Overall, the re-architecture of the connection code is more stable. It fixes some obscure edge case issues and lets it handle re-started DB's better. Basic functionality is unchanged.

You can find out more about the package and download this latest edition from its PECL page or check out the whitepaper they recent;y wrote up about PHP and Oracle scalability.

OK, then what we do if something weird happens in production and we want to see the errors, but we don't want others to see them? [...] Maybe PHP could have some setting like display_errors=local which would enable display_errors for requests originating from developer machine but would disable it when outsider accesses it?

Richard's solution checks the HTTP_HOST value of the current request and, based on whether it's marked as "live" or "dev", uses a ini_set to change the display_errors setting to true/false.

I've not added any new features to the class; I've simply updated it to be, well, better. Plus it uses PHP5's object model better. It's really just an update, ie if you're using the old version and it works, then you have no real reason to update it.

You can check out the source here and an example of it in action here.

Rival Schools, a strategic design and production company, is looking for dedicated, enthusiastic web developers for upcoming projects.

We are looking for team-oriented problem solvers who can help us build great online experiences for our clients. Rival Schools is a collaborative company, and we want people who are active participants in the development process.

Successful applicants will have at least 3 years experience and be really good at the following:

• PHP/MySQL Development
• ASP, IIS, SQL server
• Javascript, AJAX, DHTML, XML, CSS
• experience working with Flash applications
• great communication skills including the ability to work with creative teams and producers to achieve client goals.
• solid organizational skills with ability to manage multiple projects and meet deadlines
• strong understanding of cross platform browser requirements
• ruby on rails knowledge is an asset

We have both full time and contract opportunities available, and are open to applications from all over. We're much more concerned with who you are than where you are.

Send applications and a brief intro about yourself to jobs@rivalschools.tv, and thanks for your interest in Rival Schools. No phone calls please. We'll contact you to schedule an interview.