Tomas Vortuba has a new post to his site sharing a few reasons why he thinks that Doctrine isn't dead and is still "alive and kicking" with things still changing in the project.

Almost 1,5 year ago I wrote Why is Doctrine Dying. I didn't use dead, because it's is just state of time being. Open-source projects - like people - tend to find themselves on the top, being stuck or struggling with the right path from time to time. It's a completely normal process of evolution.

I don't know if that post helped it, but since then many things changed for better in Doctrine project. Saying that this post deprecates my old view and celebrate changes.

May this be an inspiration for open-source projects that find themselves stuck and the maintainers that find themselves unhappy.

His list includes reasons like:

• Bump PHP 7.1 Without Waiting for Major Release
• Cut the Weight to Save Yourself
• From Talks and Post Evangelization to Code Improvements
• New Release as a Baseline

For each point, he provides a little clarification and background from commits to the code and statistics about the community around the project.

On the TutsPlus.com site today they've posted an opinion article that tries to help answer the question "Should You Use a PHP Framework?". They provide their own list of top five pros and cons, representing each side and hopefully getting you thinking about your own project.

From routing HTTP requests to accessing the database and rendering the user interface, most web applications have a lot in common with each other. Many of them allow their visitors to sign in, and it's hard to imagine a web application without email sending. A software framework is a way to put this observation into use.

But is using a framework always the best way to go, or does it sometimes make sense just to start from scratch using nothing but plain PHP? To answer the question, in this tutorial, we will look at five pros and cons of using a PHP framework.

Items under their "pros" list include how they allow for more rapid development, easier maintenance in the future and the support of the community around the project. Their "cons" list talks about topics like the more general approach most frameworks take, the lower level of performance vs just PHP and the limited visibility into how the core framework works where it's not supposed to be customized.

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.

Stanislav Malyshev has a new post to his site talking about his proposal for a filtered unserialize change and why he sees it as a practical next step.

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).

Justin Carmony has a new post today with some reasons you should attend tech conferences including both the social and technical aspects.

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.

There's six reasons listed in the post:

• PHP is Scripted C
• PHP is not Teaming with C++ Evil
• PHP is Not particularly Beautiful but it is Very Useful
• PHP is Not the Fastest Language to Execute but is Agile
• JavaScript could be a Hobbit too but Asynchronous Programming is a Hell
• PHP Success Causes the Envy of Others

If you're interested to see the thread where the idea for this post came from, you can read it here on Quora.

In what's sure to be a "flame bait" kind of post, Jani Hartikainen has posted five reasons PHP is better than Node.js - some simple one-liners and others a bit more complicated.

All hail Node.js! Boo PHP! Except there are various things where PHP is better than Node…

His five reasons are:

• Easier to find hosting
• It's easier to get started with PHP
• If your PHP code breaks, it doesn’t bring your whole server down
• PHP processes are short lived
• Bigger standard library

There's a few comments on the post already, one noting that some of the points could be turned around to make PHP fall more on the "bad" side.