Paul Gregg has written up an example of what he calls "tail -# file for PHP" (starting from the end of file and moving backwards a given number of lines).

Here I will demonstrate a fairly tuned method of seeking to the end of the file and stepping back to read sufficient lines to the end of the file. If insufficient lines are returned, it incrementally looks back further in the file until it either can look no further, or sufficient lines are returned.

His script meets two goals - reading enough lines in for the request and keeping those lines to a minimum. His code grabs the size of the file and opens the file as a resource to fseek to a certain point and read in the lines from the defined start to finish and push them into an array. You can see the source here and a sample execution here.

In a recent post to his blog Evert Pot warns against some of the issues that mutual dependencies in your applications.

Much like most people, I try work out my class dependencies through a top-down 'waterfall'-ish approach. By attempting this, I think allows me to keep the structure very clear and understandable. [...] I try to apply the same model to instantiated objects and packages (groups of classes). When an object encapsulates another object, I attempt to make sure the sub-object object is not aware of the parent. When I design packages, I attempt to make sure 2 packages don't require 'each other'.

He gives an example of where this could cause problems - a Database logger that has three types of logging included: file, syslog and database. Obviously the last of the three requires the Database class so they must always be used/included together.

As a bonus a database-error could occur while logging, resulting in an endless loop (or segmentation fault if you're using PHP). [...] However, these types of situations are sometimes simply unavoidable (that's why we have include_once). When they are needed, they should be implemented with care and consideration.

In a recent post Fabien Potencier took a look at one method for getting metadata information from a subversion repository about the project(s) inside.

Last year, I deployed a new tool to manage symfony plugins. The first goal of this tool was to simplify the process of contributing new plugins. [...] The question I wanted to answer was quite simple: How many plugins were created per month before and after the change?

He uses a very handy option to modify the output of an "svn log" command - the "--xml" argument. This outputs the latest information (like author, date, paths and msg) for each of the log entries. This can then be thrown into a call to simple_xml_load_file and parsed down into the numbers he was looking for. He even generated a graph of the results as they coordinated with the different symfony releases.

Alvaro Videla submitted a new tutorial he's written up on integrating of a powerful parser (Hive with the logging of a popular PHP MVC framework - symfony.

The Hive project allows to load a logs file and then filter it with SQL like commands. Hive is more than this raw description, you can read more about it here. My idea was to adapt the file logging format of symfony to make easy to import those files inside a Hive database.

He shows how he created the tables to store the results, parsing the logs via a delimiter and terminator, and dropping the information into the table. This can then be integrated directly into the framework to load the log file up, parse it dynamically and display out (with a little bit more data, like a date) attached.

Ilia Alshanetsky has officially submitted his logging patch for the mail function in PHP:

I've finally got of my ass and committed my mail logging patch I've written almost 2 years ago. This functionality is predominantly aimed at shared hosters that often have a problem identifying people who abuse the mail() function to send an in-ordinate amount of spam or hacked scripts used for the some purpose. The logging functionality is disabled by default but can be enabled on a per-directory or globally via 2 INI settings.

A new directive in your php.ini file (mail.log) lets you specify where the mail log needs to go. You can also use the mail.add_x_header setting to add in a mail header with the name of the script that sent it (and the UID).

It will be included in PHP 5.3 but if you're running PHP 5.2 and want to get a jump on it, here's the patch.

On the PHPFreaks.com website there's a new article looking at one way to help protect your website from those evil doers out there looking to cause you and your data harm - PHP-IDS.

PHPIDS (PHP-Intrusion Detection System) is a simple to use, well structured, fast and state-of-the-art security layer for your PHP based web application. The IDS neither strips, sanitizes nor filters any malicious input, it simply recognizes when an attacker tries to break your site and reacts in exactly the way you want it to. [...] In a nutshell PHPIDS is an advanced intrusion detection system written with performance on a large scale in mind. The basic installation and configuration is pretty straight forward.

They (briefly) step you through the installation and configuration of the tool and provide a sample script to get the ball rolling - a file that can be auto_prepended to all scripts run on your Apache server to filter and log incoming requests.

In a new post to her blog Maggie Nelson points out the importance of error logs and a handy tool Zend Framework developers can use to make FirePHP even more useful.

The error log is a standard development support tool. It will help you find problems with your application. When developing, I take extra care to make sure that the error log is clean - this includes warnings and notices as well. When your application gets deployed, you can then depend on the error logs to accurately report any issues. [...] On a recent project, my coworker Matt Purdon wrote a pretty awesome debug console that leverages FirePHP support in Zend Framework to log a lot of information about what the application is doing directly to the Firebug console.

The end result is a console that lets you track things like session variables, memcached information and queries executed in the request (with explain plans). You can see a screenshot here.

DevShed has posted a new tutorial today looking at one of the more useful tools a developer can add into an application - logging.

If there is no logging mechanism, then if there's a goof-up in a production environment, you have absolutely no idea what went wrong. The only thing which a support developer can do in this case is to reproduce the issue at the developer end, which sometimes work and sometimes don't.

The look at the types of logging (trace logs, audit logs and user logging/history) and create a simple class that allows flexibility for file location, priority and timstamping. Their script contains a writelog method that does all the work (including pushing it through the PEAR logging class).

Tony Bibbs has posted a mini-case study about how, at his work, they cut their use of the Zend_Log component of the Zend Framework in half:

As part of the framework we use at work, we borrow what we feel are the best components out there and logging is a key part of that. Logging should be simple to setup, easy to use and should minimize work on the developer. After all, you are going to do a lot of logging, right?

He shows how, with a few changes to how they log (creation of a custom logger), it reduces the number of calls to load a Zend_Registry object each time something needs to be recorded. His code is included in the post along with examples of it in action.

Posted to his blog, Dave Marshall has a tip that uses declare and a trick or two to check out the memory usage of your scripts.

As far as I know, there isn't any memory footprint profiling in Xdebug, I think there was at some point but they removed it because it was a little flaky. I like to monitor the memory usage within my scripts, and I've found this simple snippet can help.

The script defines a log_memory function that pushes the memory and time information into a session value. The register_tick_function method is used to add log_memory to the handler and its called over and over from inside his for loop.