In his latest post Coen Jacons suggests that updating PHP is everyone's responsibility - that keeping the PHP installation on your systems up to date is important for everyone, not just the system administrators.

The number one remark I heard when I launched WPupdatePHP, is that users shouldn’t be bothered with this. In an ideal world, this is true, but in reality this isn’t going to stand for long. [...] I know the WordPress core team is working really hard to get webhosting companies to update their PHP versions and I agree up to a certain level that this is the best way. It’s not the only way though. [...] This will help lower the percentage of PHP 5.2 and 5.3 users out there. There still will be people on older PHP versions who are caught out and without them knowing what is going on, nothing will change for them.

He talks about the efforts the WordPress core team is doing to try to convince hosting providers to update, but points out that while WordPress aims to run on those old versions, staying on them is a mistake. He also mentions that an effort like this is a constant thing, always changing as the PHP versions released change. He ends the post with a "call to arms" for users out there, encouraging them to get talking to their hosting provider and get those PHP versions updated.

Don’t understand me wrong, I like what WordPress is doing to get these requirements bumped, but I think it’s not enough. I disagree on the fact that users shouldn’t be involved in this. It’s easy enough for users to request their hosting platform to be upgraded. If their request isn’t heard, they should find a better webhosting company. [...] It’s been long enough, I choose to act now.

Mathias Noback has posted another in his series looking at the concepts and implementation of command bus handling in PHP. In this new post he looks at some of the responsibilities of the bus and provides a few examples to help drive the point home.

In the previous post we looked at commands and how you can use them to separate technical aspects of the input, from the actual behavior of your application. Commands are simple objects, handed over to the command bus, which performs the change that is needed. [...] So the command bus contains some kind of a lookup mechanism to match commands with their handlers. Some command bus libraries use a naming convention here (e.g. handler name = command name + "Handler"), some use a kind of service locator, etc.

He starts off talking about the main point of the article, giving an overview of what he sees are the basic responsibilities of the command bus. He also sheds some light on methods he's seen for keeping it from becoming a "big inarticulate unmaintainable class". He then gets into his two examples: database transaction handling and protecting the original order of commands. He shows how his SimpleBus package handles most of this for you and shows how it follows the "chain of responsibility" design pattern to make it work.

NetTuts.com kicks off a new series of posts today with this first article covering the SOLID development practices. SOLID is a set of principles that can help make your code more robust and well structured in the long run. In this first post they jump right in with the first letter - "S" for Single Responsibility Principle.

[The Single Responsibility Principle] is one of the five SOLID agile principles. What it states is very simple, however achieving that simplicity can be very tricky. A class should have only one reason to change. But why? Why is it so important to have only one reason for change? [...] Even though you may not use a compiled language, you may need to retest the same class or module for different reasons. This means more QA work, time, and effort.

They go on to talk about how to figure out the "audience" for your class and how that effects what it should contain. A few "class examples" are shared in the post including objects that can print or save themselves. There's a bit of talk about software design ideas to consider and a less obvious example that might be breaking the principle (and how to fix it).

In this recent post Brandon Savage suggests that just using objects in your application doesn't mean that it's truly "object oriented development." There's other criteria that need to be met to really fit this description.

Lots of developers understand that object oriented code offers advantages over procedural programming. And so, they begin working on creating objects in their own projects, and eventually feel pretty good about what they’ve done. After all, if they’re using objects, their code must be object oriented, right? Well, not exactly.

He breaks it down into three main points that developers should consider when working with OOP in their apps: splitting responsibilities between classes, being polymorphic and using dependency injection. There's no code samples to back up the concepts here, but it's a decent list to think about. There's plenty of tutorials out there about SOLID development and dependency injection in PHP apps, so you might check some of those out to help with these concepts.

In this recent post to his site Phil Sturgeon has a reminder that you should select the dependencies for your packages wisely, and not just because they're "cool."

When I say "make sure it is worth it" I mean, don't just switch your arrays from array() to [] just because it looks cool. That was the extent of my original tweet, because I've seen a few packages doing that and it annoyed me immensely. [...] Suffice it to say, if you require a user to upgrade their version of PHP simply so you can use some syntactical sugar inside a package that nobody else is even going to be looking at, then you're an idiot. Beyond that, you're actually hurting the community.

He notes that, by requiring users that are currently only at 3.1% of PHP installs to upgrade to 5.4 just to use your library is a quick way to not have your library used. He points out that PHP 5.4 is "more than just []" for arrays and includes a reminder that several projects are still in PHP 5.3-compatibility mode just because that's the widest audience. He also briefly touches on the "push it forward" comments that people have used to justify 5.4-only packages, but notes that it's still not as much up to the developer as it is the web host.

In a recent post to his site, Brandon Savage has a few helpful hints to keep in mind when you're refactoring your applications to make them easier to maintain (and possibly perform better) in the future.

The downtime [of this week] provides a perfect opportunity for the aspiring software developer to do the one thing they are always told there’s no time to do: make the code better for better’s sake. With few deadlines and plenty of free time, most developers can get a few hours of refactoring in to their code towards the end of the year. They can rearchitect sections that were implemented with haste in September; they can write tests for sections that were untested in April. Put another way, the “lost week” can be redeemed.

He has a few recommendations, each including their own brief summary:

• Test Everything First
• One Method, One Job (Also One Class, One Job)
• Don’t Be Afraid Of More Objects And Classes
• Remove Dead, Unused, Unnecessary or Old Code
• Document Your Code

Check out the full post for the summaries and links to other useful resources.

On PHPMaster.com today Alejandro Gervasio has a new tutorial posted about the Single Responsibility Principle - a guideline that states that each class should only have one "area of concern" and not try to do to much.

One of the most notorious consequences of this rational associative process is that, at some point, we effectively end up creating classes that do too much. The so-called “God class” is quite possibly the most extreme and coarse example of a structure that packages literally piles of unrelated operations behind the fence of the same API, but there are other subtle, more furtive situations where assigning of multiple roles to the same class are harder to track down. [...] What the principle attempts to promote is that classes must always be designed to expose only one area of concern and the set of operations they define and implement must be aimed at fulfilling that concern in particular and nothing else.

He starts off with a typical violation of the principle, showing a class that not only handles user data but also includes the functions to work with the database directly as well (insert/update/delete). He refactors this into a few much more manageable classes - a mapping class to handle the database interaction and a "User" class representative of a true user object.

In this new post (and this related article) Pádraic Brady shares some of his opinions about default security languages should provide and the Secure by Design principles.

Odd though it may seem, this principle explains some of PHP’s greatest security weaknesses. PHP does not explicitly use Secure By Design as a guiding principle when executing features. I’m sure its in the back of developers’ minds just as I’m sure it has influenced many if their design decisions, however there are issues when you consider how PHP has influenced the security practices of PHP programmers. The result of not following Secure By Design is that all applications and libraries written in PHP can inherit a number of security vulnerabilities, hereafter referred to as “By-Default Vulnerabilities”.

He focuses on what he sees as a responsibility of those creating the language to either default to a more secure architecture or provide information as to why their choices could cause problems. In the extended version of the post, he talks about some specific issues that the language has including SSL/TLS misconfiguration, openings for XML entity injection attacks and limited native filtering for cross-site scripting.

Freek Lijten has written up a new post to his blog about a set of development principles that have been getting more press in the PHP community lately - SOLID. In his post he starts with a look at the "S" in the set - "Single Responsibility".

The single responsibility principle isn't all that hard to explain. It states that an object should do one thing, and one thing only. [...] A responsibility is a reason to change, and a class should only have one of those. Now all of this may sound abstract and since the objective of this series is to avoid just that we'll just dive into the why now.

He includes some sample code to illustrate, going with an active record implementation, some of the problems that come with a typical setup including issues with unit testing, bad practice of using the data store directly, etc. He shows a refactored code example that splits out the functionality previously all in the one class ("Bike") into three different ones - one is the normal Bike object, another compares the Bikes and the third works with the data store to handle the CRUD for the objects.

Cal Evans has a suggestion for all of the developers out there not happy with decisions being made at their workplace (or in the contracts they work with) - man up!

Look, it's easy. As developers, we see people we don't respect making decisions we don’t agree with. I know how difficult this position is because like every other developer in the world, I've been in this position. However, unlike a lot of developers I've talked to in recent years, I don't see "digging my heals in" or whining as alternatives.

He suggests one of two alternatives to the situation - either deal with things head-on and get onboard with the decision or jump ship and find something else that suits you better. Sometimes this is a bit easier than others (terminating contracts versus leaving a full-time job), but if you're really that upset with it, it's probably not going to get any better.

talk to a lot of people about how to build teams and the cornerstone of any good team is respect. Management has to respect developers and I firmly believe that. However, you as a developers, have to respect management as well. It is a two way street.