Paul Jones has a new post today looking at the disconnect in the term "quality" that there seems to be between the ones developing the code and the ones paying for the end result.

Recently, I was pondering why it is that programmers and employers have different attitudes toward the quality of the projects they collaborate on. The people who do the work are usually the ones who care more about quality. Why? [...] The people who are paying for the work care much less about quality. Why?

He touches on some of the answers to the "why" questions above and points out that it's not so much about the care one has over the other on quality. It's the differing definitions of quality they both have on the parts they work with.

Kevin Schroeder has posted some of his thoughts how how you, the one looking for good PHP developers, can really get the best talent out there you can find based on his experiences in interviewing other developers.

I can interview for certain (but by no means all) PHP positions because I know a fair about PHP and I believe that being smart but being an asshole does not make you a good PHPer. But not everyone who interviews knows that. And not only that, it is getting difficult to find good PHP developers. A lot of the good ones are being taken up by top companies, but even they are having trouble finding all the good developers they need.

He suggests coming up with something a bit more concrete than just this vague picture of what a "good PHP developer" is and how, even once that's defined, the quality of all developers should be raised to that level. He asks for some feedback on a few related questions like: is there really a shortage of good PHP developers or what are the significant topic areas that PHP developers should know well? Lease him some feedback on the post.

In a new post to his blog Matthew Turland takes a look at one of the concepts it's more difficult for those new to the Zend Framework to wrap their heads around - models.

A question that frequently comes up in my interactions with other developers about Zend Framework is how to approach designing models. There's a small collection of resources and advice that I generally give on the subject, so I thought I'd write up a blog post to give people an easy place to access it all.

He talks about the "correct" way to create a model - guess what, there's not one - and some suggestions of other resources that can give you some suggestions. He both defines what a model is and mentions a few things to consider in your development:

• data encapsulation
• handling dependencies
• defining default adapters to make access simpler

On the Blue Parabola blog today Keith Casey looks at a term that's become more and more ambiguous in the software development world and means so many things to so many people. He thought he'd set the record straight with some criteria he thinks makes the position of "senior developer".

In recent weeks, I've spoken with a number of people about developers. About hiring them, firing them, training them, promoting them, and generally everything revolving around getting or having good people for a team. And one of the odd things that struck me is that: Every organization defines "Senior Developer" completely different and sometimes contradictory ways.

He's not talking about the little things so much as the responsibilities and expectations the company places on this senior level role. Some of the things he suggests to look for include:

• a good amount of experience
• basic project/time management skills
• that they're a good communicator
• a bit of mentoring tossed in too

A Senior Developer - either in name or in responsibility - is often the same as a Team Lead. This person must be effective both on their own and on a team. They have to report up to the Project Manager (or higher!) and lead the rest of the team.. and sometimes even coordinate and collaborate with other teams horizontally.

In this new post to his KillerPHP blog Stefan Mischook takes a quick look at professional programming and what separates professional programmers out from the rest.

I recently got an email question put to me by someone wanting to know what makes a professional programmer. [...] A good programmer is able to put out clean code that works and is easy to update. Simplicity is a sign of professionalism in any profession or discipline.

He goes on to talk about some of the things a programmer should learn to help them move towards that "professional" status including object oriented programming, design patterns, MVC frameworks and getting in "under the hood".

Cody Taylor has a quick post to his blog about bit checking in PHP:

PHP makes life a lot easier for quick or dirty maintenance scripts, cron jobs or web applications but how does it do for older, not so straight forward problems dealing with bits and bytes? I was surprised how easy it was to manipulate bits in a byte with php. Here is an function that made my life a fair amount easier when having to check for a specific bit in a byte.

The function takes in the value and, after casting it to an int, checks to see how it compares to eight and returns it. This result can be passed through decbin function for output. A handy table of the bitwise operator definitions is also included.

In a new post to his blog, Tobias Schlitt takes a look at frameworks - no, not any specifiy ones - and defines more of what a framework is and how you can create something that fits into this "more correct" structure.

I attended the talk Framework? No thank you, I will use my own!, this week at IPC 2009 SE. The idea of the session was to get a discussion running about if you should use one of the many existing OSS PHP frameworks out there, or if you go better with building one on your own. [...] The result was quite obvious for many reasons already beforehand: Use an OSS framework! While I fully agree with this result, I stated a somewhat controversial thesis right at the beginning of that talk, mainly to get the discussion running.

Tobias looks at the official definition (via Wikipedia) and looks at how that compares to the more specific definition of a software framework. He talks about creating a framework - not from scratch but possibly standing on the shoulders of another OSS framework.

On the Blue Parabola blog, Matthew Turland takes a look at object-oriented programming and what core concepts lie at its heart.

What is object-oriented programming? The acronym OOP has become a bit of a buzzword in the current age of programming, to the point where the waters of its definition have become rather murky. [...] PHP may not be object-oriented, but from a purist perspective, neither is Java. What do I mean by "purist perspective?" Plain and simple: everything is either an object or a message being passed between objects (where message parameters are also objects).

He mentions one of the first languages to support objects (Simula) and the four fundamental concepts that would make a language truly OOP - abstraction, inheritance, encapsulation, polymorphism. Its his opinion, though, that while its good for languages to adhere to these four principles as much as they can, discussions about how well they adhere to them is usually just "spinning your wheels" and don't have much use.

On the Ibuildings blog there's a new post that looks at the "evils" of a crucial part of many web applications - caching.

Recently a colleague stated that in theory, caching could be considered 'evil'. Now 'evil' is a very broad term which is used a lot in the IT community, but what does it really mean when we're talking about technical solutions? I asked around, but couldn't find a clear cut definition, so I went searching...

In his search he came across a wide range of definitions, including one mentioning bad design or implying a lack of goals with a summarized meaning of "does harm to your aesthetic and engineering judgment". He applies this to caching and, because of it being a sort of counter-intuitive way to handle content (not just the pull and push), it could be considered slightly evil. Interesting interpretation...

However, as anyone will tell you caching is a very necessary evil. [...] So while it does some minor harm to aesthetic and engineering judgment, the user gets a fast experience, which is really all that matters in the end.

On his blog today, Vinu Thomas has an example of what he calls a "quicker and cleaner form" using the Zend_Form component of the Zend Framework.

Usually handing forms involves coding the form in HTML and performing client and server side validation, which usually makes the code for complex forms quite unwieldy. Zend_Form which is available in Zend Framework version 1.5 aims at simplifying this process.

With this new version comes the ability to add in methods for validation right into the form definition. His example shows a traditional login form that checks things like if it's required, checking the length and adding filters to modify the input.