Continuing on from the first part of their tutorial series about creating a simple ad tracker for your web application, Developer Drive is back with part two, a more in-depth look at the actual object design and code.

In our last PHP Ad Tracker lesson, we constructed the database tables for our ad banner application. Now we are ready to construct the data object that will hold the variables and functions that will display, add, edit and delete the data in those tables.

They cover each of the variables they'll be using with a summary of what they're used for as well as the various functions to be defined and what they'll return. Following this, they get into the actual development - creating an "ads" class and defining the methods to get the current ad count, get the number of clients and pull the actual client/ad data.

In this recent post on Reddit.com, there's some good discussion/feedback about the proposed redesign of PHP.net.

Opinions from commentors range widly:

• "The layout's nice. But those colors are downright disgusting."
• "To be honest, the new version is 100x better."
• "It's definitely way better than the old design but still not exactly great is it?.."
• "Much more profressional. Welcome to the 21st century PHP.net."

Have an opinion on the new layout? voice it here!

In a new post to DZone.com Giorgio Sironi talks about the "open/closed principle" in software development and shows an example based on the design of the PHPUnit_Selenium project.

This article shows an example of how the application of the Open/Closed Principle improved the design of a real project, the open source library PHPUnit_Selenium. These design concepts apply to every object-oriented language, including Java, Ruby or even C++. The Open Closed Principle, part of SOLID set, states that software should be open for extension and at the same time closed for modification.

He starts with a little background on the project, pointing out that there's a Session object it uses for all of its testing with a magic "__call" method that handles any kind of method call to the object. This method has issues (dependencies, strict requirements for use) but can be refactored according to the Open/Closed idea to set up an array of anonymous functions that can be called as a "command". Examples of these types of classes are also included (one for the "click" action on a button and another for getting the current location).

New from the Decal blog today there's a general post about testing, not writing tests for your code but testing methods for your site as a whole (like A/B testing). This is the first part of a series.

For a long time, we here at Working Software have been strong believers in the "content precedes design" philosophy, as famously espoused by Jeffrey Zeldman and summarised here on UX Myths. [...] We are relaunching this website so we'd gone through the process of creating our "content first" wireframe using Decal Mockups.

They go through their entire process - how they decided what to test on the site, the methods they chose for the testing (including PickFu and Feedback Army) and some of the results of the feedback from each.

In a new post to his blog Tibo Beijen presents a case study about doing Domain Driven Design in an application using Doctrine2 to work with objects and your database.

Nowadays developing web applications usually requires a flexible process due to changing business logic, shifting priorities or new insights. Besides choosing the right methodology this also requires designing the application in such a way that this flexibility can be achieved. [...] In this article I will show how to implement a specific case using Doctrine 2. Full code accompanying this article can be found on GitHub.

He starts by describing the entities (User/TimeSheet/TimeSheetStatusChange) and how they're defined in Doctrine objects. He modifies them to build in some business-level restrictions like "status changes are only allowed in a certain order". He shows that the domain models presented are about more than just working with the database tables. They enforce rules that effect the flow of the application as well.

Michelangelo van Dam has posted a new book review today about an offering from from Packt Publishing - CMS Design Using PHP and jQuery.

After receiving the book I started reading it. But right from the start the author displayed bad practices and mis-use of PHP. Reading the book from front to back, the author Kae Verens (@kae_verens) has confronted me with bad use of variables (like $a, $b, $c), bad use of PHP structures and a complete wrong approach of using JavaScript, where JavaScript should enrich an application instead of incorporating business logic.

In his "good" category fell things like the interesting variety of jQuery plugins mentioned and how the CMS example was broken up into easily digestible chunks. Unfortunately, most of the rest of the book falls into his "bad" and "ugly" category" including the structure of the application, the quality of the code and the lack of filtering/validation that was done on input.

Smashing Magazine has posted their latest Upcoming Conferences list for the events happening in March through August of 2011.

We're well into 2011, and many designers and developers around the world are planning their travels for the year, including the possibility of attending any Web design or development conferences. To help you out with your plans for the upcoming months, we've put together a list of conferences and events that you might want to consider. This particular post covers events taking place in about a six month timeframe that ends in late August and early September.

Their list includes PHP-related events such as the International PHP Conference and events surrounding many other technologies like Ruby, Photoshop, MySQL, Javascript and lots of other more business-minded sort of events. Check out their full list to see which ones you might want to attend.

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.

Ralph Schindler has written up a new post for his blog today looking at APIs and some things to consider when building them. These aren't the web service APIs you're thinking of - this is the interfaces your code uses to talk to it's own parts.

It's important to have a common understanding of the actual problem area. When we talk about names, we are really talking about the API. An API is a particular set of rules and specifications that a developer can follow to access and make use of the services and resources provided by another particular software program, component or library. Put another way, it is an interface between various software pieces and facilitates their interaction, similar to the way the user interface facilitates interaction between humans and computers.

He talks about the two different APIs you're usually building at the same time - a consumption API that is the method others use to consume it and the extension API, how the feature allows others to improve upon it. He shares his own API philosophy and a three tips he's learned along the way to make his APIs more robust:

• Adopt A Common Namespace & Class Naming Scheme
• Avoid Doing Too Much In the Constructor
• Avoid final And private

David Gardner has a suggestion for your development that he thinks can help keep things neat and tidy - using interfaces.

This post was sparked by a very simple question from an ex-colleague: "Why bother with PHP interfaces?" The subtext here was that the classes themselves contain the interface definition (through the methods they define) and hence interfaces are not needed, particularly where there is only one class that implements a given interface.

He talks about two reasons he things that interfaces could be beneficial - they help you think about things "the right way" of planning out structure before implementation and that it makes things more "future proof" the code by forcing future elements into the same mold as the current use.