Matthias Noback has posted about CQRS (Command Query Responsibility Segregation) on his site showing how to reduce coupling and let the "model(s) evolve" that tries to break down some of the perceived complexity around the design technique.

CQRS has some reputation issues. Mainly, people will feel that it's too complicated to apply in their current projects. It will often be considered over-engineering. I think CQRS is simply misunderstood, which is the reason many people will not choose it as a design technique.

[...] CQRS alone simply means that you're making a distinction between a model that is used for changing state, and a model that is used for querying state. In fact, there's often one model that accepts "write" operations (called "write model" or "command model") and multiple models that can be used to "read" information from (called "read models", or "query models").

He goes on to talk about the more common structure in applications, a single model that handles all of the usual CRUD operations rather than having it split up. He then moves on to the topic of coupling and reducing it through the use of read-only models. He shows examples of the code for these models as well as tips for dealing with inconsistent data.

On the SitePoint PHP blog Timothy Boronczyk has a new post trying to predict the future of PHP and where the language might be heading:

As developers, we find ourselves living in exciting times. With increasing attention paid to online activities, we’re working with larger data sets (even “big data”); scalability and connectivity are more important than ever before; the very nature of privacy is being re-examined. But quietly, in the shadow of all of this, sits perhaps a more pragmatic question. How will PHP change and grow to enable us to build the future, whatever it may hold?

Among the things he proposes are ideas about future versions with double-digit minor release numbers, less frameworks and more meta-frameworks, the introduction of lots of new extensions and the adaptation and positive outlook for a thriving, constantly improving web-centric language.

In a new post to his site Igor Wiedler looks forward and suggests some alternate syntax for PHP based around the idea of macros from Lisp. These macros would be parsed at runtime and handled directly as code, compiled down from their custom format.

A very common problem that many software projects have is lack of adoption of new versions. Browsers are an excellent example of this, But it exists on the server as well. [...] This leads to this recursive problem of hosting companies not upgrading because they don't have to, and software not requiring newer versions of their programming language, because they don't want to lose their users. The longer your dependency chain is, the more you suffer from this.

He points out that the easier it is to update these lower level pieces, the simpler it is to introduce new things into your system. He suggest that macro-like functionality for PHP could aid in this goal. He talks some about backporting features and how these marcos could make it easier to upgrade just the things we wanted (or all of them) without having to upgrade PHP itself. He even went so far as to create a tool (galapagos) that does this kind of parsing. His examples implement the 5.4 features of short arrays, $this in closures, function array dereferencing and callable typehinting.

Being able to invent your own syntax is very useful, which instantly becomes apparent when you look at the past. Features get added to languages all the time. What if you could do that easily, within minutes instead of months?

Dave Marshall has posted part three of his series looking at how to land that perfect PHP job. In this part he focuses on the resume/curriculum vitae - often times your first impression to a potential employer.

In part two of this series, I discussed the technical know how I think will help get you your next PHP job. This part will discuss writing your Curriculum Vitae(CV, resume, etc.). There are a lot of contrasting opinions on this subject, I’ll make a few points, give you some further reading and you can adapt the opinions in to a top notch CV of your own. I’m no major expert and most of the recruitment I have been involved in has been for trainee developers, but these positions attract a high number of CVs, so I’ve seen a fair few.

He includes a few helpful hints like "Your CV does not get you a job", "Don't stuff your CV with keywords/acronyms" and some tips on formatting and proofreading.