Christian Mackerprang has an interesting post to his site sharing some of his thoughts about why terrible code gets written by sane people - developers that know what they're doing but, for other reasons, write code that's a mess of anti-patterns and inconsistency.

What I discovered after some months working there [on a legacy Python project], was that the authors were actually an experienced group of senior developers with good technical skills. What could lead a team of competent developers to produce and actually deliver something like this? What I’ve come up is a list. These are some bad habits that even experienced teams can get into which will severely affect your end product, more than any static code checker or development methodology could rescue it from.

His list of reasons covers six of the reasons he sees for the "good people, bad code" situation happening:

Giving excessive importance to estimates

Giving no importance to project knowledge

Focusing on poor metrics such as “issues closed” or “commits per day”

Assuming that good process fixes bad people

Ignoring proven practices such as code reviews and unit testing

Hiring developers with no “people” skills

For each item in the list he briefly covers why it's a bad thing for your engineering group and references to other sources on good suggestions to fix the situation.

Lorna Mitchell has a new post today with five things that you could gain by upgrading your platform, mostly centered around the changes PHP has made recently.

In recent years, the release cycle of PHP has become much shorter. We now have a much more controlled and well-publicised process of releases, and moving between each version is no longer a leap of faith. The newer versions have HUGE performance improvements, great features, and better security, and the software is free to use. Yet we have a very, very long tail of PHP installations on older versions (around 75% on entirely unsupported versions at this point). Many of the companies I talk to think that upgrading will be pointless and painful, but that's not my experience of migrating PHP projects. Here are a few things you might like to think about or be aware of before you make the decisions that "not broken" is good enough for your applications.

She offers her list of five things, each with a bit of summary and a few links to more information on the topics:

Improved Performance

Security and Support

New Syntax

Traits

Built In Webserver

She also technically includes another in the list (#6 in the top 5, naturally) talking about the password hashing functionality that's been introduced in recent versions and how much simpler it can make your life.

I have recently revived my “filtered unserialize()” RFC and I plan to put it to vote today. Before I do that, I’d like to outline the arguments on why I think it is a good thing and put it in a somewhat larger context. It is known that using unserialize() on outside data can lead to trouble unless you are very careful. Which in projects large enough usually means “always”, since practically you rarely can predict all interactions amongst a million lines of code. So, what can we do?

He touches on three points that would make it difficult to just not use it this way (on external data) including the fact that there's not really any other way to work with serialized data in PHP. He suggests that by adding filtering to the unserialize handling of the language it can protect from issues around working with serialized external data.

Is this a security measure? [...] Yes, it does not provide perfect security, and yes, you should not rely only on that for security. Security, much like ogres and onions, has layers. So this is trying to provide one more layer – in case that is what you need.

In his latest post Benjamin Eberlei talks about some of his reasoning to want to Symfony all the things when it comes to building web applications. Actually, it's the results of a discussion he had with a coworker about when is the right point to move from a micro-services infrastructure to a full-stack framework like Symfony.

We use microservice architectures for the bepado and PHP Profiler projects that Qafoo is working on at the monent. For the different components a mix of Symfony Framework, Silex, Symfony Components and our own Rest-Microframework (RMF) are used. This zoo of different solutions sparked a recent discussion with my colleague Manuel about when we would want to use Symfony for a web application.

He talks about some of his own reasons for making the choice including things like the HttpKernel and having a well documented and standardized solution. He notes that most of his reasons are more because of his previous exposure to the framework and could be very similar for others and other frameworks, though. He then extends on the "Hello World" code from the previous post and makes an improved minimal Symfony app with just seven basic parts (including configuration files).

Ever since 2006 I had always wanted to go to a technology conference. I’d see titles of talks for ZendCon and think “Wow, that would be cool to learn about!” In 2009, I finally went to the Utah Open Source Conference (now called OpenWest), and I was blown away with all the stuff to learn. Then, in 2011, I shelled out my own money and flew to Chicago for PHP Tek, and it cost me around $3,000 after conference ticket, flights, hotel, & other expenses while at Chicago. It was absolutely awesome, and I walked away extremely grateful that I went.

He gives four main reasons to attend:

Learning From the Talks

Discovery of New Technologies

Rubbing Shoulders with Giants

Making Connections with Others

He points out that, with so many more regional conferences popping up, attending these events is even more accessible.

About a month back Samuel Levy wrote up a post sharing some of his thoughts on PHP, mostly centered around one idea - that PHP is the right tool for the job (for all the wrong reasons).

When people complain about PHP being a horrible language, not fit for human consumption, they will often talk about how the features of their favourite language are far more refined; have been designed with elegance in mind; are consistent and secure. And you know what? They're right. But PHP is still a better tool. [...] And it shouldn't be. It really shouldn't. I want another language to knock PHP out of the way. [...] I can't, though, because PHP does one thing really well that no other language seems capable of doing. It works, out of the box, for people who don't know what they're doing.

He goes on to talk about the "installation" required with running PHP scripts and how it makes it mostly "idiot-proof" to use. He points out that PHP has a definite niche in the world of web development languages - one that has a larger need that some others.

This is the challenge for all the people who want to complain about PHP - if your chosen language is so much better (and I have no doubt that in many ways, it objectively is), then make it accessible in the way that PHP is. Until then, keep that double-clawed hammer in your shed in case you want to make... burgers...

The PHPClasses.org site has posted a humorous look at the PHP language with several reasons why PHP is a "hobbit" (a Lord of the Rings series reference):

Sometime ago a user of the Quora site asked a question if there was a language war, which languages you support and why. Another user gave a very creative response comparing programming languages with characters of the Lord of the Rings story of JRR Tolkien.

In this recent post from Charles Sprayberry he explains why using dependency injection (DI) in your application is a good idea and can help make things easier in the long run.

Dependency Injection is just a fancy term for passing dependencies to the object needing them instead of letting the object create its own. Hopefully, you've watched this great Google Clean Code talk about dependency injection by Misko Hevery where he talks about why you should ask for things instead of looking for them. I'm gonna talk about some reasons to use DI beyond just those presented in the video.

In this new article from Web Developer Juice giving fourteen (descriptive) reasons why Ruby is a better choice than PHP for building web applications (from the perspective of a Ruby developer, it seems).

Picking a language for a programming project is never an easy task. [...] This is especially true with web programming projects. Because you are not always in control of the environment where one’s application will be run, it is important to pick a language that can adapt to many situations. Ruby is a better language than PHP for the following reasons.

The list of fourteen includes several points that are not the usual "because it's faster" or "because PHP sucks at this" sort of thing. Here's some examples: