In a new post to his site Matthias Noback makes an interesting suggestion about working with objects in PHP: that they should all be made in one, and only one, place.

Consider the following rule: "When you create an object, it should be complete, consistent and valid in one go."

It is derived from the more general principle that it should not be possible for an object to exist in an inconsistent state. I think this is a very important rule, one that will gradually lead everyone from the swamps of those dreaded "anemic" domain models. However, the question still remains: what does all of this mean?

He shares an example of an object (GeoLocation) that can be created with only the latitude value but points out that this leaves it in an invalid state. He updates this example to show a more complete implementation, one that prevents an object with partial setup from happening. He then talks about the aggregation of child entities and a "paper" metaphor. This metaphor - imagining a "paper purchase order" - helps him wrap his head around the structure of the objects and how they interact.

The SitePoint PHP blog has a tutorial posted from Andrew Cairns showing you how to model an aggregate with Eloquent, the database access layer from the Laravel framework. The "aggregate" here is an implementation of the Aggregate design pattern, a system of smaller opbjects operating as a whole.

The Aggregate pattern is an important part of Domain Driven Design. It prevents inconsistencies and is responsible for enforcing business rules within a collection of objects. For these reasons alone, it is clear to see why it is a key component of a domain model.

[...] Mixing persistence concerns into a Domain Model can become complex and lead to a lot of bad decisions. This does not mean that it is impossible to create an Active Record Domain Model. In this article, we will work through an example of building an Aggregate which also extends Eloquent: a popular Active Record ORM.

They start with a brief summary of what the Aggregate design pattern, how its objects work together and the point of a "root" object. They help illustrate how it would in a more real-world situation with a simple blog system, starting with a simple Post object minus the Eloquent integration. From there they bring in Eloquent, showing how to extend it with the class and what features it introduces. Most of the changes they make then revolve around a "lock" on the post and where value objects and the invariant rule comes in to play.

In a new post to his site Jeremy Cook introduces you to Graylog2, a logging server that can aggregate messages from multiple sources/feeds into one consolidated location.

Graylog stores them in a database and allows you to perform custom searches on them. You can also see in real time how many log messages are being received and processed. The real killer feature in Graylog is streams. A stream in Graylog is a predefined custom search. The server will display to you log messages that only match the stream criteria selected, graphing the results for you.

He mentions other features of the Graylog2 system including customized alerts, messaging via UDP/AMQP and how it uses MongoDb and ElasticSearch. He also introduces Monolog, a PHP tool that lets you log in multiple formats directly to the Graylog2 server. He includes an example of how it works with a sample "LoggingHelper" added as custom exception and error handlers.

Thomas Weinert has a new post to his site showing some of the things that iterators can do for you (including working with arrays and aggregation).

Basically Iterators provide a list interface for an object. Like all interfaces they are a contract how something can be used. If you use an interface it is not relevant how it is implemented - the implementation logic is encapsulated. It is of course relevant on the integration level. A bad implementation can impact the performance of you application. Even an good implementation may need special resources (like a database). But all this does not impact how you use it. Your code using the object with the Iterator interface stays the same.

He shows how to use the IteratorAggregate, ArrayIterator, FilterIterator and how to create a custom Iterator that you can extend in your own code.

Brian Moon has a new post to his blog that pulls together some of his thoughts on monitoring PHP applications and how to handle the error that might be thrown.

PHP errors are just part of the language. Some internal functions throw warnings or notices and seem unavoidable. A good case is parse_url. The point of parse_url is to take apart a URL and tell me the parts. Until recently, the only way to validate a URL was a regex. You can now use filter_var with the FILTER_VALIDATE_URL filter. But, in the past, I would use parse_url to validate the URL. It worked as the function returns false if the value is not a URL. But, if you give parse_url something that is not a URL, it throws a PHP Warning error message. The result is I would use the evil @ to suppress errors from parse_url. Long story short, you get errors on PHP systems. And you don't need to ignore them.

He talks about the two-step process he's upgraded to to help monitor and handle the errors that pop up - an error handler that logs human-readable and json versions of the errors and something like Circonus to do metric tracking. He also mentions some external services recommended on twitter - HopToad and Loggly.

In a new post to his blog William shows you how to create a Popurls clone with the powerful combination of PHP and jQuery. Popurls is an aggregation site with some of the latest news and happenings from all around the web.

Since I have a crazy workload right now, I feel this is the perfect time to write a quick n' dirty tutorial on how to build your very own Popurls. Impress your friends and/or boss with a nifty, hand made news aggregator. Yes, very buzz word friendly.

He uses the SimplePie library to pull in the information from various feeds including Digg.com, Reddit.com, Wired's news feed and Engadget. He shows how to use regular expressions to extract information from the feeds (if they're uncooperative), a bit of PHP to work around potentially empty fields and the full jQuery/HTML/CSS you'll need to make it look more like this

In the latest post to the Development Seed blog Alex Barth looks at some of the thoughts going on behind a replacement for the FeedAPI component of Drupal.

In the last couple months we’ve been driving efforts to bring Drupal's core aggregator up to speed so that we could use it to replace FeedAPI in Drupal 7. After trying to pull through some of the more extensive changes, I have to recognize that in this case the advantages of Drupal core work are not enough to outweigh the disadvantages.

While there was a real need for the update, the support just didn't seem to be there and development of the update slowed to a crawl. Alex notes that the original goals for the FeedAPI updates need to be rethought - don't replace the FeedAPI component, make a true successor instead. There's plenty of comments and thoughts from other Drupal-ers on the post, so read up!

Amit Singh dropped me a note to let me know about a new community site he's developed to share PHP-related resources from all around the web (similar to DZone) called PHPCamp.net.

PHPcamp aims to provide a platform where everyone can bring interesting links, news and share their knowledge that are helpful to other web developers. It provides publishers with a chance to easily show their articles to others and gain some readers; most importantly it provides readers an easy way to keep an eye on latest things in PHP world, at the same time, giving them a chance to learn new things every day.

The site takes in user-submitted articles/blog posts/etc and they're dropped into the "freshly arrived" list for public consumption. If a link gets enough attention, its listed under the "getting hotter" and "boiling" sections progressively. Check out their blog for more information.

Padraic Brady has put together a very comprehensive post on his blog today about using the Zend_Feed component of the Zend Framework to help with the aggregation of content from other sites (like RSS and Atom feeds).

In this entry I explore Zend_Feed from the perspective of someone aggregating RSS and Atom feeds with a view to building a database of uniquely identified content for later presentation in a "Planet" style application. [...] In fact all we create here is a simple command line script to aggregate content frequently (e.g. just set up cron to run it every hour or so) into a database for later presentation.

He guides you through each step of the way:

• Setting Up Database And Models
• The Aggregator Script Foundation
• Using Zend_Feed to get common data for RSS/Atom entries
• Putting It All Together

There's plenty of code (and SQL to insert) in the post and he explains each point well, helping to make the development process smoother. There's even a summary section to toss in a few extra bits of information just in case you missed them along the way.

Cal Evans, of Zend Developer Zone (and PHP Abstract) fame has launched a new site to help PHPers with keeping all of their PHP podcasts in one place - PHPPodcasts.com - an archive site to give people searching for PHP podcasts a "one-stop shop".

phppodcasts.com is not a replacement for any of the existing feeds, it won't be on iTunes because it's not in competition with the owners podcasts. It's an archival site and a place for people to explore the different podcasts available for PHP developers before subscribing to them.

Currently, there's four podcasts under the PHPPodcast umbrella - Zend's own PHP Abstract, php|architect's Pro PHP podcast, the phpBB podcast and the CakePHP group's own podcast, The Show.

Know of a PHP-related podcast that you think should be added to the site? Let Cal know - Cal [at] this domain.