In a post to his site Christoph Rumpel shows the Laravel (well, Eloquent) users out there how to use groupBy at multiple levels for customizing and sorting the results of your database queries.

Since Laravel v5.5.29 you can group collections by multiple levels. Let's see what this means and how this works.

The post starts with some of the current functionality, showing how the groupBy could be used before with a simple collection to group student data by skill level. It then gets into the new functionality, modifying the example to group by both the skill level and by the "teacher" value. The result is a sorted set of results where the top level is the skill level and, inside of each, the teachers with students under that. The post finishes by "going crazy" and showing the grouping by event more criteria, adding "name" and "email" columns to the list.

In a recent RFC that's been proposed and is now up for voting, the suggestion has been made to drop the var keyword in PHP 7.1 and completely remove it in PHP 8 (made a bit redundant buy the public keyword in classes). Evert Pot, however, disagrees and suggests dropping public instead.

A PHP RFC vote has started to deprecate the var keyword in PHP 7.1 and remove it in PHP 8. At the time of writing, there 23 who say it should be removed, and 18 who say it should not. [...] I’d like to offer a different opinion: I think people should be using var instead of public. I realize that this is as controversial as tabs vs. spaces (as in: it doesn’t really matter but conjures heated discussions), but hear me out!

He goes through an example on one of his own projects, showing how he's mostly removed the public level of exposure from his development (using final and statics instead). He then suggests three common thoughts he sees people having being in favor of dropping var versus public:

• #1: Everyone doing the same thing is good
• #2: It’s ugly!
• #3: The public keyword is useful to convey intent

He also points to one place where he does see the need for a public but also suggests that in that case var would do juts fine too.

In this new post to his site Joshua Thjissen has shared some of his discoveries with Xdebug, Symfony 2 and problems with maximum nesting levels of objects in his testing.

Here you are, developing your code based on the Symfony2 framework. Creating a form here, add a Twig template there, until suddenly, boom! Your site doesn’t work anymore, and all the info you can find in your PHP logs is [an error about the maximum function nesting level being reached.

[...] What just happened? Did I create some kind of recursive function I wasn’t aware of, did somebody commit code that I accidentally pulled? Fortunately for us developers, there is a quick way to deal with this: google it...

According to the information he found via his search it's a common issue and can be "fixed" by bumping up the max_nesting_level to a higher value. He could have stopped there but he wanted to explain why this problem happened, what the nesting is all about, how it relates to the limitations of XDebug and why Twig could cause problems with it.

On PHPMaster.com today there's a new tutorial from Sneha Heda looking at error handling in PHP - the types of errors that can come up, how to throw your own and how to catch them appropriately.

Errors are the most common event a developer faces when programming. [...] To help reduce the number of errors in your code, and to mitigate their effects, proper error handling is essential in your web application. This article is a crash course in PHP error handling. You’ll learn about PHP’s built-in error reporting levels, and how to handle errors with custom error handlers and exception handling.

She starts with the different error reporting levels PHP offers, everything from the lightweight E_NOTICE out to E_ALL|E_STRICT. With this as a reference, she shows how to create a custom error handler (using set_error_handler). Also included is a look at exceptions and some of the more detailed information that comes with them - line numbers, messages, file the error was thrown from, etc.

On his blog today Brian Swan has posted the results of some of his research on transaction isolation levels in SQL Server PHP applications.

Last week I had the good fortune of presenting at the the Seattle PHP Meet Up on a topic I knew only a little about: transaction isolation levels. It was fun doing the homework to learn more and I'll share what I learned in this post. This post is only somewhat PHP-specific. I'll focus largely on the concepts behind database transactions and isolation levels. Most of the concepts I'll look at are database agnostic (although I will use SQL Server as the vehicle for explaining the concepts) and are supported by most relational database management systems out there (e.g. SQL Server, MySQL, Oracle, DB2, etc.).

He introduces database transactions for those not familiar (a key to understanding the rest of the post) and some PHP code that connects to a SQL Server and begins a transaction to update some banking information. He uses this example to show how to set up isolation levels like "READ UNCOMMITTED", "READ COMMITTED" and "SERIALIZABLE".

New from the PHPFour website, there's this post with a few tips to help you become a "kick-ass PHP ninja" in your development.

You've been developing web applications using PHP for a couple months now and are finding it very enjoyable. Although you feel that you're doing quite good, you're not sure whether its the end. [...] If that's the scenario, then this post if for YOU.

Its broken up into two methods to move forward in your career as a developer - the technical way and the personal way. The technical way involves things like using version control and adhering to a coding standard. The personal way includes tips like "keep yourself updated" and "start community involvement".

Mike Naberezny 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.

Mike Naberezny 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 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.

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.