In the most recent episode of the North Meets South podcast - Episode #28 - hosts Jacob Bennett and Michael Dyrynda talk about Laravel. More specifically they cover Eloquent functionality, client expectations, and packages.

In this episode, Jake and Michael talk about Eloquent observers and answer listener questions about managing client expectations and packages we use in our Laravel applications.

Other topics mentioned in this episode include Dash (the documentation tool), the "Supercharge Your Tinker Workflow" article and the Sentry package for Laravel. You can listen to this latest show either using the in-page audio player or by downloading the mp3 directly for listening offline. If you enjoy the show, be sure to subscribe to their feed and follow them on Twitter to get the latest updates when new shows are released.

For those that might be new to development, the concept of "design patterns" could be one you're just approaching. These common practices define some "patterns" of development that have been proven to provide good structure and maintainability to applications...when applied correctly. PHPBuilder.com has an introductory article showing you how to use five of the most common patterns: Factory, Singleton, Observer, Chain of Command and Strategy.

Design patterns provide a generic reusable solution to common problems. A design pattern is not a concrete solution that can be converted in to source code or a machine code rather it is a template which can be used to solve a problem in different situations. Design patterns help in faster development as the templates are proven and from the developer's point, only implementation is required. Design patterns not only make software development faster but also encapsulate big ideas in a simpler way.

For each of the patterns represented a brief description is included and some sample code is given showing it in use. There's not too much depth in this post, so if you're looking for more "meat" on these patterns, I'd suggest checking out some more advanced articles on SitePoint.com.

Kevin Schroeder has posted a step-by-step guide to his site today about creating a module for Magento in the first of a series of posts about Magento.

I believe that one of the best ways to learn something is to write out what it is you are learning. This forces you to think through the concepts and determine how to explain them to others. In doing so you are forced to use terms that are familiar to describe this new thing. This helps to solidify the concepts in your own mind, making it easier to remember. But still, there are three caveats: Magento 2 is not out yet, I'm learning as I write and what I share is what I see (my interpretation).

He talks about some of the differences between Magento 1 and 2 including:

• The lack of code pools
• Discovery XML files are in a different location
• A different parser for these XML files

With all of this configuration and location information covered, he gets into the actual module building. He makes a simple "Hello World" module with a module.xml, event.xml and an Observer that handles sending the text back to the waiting application.

In this new tutorial on PHPMaster.com, Alejandro Gervasio looks at the Inversion of Control methodology and how it's more than just an abstract reference to dependency injection.

Traditionally, application components have been designed to operate on and control the execution environment, an approach that delivers well to some extent. [...] Instead of making the module completely responsible for logging data to multiple endpoints, we can transfer the responsibility straight to the external environment. [...] Not surprisingly, the process of inverting these responsibilities between components and the environment is formally known as Inversion of Control (or in a more relaxed jargon, The Hollywood Principle), and its implementation can be a real boost when it comes to developing extensible, highly-decoupled program modules.

He uses a set of domain objects (Posts and Comments in a typical blog structure) and the Observer pattern to show how mixed up things might get if the application isn't carefully coded. He takes this and updates it to include a "comment notification service" that implements the SplObserver and is attached to the post to be executed on an event (in this case, the setting of a new comment).

In this recent post on the Zubma Fitness Engineering site, Chris Saylor looks at using events in your applications to hook in plugins to easily (and dynamically) enhance functionality.

In many instances, having a plugin system (even for closed-source applications) is a convenient and safe approach to adding functionality to a product. It minimizes risk by not having to modify the core of the source. In this article, I’ll be discussing how we implemented a plugin system for our cart software to allow for plugins.

Its implemented a bit like the Observer design pattern - you "register" the listening event which can then be activated by a "trigger" method with the event's name. These events are stored in a registry (static) so they can be accessed across the application.

On the PHP-Tip-a-Day site today there's an new "fable" posted in the Design Pattern Fables series. This time it's about the Observer pattern (and kings and princes).

The first place I recall encountering the observer pattern was not in PHP, but in JavaScript. If you've ever set a listener to fire when an event happened, you've used the observer pattern. Functions or methods are registered with an object so that when it experiences a specific event, it "notifies" the registered functions or methods by calling them.

His story tells about a royal family, a pregnancy and magic mirrors that allows for instant communication between the family and outlying locations. He relates it to the objects and "watchers" that make up the Observer pattern and gives a brief code example (in Javascript) of a HTML button and a jQuery event observer that fires when it's clicked.

Anthony Ferrara has a new post today looking at plugin handling and a few of the more common design patterns that can be used to implement them in your applications.

A common problem that developers face when building applications is how to allow the application to be "plug-able" at runtime. Meaning, to allow non-core code to modify the way an application is processed at runtime. There are a lot of different ways that this can be done, and lots of examples of it in real life. Over a year ago, I wrote a StackOverflow Answer on this topic. However, I think it deserves another look. So let's look at some patterns and common implementations.

The patterns he covers are:

• Observer
• Mediator
• Strategy
• Decorator
• Chain of Responsibility

For each there's both a bit of sample code showing it in use and links to some examples from various frameworks and other projects.

PHPMaster.com has a new tutorial looking at another popular design pattern, the Observer pattern, and sharing some example code putting it to use. (Their other design pattern articles include ones on command and factory patterns).

In this article I’ll show you how to implement the Observer Pattern. You’ll learn how various classes in the pattern relate to one another as subject and observers, how the subject notifies observers of a change in its state, and how to identify scenarios where it would be suitable to use the Observer Pattern in your own code.

The introduce the pattern by using an abstract "Observer" and "Subject" (that defines "attach", "detach", "getState", "setState", "notify" and "getObservers" methods) observer classes to coordinate the attached classes. They extend these classes with "Auth" and "Auth_ForumHook" show how to attach the "Auth_ForumHook" classes to the main "Auth" observer manager and change the state of the observer to notify it of an update.

You can find a more detailed explanation of the Observer pattern on Wikipedia.

Fabien Potencier has posted the ninth part of his "build a framework on Symfony2 components series. In this latest tutorial he takes the simple framework he's already created (complete with some unit tests) and makes it easier to extend.

Our framework is still missing a major characteristic of any good framework: extensibility. Being extensible means that the developer should be able to easily hook into the framework life cycle to modify the way the request is handled.

He chooses the Observer design pattern as a basis for his example, allowing any kind of behavior/actions to be added to the framework's execution. He includes the Symfony2 dispatcher to make this work and includes the code for a "handle" method to fire off events. It executes a "ResponseEvent" every time the framework is executed. An "addListener" method provides the hook to apply a callback to an event - in his case an anonymous function (or closure).

Tom Rawcliffe has posted the latest in his design patterns series covering some of the most common patterns and how they would work in PHP. In this new post he looks at the observer pattern.

So far in my series of articles on design patterns in PHP we’ve looked at a creational pattern, a structural pattern and a behavioral pattern. Today I’ll be taking a closer look at another behavioral pattern - the observer. The observer pattern (also known as the Subscribe/Publish Pattern) is used to notify one object, the observer, about a change of state from another object, the subject.

He gives the layout of the pattern in a simple UML diagram before moving into the description and code. His sample builds a Users object that has a set of observers on it. His custom observer is a logger that, when a change is made on the Users, it writes out a value of the current object.