In this new post to his site Matt Stauffer looks at the "higher order messaging" in Laravel's collections as a part of his series covering features in Laravel 5.4.

It seems like it was just last year that collection pipelines took over the Laravel world. Taylor had introduced collections to Laravel a while back but they sat somewhat under-appreciated until Adam Wathan wrote his book Refactoring to Collections about how they can transform the way you write a lot of your PHP code.

In Laravel 5.4, collections got a few boosts. Let’s take a look at a few.

He starts by talking about the higher order messaging design pattern and how it is different than just using something like foreach to iterate through a set. He then applies this to the Laravel collections, showing how they're implemented there via the "filter" and "pipe" methods.

On NetTuts.com there's a recent post that tries to explain the "whens" and "whys" of design patterns - when using them is a good idea and why you might want to implement them as a part of your application.

There are plenty of articles that explain what design patterns are, and how to implement them; the web doesn’t need yet another one of those articles! Instead, in this article, we will more discuss the when and why, rather than the which and how. I’ll present different situations and use-cases for patterns, and will also provide short definitions to help those of you who are not so familiar with these specific patterns.

They've broken them up by topic instead of by the patterns themselves with sections like:

• Finding the Data We Need
• Reusability
• Discover-ability
• Singularity
• Controlling Different Objects

There's also a few sections that look at other patterns that really only have a handful of uses - like the Decorator, State and Composite patterns.

In this new article from Noupe.com they look at a hot topic in the PHP community - frameworks - and give an overview of the features of five popular choices.

PHP is the world's most popular scripting language for many different reasons - flexibility, ease-of-use, among others - but often times coding in PHP, or any language for that matter, can get rather monotonous and repetitive. That's where a PHP framework can help. [...] Frameworks can also help beginners to build more stable apps by ensuring proper database interaction and coding on the presentation layer. This allows you to spend more time creating the actual web application, instead of spending time writing repetitive code.

They touch on why you should use a framework and when are appropriate times to make them a part of your development. They also point out a few common mistakes that are often made when using frameworks like using a framework above your skill level or ensuring that all other technologies will work with your framework of choice.

They finish the article off with a look at the features of five different frameworks:

• Zend Framework
• CakePHP
• Symfony
• CodeIgniter
• Seagull

On the KillerPHP.com website, there's a brief look at design patterns, specifically using them in PHP:

Since the release of PHP 5, the PHP world has slowly started to get into more advanced programming, things like object oriented concepts and the use of design patterns.

Stefan Mischook describes the patterns simply, as nothing more than standardized ways of solving common programming problems. He lists a few of the more well-known patterns and answers a few common questions developers have about them:

• When should you start learning and using design patterns?
• The dark side of design patterns (when should I use them?)
• What can we learn from Java's bad experience?

I love his final comment - it sums the design pattern experience up well:

I am not saying that design patterns are bad, I just think they should be used only in the right context: you don't need an 18 wheeler truck to move a chair...

On the KillerPHP.com website, there's a brief look at design patterns, specifically using them in PHP:

Since the release of PHP 5, the PHP world has slowly started to get into more advanced programming, things like object oriented concepts and the use of design patterns.

Stefan Mischook describes the patterns simply, as nothing more than standardized ways of solving common programming problems. He lists a few of the more well-known patterns and answers a few common questions developers have about them:

• When should you start learning and using design patterns?
• The dark side of design patterns (when should I use them?)
• What can we learn from Java's bad experience?

I love his final comment - it sums the design pattern experience up well:

I am not saying that design patterns are bad, I just think they should be used only in the right context: you don't need an 18 wheeler truck to move a chair...

Des Traynor shares some of his opinions on PHP in his latest blog post - "I hated php back when it was cool".

This is a short smug entry, written in the "Yeah, well I liked them before they even had a record deal" style associated with trend snobs. Except in this case, its the opposite, I am claiming that I hated something back when it was cool. Thanks to blogging my opinion earlier, I even have proof! PHP should stand for Pretty Huge Problem.

He mentions some of the rants, langauge switchers, and general complaints that have come up about PHP, including the combination of code and HTML, the "safe mode" feature, and PHP's "battered on" nature of development. He also goes off a bit on the (inevitable) backlash that Rails and Ajax will see in the future, and wonders how far off it will be.

Des Traynor shares some of his opinions on PHP in his latest blog post - "I hated php back when it was cool".

This is a short smug entry, written in the "Yeah, well I liked them before they even had a record deal" style associated with trend snobs. Except in this case, its the opposite, I am claiming that I hated something back when it was cool. Thanks to blogging my opinion earlier, I even have proof! PHP should stand for Pretty Huge Problem.

He mentions some of the rants, langauge switchers, and general complaints that have come up about PHP, including the combination of code and HTML, the "safe mode" feature, and PHP's "battered on" nature of development. He also goes off a bit on the (inevitable) backlash that Rails and Ajax will see in the future, and wonders how far off it will be.