In this new post to his blog today, Lars Strojny looks to clear up some of the confusion that might be forming around the term "intrusion detection", more specifically, related to projects like PHP-IDS.

PHP-IDS is an intrusion detection tool on the application level. Application firewalls know about a certain protocol and its structure (e.g. HTTP) and inspect the protocol to detect attack patterns. Some of them are even capable of learning from usual request signatures and enforcing rules based on the learned data. There are various commercial products to achieve application firewalling. PHP-IDS does the same for free and sits directly on the webserver in the scope of the application.

He recommends it as a good supplement to the hardening you've already done for your server (you have hardened it, haven't you?) to help keep you and your data safe from prying eyes.

Mike Naberenzy has posted about some improvements that were made to the PHPUnit testing software lately (support for TestNG-style groupings) and how, with a few of his own suggestions it was made a bit more flexible.

At my company, we typically organize our test case classes into high-level groups such as unit and functional. Method-level group annotations are inconvenient for us because we'd need to annotate every method of every test case class.

He includes an example of their use - commenting a testing class and running it through the phpunit command line tool with a call to the testing group's name.

In a update to his recent post on Cyclomatic Complexity in PHPUnit, Sebastian Bergmann has given more information about the software metrics support that the upcoming release (3.1.6) of PHPUnit will offer.

The upcoming 3.1.6 release of PHPUnit adds a couple of software metrics to the data that is stored in PHPUnit's test database.

Among the metrics gathered are things like: lines of code, commented lines of code, an attribute inheritance factor, depth of inheritance tree, method hiding factor and a polymorphism factor (he links each of these more complex ones for more information on the subject). Still included in the post is an example of the output for the Cyclomatic Complexity metric.

So, you've just upgraded to PHP 5.2 and all is going well until you come across a page in your application that gives the message "Nesting level too deep - recursive dependency?". With such a vague error message, you might have trouble locating the source of the problem. Thankfully, someone's already been there and figured out the issue - Richard Lord.

I installed PHP 5.2 on one of my testing servers today and a couple of bits of code that previously worked fine in version 5.1.6 threw fatal errors in the new version. The error message was "Nesting level too deep - recursive dependency?" and it took a little time to track down the root of the problem. Here's what I'd done wrong.

Basically, his problem was using the "non-strict" evaluation for checking if two objects were equal to each other (== instead of ===). This compares everything about them, down to the properties - even if they're references to other properties inside of the same class (which is where the problem lies).

So, the fix is simple - === instead of == when comparing those objects. You'll be happier for the change.

Company	Digital Business Solutions
Location	Louisville, Kentucky
Title	Entry Level PHP Website Programmer
Summary	We are looking for someone with a positive attitude who really loves programming and learning new technologies to become the newest member of our team. This is a full time position. Specific job responsibilities include website and web application development; database and link-integration; website maintenance; and content management tool development.
Link	More Information

On his blog today, Andi Gutmans has posted his feelings on the growing trend of PHP developers turnng to the C level of things to add new functionality to the PHP development.

One thing I have noticed, is that quite often, PHP developers who are seeking for new PHP features are prematurely trying to implement them in C. Although, there are definitely cases where you want to write your code in C, I think in some cases PHP is too quickly dismissed.

Developing features in PHP not only takes less time, but is also less prone to bugs, easier to maintain, and more stable and secure. Also, in the majority of cases, whether such a feature were implemented in C or PHP, would not make a significant different to overall application performance.

He gives the example of the ZSearch functionality that they mentioned in the php|architect webcast for the Zend framework - entirely implemented in PHP, not C. He also mentions a point that web developers would do good to take to heart - the bottlenecks usually aren't in the code - it's dealing with external resources that's the problem...