On the Ez.no blog there's an interesting post comparing PHP and Symfony to Java and some of their own reasoning behind the choice of one over the other.

We are often asked, especially from our enterprise customers at financial institutions, why we decided to go with PHP and Symfony instead of a Java framework. And as we have actually re-considered alternatives both in 2007 and 2011, we know the answer pretty well. We also know firsthand how much PHP and the PHP ecosystem has matured and progressed the last few years, how Symfony2 and Composer provided a big jump forward, how PHP v7 and Symfony3 is positioned to provide the next, in the end making us very confident in our choice and in recommending it to others.

They then talk about some of the arguments of PHP versus Java, some that are pretty familiar to those in the PHP camp:

• PHP is "just a scripting language"
• Java is more scalable
• PHP's performance is bad in comparison
• Poor tools support for PHP

For each of these they link to more information and describe the current state of PHP and its ecosystem to help refute the claim. They then get into the Symfony portion, comparing it to similar Java frameworks, listing advantages like the large pool of Symfony developers and its vibrant community.

In a recent post to his blog Anthony Ferrara takes a look at what he calls the "Framework Fixation" anit-pattern - that one of the first inclinations he sees is to use a framework when it may not be needed.

In this day in age, it seems that the community trend is completely and unequivocally trending towards the use of web application frameworks. So much so that the defacto first comment to someone asking how to do something seems to be "Just use a framework, and it'll solve the problem for you." While I completely understand why this is the case, I can't say that I agree with it. And while I do believe that frameworks serve a purpose, I think that they are vastly over-used. Let me explain why...

He starts off by describing what a framework is (its components, goals) and points out a few flaws in their use. These include the removal of emphasis on the setup/configuration/bootstrapping of the application (it's part of the architecture too!), how they can help (and hurt) in prototype situations, the myth of the shorter development time and that looking for "framework developers" that only know how to use the tool could hurt you in the long run.

In this recent post to DZone.com Giorgio Sironi looks at duck typing and compares it in a few different languages (PHP, Ruby and Java). "Duck typing" is where the methods/functions define the structure or common interface rather than being functional.

What follows is my experience with Java, PHP and Ruby. I mainly use PHP as a dynamic language that supports duck typing but also the definition of Java-like interfaces, but does not force any of the two approaches as you can define interfaces whose method arguments accept any variable or not using interfaces at all. Is duck typing that a revolution?

He shares some of the common misconceptions he's seen including the idea that duck typing can help completely different objects work together and that, sometimes, despite naming conventions, functionality was intended to be different. He shows how even interfaces in PHP can be implemented loosely and the "acts as" and "single callback" architecture ideas.

On the PHPClasses.org blog there's a new post that tries to right some wrongs about how people think about PHP. Maunel Lemos looks at some of the misconceptions people have about the language and the truth behind them.

PHP is often a misunderstood language by people that either love or hate it. [...] This article attempts to clarify some of the most common wrong ideas that many developers have about PHP. Read the article to the end, so you may eventually start having a better perspective about PHP and take advantage of the opportunities that this language and the PHP ecosystem can provide you.

Among the misconceptions on the list, there's things like:

• PHP cannot do X (access memory, control hardware devices, or some unusual purpose)
• PHP is controlled by only one company (Zend)
• PHP is worse than Ruby On Rails, Python Django, X language Framework
• PHP is not good for high performance scalable Web sites or applications
• PHP developers are cheaper because they are not qualified

Iwan Luijks has a recent post to his blog trying to dispel some of the myths and misconceptions about becoming a certified ZCE through Zend's testing. He also includes some of the benefits of having the certification to go with your name.

In the community of PHP developers there are more non-certified professionals than certified professionals. PHP developers mostly don't really see the pro's of getting certified. These developers mostly honor the fact that PHP is a quick and easy language to learn and to get started with, and professionalism is found even by building a simple dynamic web page, leaving the discussion of whether this is a good or bad thing for what it is.

He talks about the confidence it can give current (and future) employers in your skill level and let them know you're the kind that keeps on learning/improving in your career. It also lets them know that you're dedicated enough to learn what you need to pass and can put it into practice easier in the future.

In a new post to his blog today Jordi Boggiano talks about a task that can trip up some developers when they're trying to secure parts of their site or just create one-time use tokens - making unpredictable hashes.

If you [override the default session handlers], unless you want to entrust PHP's core to do it, one thing you will have to take care of is generating unique session ids to send as a cookie to your users, allowing the session to persist. Other common use cases for such unique hashes is to generate CSRF tokens to insert in forms or URLs, and finally authentication tokens for email validation or such.

He talks about how we, as humans, aren't very good at figuring out true randomness and that hashing the information only adds to the problem. He mentions how some of the random functions in PHP aren't all that random and that there's a better way to really generate good values. He's come up with a solution (his "generateUniqueId" function) that tries to generate entropy from OpenSSL or from the COM extension or from the "/dev/urandom" on unix-based systems. It's then hashed and sent back out the other side for easy use.

Alvaro Videla has submitted a new post from his blog today that looks at caching in PHP applications, specifically with APC or memcached.

Sometimes when talking with developers I see that there are some misconceptions regarding this two caching systems. That's why I'd like to share some concepts I've learned along the way.

Alvaro looks at both technologies and describes what they're good at and two of the main misconceptions about them - that APC doesn't mean caching data and that using memcached isn't faster than working with local values (you still have to make the TCP round trip).

From the SellMix blog today there's a new post with a few "no-nos" and misconceptions when it comes to working with PHP in your applications.

We have all had that moment where we looked back on a script that we wrote years ago and thought "what the hell was I thinking?'". But it is a process. You make mistakes, you learn from those mistakes and then you move on. From my experiences of modifying other people's code, helping people on PHP help forums and making my own (many) mistakes, I hereby present this list.

There's eleven points included in the list, touching on things like:

• Superglobals being referred to inside class functions
• MySQL queries inside loops
• Brackets '" use them.
• Indent, indent, indent!
• Why are you using mysql_fetch_array?

Check out the rest of the post for more tips.

In a new post to his blog Johannes Schluter recommends that you don't use references in your applications, mostly because of some misconceptions about how they work.

Last year I spoke at eight conferences and attended a few more multiple times at most of them I found myself in discussions about references and PHP as many users seem to have wrong understandings about them. Before going to deep into the subject let's start with a quick reminder what references are and clear some confusion about objects which are "passed by reference."

He re-introduces referenced variables and scratches the surface about the confusion they can cause, not only on the user level but also in the internals of the language, and can lead to some unexpected results. He also mentions the "always passed by reference" idea that several PHPers have about PHP5 objects and why it's not entirely correct. He finishes off the post with a look at returning referenced parameters and how it can lead to bad application design.

Jani Hartikainen has started off a new series that looks specifically at the Zend_Acl component of the Zend Framework starting with this new post looking at a few of the misconceptions surrounding the component.

I’m going to be writing a weekly series of posts on Zend_Acl. This first post will clear up some common misconceptions regarding Zend_Acl, introduce creating ACLs for simple applications, and give some examples on using the ACL in both non-Zend Framework and Zend Framework applications.

To show the most basic usage (and set a foundation for future articles), he creates a simple ACL system for a Zend Framework application. The system sets up a few different roles (guest, member) and some rules to show who can access what. He ties this into his preDispatch method in his My_Plugin_Acl plugin so that it runs right before the rest of the request is processed. If the user is not allowed, it kicks them other to the authentication controller for them to log in.