When we write programs, we may often get into a situation where we don't know whether we should use Abstract class or Interface when we want to define an abstract object. These two are very similar and they are interchangeable. On Stackoverflow, this question is asked many times, it's related to many programming languages. Also in the official documentation of PHP regarding the Abstract class and Interface, people are arguing about this. To understand this question, we need to understand their differences and use scenarios.

They provide examples of abstract class and interface usage with one of the main differences being that you can define functionality in abstract classes. There's also examples showing classes that extend the abstract class while implementing the interface at the same time, helping to define the object structure to an even finer level.

You've decided that it makes sense to use a framework when writing your next new application, and chances are that if you're already familiar with a specific framework, then you'll probably be leaning towards using that one when you start. But are you sure it's really the most appropriate for the task at hand? In the name of due-diligence, here are some of questions that you should ask yourself before settling on a particular framework to make sure you're not programming "against the grain" and also to make sure it will be able to meet your needs now and in the long-term.

He doesn't get into any specifics of any PHP frameworks out there, but suggests general questions to ask even before getting too deep into the technology:

• What do I need from the framework?
• Do I expect the framework to help manage consistency?
• Is good documentation available?
• Is the framework actively developed, and does it have an active user base?
• Does the framework work in what I run in production?
• What business factors are influencing my decision?

Not every application needs to be written using a framework. But if you've decided that yours does, then it's beneficial to compare your needs against the features and benefits of the various framework offerings.

Developers like to think that companies hire developers to write code. But companies do not hire developers to write code; they hire developers to solve problems. They hire developers with the expectation that the developer knows about, or can learn about, the problems of the company, and find a creative solution to those problems at minimal cost.

It is therefore up to the developer to choose what tools they will use to achieve the outcome. The customer doesn't much care what tools the developer uses; they only care that the outcome they desired is achieved.

He goes on to talk about preferences in the tools "used by craftsmen" and why they're less important than the result of the work they create. He notes that languages matter, but only in a certain context - as a piece of a puzzle, a part of a whole to reach an objective of functioning software.

What is it you do as a developer? As I see it in web dev there are a few different types: Hobbiest, Client Web Dev, Distributed Application Devs, Web App Developer (SaaS) and Corporate Dev. What do they all have in common? They're all using some sort of language to make some sort of system for somebody somewhere. That is about the last connecting factor that most of us developers actually share. [...] The crazy thing here is that most developers who are in a situation where they can use whatever system they like, often end up picking a specific tool and using it to death. This is ridiculous, as every developer should use the best tool for the job.

He talks a bit about each of the different categories of developers and where he sees their place in the world of development. He points out some of the restrictions of each type of position (required technologies, dependencies, etc) and comes to his point about their choices:

The point I am trying to make in all of this, is that while you might have really strong opinions about what language, framework, version of the framework or version of the language you use, EVERYONE has a totally different situation to you.

Each of them has its own advantages and disadvantages so the project's requirements, development environment and team members receptivity should be taken into consideration. Relying on my own experience in project management and using version control systems to manage the development process I've formed the conclusions listed below that may be helpful while considering usage of one of described SCM's in your own projects.

He talks about how the size of the project can effect the decision and a bit more detail about what each of the version control systems are good at. The PHP project itself has recently made the shift to git away from Subversion (you can find more information on the PHP.net site).

I recently read Kevin Schroeder's blog post about 10 Reasons To Use PHP. Then -- silly me -- I started reading the comments. It only took a few before the obligatory anti-PHP hater came out and started insulting the language and the people who use it. That made me think about why that hate exists.

He points out that some of it probably has to do with people not really understanding what PHP is all about (no, reading a blog post dosen't make you an expert on it) and mentions PHP's dynamic typing as a sticking point with several developers.

Usually someone hating on PHP does so because they don't understand it, are upset by what it lets people get away with, feel it makes it too easy for someone to earn the title of "developer," or because they're dicks who have to insult other people because they can't simply be happy with their own choices.

A standard select list can be created using Symfony's choice field type; it is pretty clear how to create a new choice field with simple, non-dynamic options (e.g. gender), but it gets a little more complicated when you want to create and validate a dynamically generated choice list.

He includes the code for a simple entity, a Post model to fetch the category information and the set up of the form element - a select list of post types/categories. He also includes a bonus section showing how you can achieve the same thing without a model to bind to. The code's a little bit more complex than the previous example, but it's basically just reproducing some of the validation and fetching logic manually.

Back in the Fall of 2010, we needed a new PHP framework for our applications. Neither of our applications - Newscoop or Airtime - had anything that could really be called a framework, though our code was generally separated into Models, Views, and Controllers (MVC). But it wasn't pretty. We were in need of an established MVC framework to build on.

They tried out several different frameworks including Yii, CakePHP, Kohana, Symfony and, of course, the Zend Framework. They talk briefly about their evaluation process and some of the pros and cons they found along the way.

Overall, using Zend has helped us to create clean, structured code and for most cases has lowered our implementation time for new features. [...] Even though there are some things that could be better, the net benefit has been positive for us.

Continuing with our best-five-book series, today we are introducing our pick of the top 5 PHP books. Obviously, PHP has been around much longer than our other review subjects such as Android or HTML5, and there is a greater general variety of books to choose from.

Their list of top five covers a pretty good range of skillsets, but leans more towards the introductory level:

• Professional PHP6 (and yes, they mention that the title is "blatant false advertising" since PHP6 is nowhere to be found)
• Learning PHP, MySQL, and JavaScript: A Step-by-Step Guide to Creating Dynamic Websites
• PHP Solutions: Dynamic Web Design Made Easy
• Beginning PHP and MySQL: From Novice To Professional
• Head First PHP & MySQL

One of the difficult parts of framework adoption, especially in the PHP world, is about choosing the right framework. There is a proliferation of open source solutions and a team must analyze the overall picture thoroughly before locking itself into a particular framework. Changing the framework which an application is built with without shaking its foundations would be probably impossible after a certain period of development.

He lists a few of the things he looks for in a framework - functionality, performance, community and a good license - and asks for some feedback (in the form of a poll) as to which you'd prefer to use next. He's narrowed it down to four options: Zend Framework, Symfony, CodeIgniter and CakePHP. (Expect plenty of comments asking "what about [insert framework here]?")