On his Medium.com site Benoit Schneider (CTO of Outsourcify) has a post sharing some of the reasons they made the choice to use Symfony for their web development needs.

At Outsourcify we work on projects of varying sizes, from small sites with a few pages to complex business applications. Depending on the case, we recommend different technical solutions (we do a lot of Javascript SPA and Wordpress also), but for the most complex cases, when we have to chose a technology to build large web applications that require several weeks or months of work for several web developers, Symfony is our framework of choice.

He starts with a bit of background on his own experiences with Symfony and why he chose it for his own needs early on. He then shares his thoughts around "why Symfony?" when there are many other major frameworks to choose from. He wraps up the post with a summary of some technical reasons to use the framework including the innovation it brings to the table and the robust ecosystem around it (and related products/tools).

On the Laravel News site there's a new article posted by Percy Mamedy posing the question: "Can Frameworks lead to tribalism among developers?"

In the modern world of web development, it is common practice to make use of frameworks for building large scale applications instead of starting from scratch. [...] In the PHP world, we have seen the emergence of hundreds of frameworks thanks to a large and dedicated community. Some developers even develop their own framework re-using components and parts of other frameworks thanks to an awesome tool called composer.

[...] As part of an experiment, I wanted to see how my fellow developers would react and to what extent they were willing to go to defend their own frameworks if I praised Laravel as being the best framework out there. [...] As expected, responses were flowing in; some even brutal. Everyone defended their framework of choice with extreme passion and dedication. This has lead me to the conclusion that there is an intense sense of identity and kinship that developers have around their framework of choice.

His results came in from a post he made wondering how fellow developers would react to the statement "Google Trends says it all...Laravel is king." He talks about these results and the obviously relation to tribalism in technology choices and how it binds like people in groups, a common human need.

We all as developers feel this intense love and passion for our tools, it’s part of who we are, and I think it’s what makes our Job so unique; we code because we enjoy to and because we love to.

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.

On the Paragon Initiative blog there's a new article posted that wants to help you pick the right cryptography library for your project and your needs. In it they make several recommendations and the benefits of each.

Cryptography is not magic. Adding encryption to an application doesn't automatically make it secure against attackers (especially if you aren't authenticating your ciphertext). But if you do need it to satisfy a business need, conventional wisdom states that you almost certainly should not try to design your own cryptography. Instead, you should use an existing cryptography library.

Okay, great. So which PHP cryptography library should I use? That depends on your exact requirements. Let's look at some good choices. (We won't cover any terrible choices.)

The three libraries they recommend are: Halite, the Libsodium library, the Defuse Security PHP Encryption library and the PHPSecLib library. For each they make some recommendations on places they may be most effective and how it using them relates to passwords (hint, hashing over encryption).

Marc Aube has shared some thoughts about picking your project's dependencies and considerations to think about when building your applications.

If you work on any non-trivial project, chances are you'll install one or many external dependencies at some point. [...] However, you shouldn't bring any library in your codebase. While Packagist has, at the time of writing, around 60000 packages you could use in your project, most of them are not production quality. Here's a list of things to look for when choosing a generic library for a mission-critical project, in no particular order.

Among the things he suggests, there's tips like:

• Ensure it has a stable version
• That it's extensible
• It's active and maintained
• The license permits the intended use
• It has quality documentation

For each he offers a brief paragraph or two explaining the point and examples where appropriate of projects matching the topic.

The SitePoint PHP blog has posted a request for responses to a survey about which PHP framework you consider to be the best for 2015.

Almost a year and a half ago we published the results of a framework survey on the PHP channel. The survey, while producing fewer entries than our IDE survey still provided us with valuable insight into our audience and the state of individual vs. team developers out there.

With Laravel 5 fresh out of the oven, Phalcon being kickstarted into full-time development, and others reaching a much anticipated maturity, it’s only natural we’re curious about your preferences – have they changed? Do they remain unbudged? Do you wish you could switch so hard you can taste it, but aren’t allowed to by your company? We’re interested in all these points and much more.

The survey will run for a month and there's some prizes involved for the top "resharers" of the survey. You can submit your own votes directly through the post at the bottom. Questions range from which framework you prefer to which you use at your place of employment and why each was chosen. Submit your answers today and help get a better idea of the PHP framework landscape.

On the Dutch Web Alliance blog today Stefan Koopmanschap talks about making technology choices, how flexibility comes into play and suggestions on what to do when things go wrong. He uses some of his own experience (and problems) to illustrate his points.

The amount of times I come into an organization that says any of the above is impossible to keep track of on one hand. Or even two. Most development shops for some reason have decided that they have a single tool that will fit the job. Always. I have to admit the current market is good for developers. There are many projects available, and not enough developers or agencies to work on all of them. [...] But too many times have I encountered projects where the used tool actually was not optimal for the project. I would like to make a case against starting with a full stack from the start. Obviously, this approach does not work for all projects, but too many projects start out small but with a full stack. I’m going to take an old project of mine as an example of how to start out small and not grow until you need to.

He talks about the project first, a transcoding tool that used a third-party service and generate a playlist once the process was complete. He shares some of his thinking about the technology involved (Symfony2 without the full Symfony2 stack) and the decision to go with Cilex. He also talks about database choices (PDO over Doctrine) and how starting with small pieces like this makes it easier to change things in the future (or when a roadblock looms ahead). Then comes the "what went wrong" part of the development - debugging the system without the direct access needed to view the logs. Instead he worked around it, made a simple endpoint to show the logs and output it via Twig templates.

The result of all this work, including changes and extensions, was still a very small and lean application that combined the power of the commandline with a simple but effective web interface. I am sure I could have done a similar thing with Symfony2, but the code would’ve been overkill. [...] It is important to realize that there is not always a need for full stack frameworks or huge CMS’es like Drupal. Sometimes you need to start small and just let it grow.

Tobias Hermann has put together some interesting statistics pulled from the various programming subreddits on the Reddit.com site. He measures the choice of words for each community based on how own they're used.

While reading about various programming languages, I developed a hunch about how often different languages are mentioned by other communities and about the average conversational tones used by relative members. To examine if it was just selective perception on my site, an unconscious confirmation of stereotypes, or a valid observation I collected and analysed some data, i.e. all comments (about 300k) written to submissions (about 40k) in respective programming language subreddits from 2013-08 to 2014-07 using PRAW and SQLite. In this article I will present some selected results.

He first covers the "mutual mentions" for each of the groups with the largest connection from the PHP subreddit being to Python. He also compares the results to the TIOBE index for each (average popularity). He gets into more details about the words used (abstract, category, pure, etc) with PHP placing somewhere roughly in the middle for most data sets. The most interesting result, however, came with the set of curse words and the frequency of their use. In the PHP Reddit community the usage of these terms is, by far, the most of any group. Unfortunately, PHP also ranks lower on the "happiness" scale.

If you're interested in seeing how he came up with these results, you can get the raw results and the code he used.

The Loosely Coupled podcast has posted the eighth episode of their podcast (hosted by PHP community members Jeff Carouth and Matt Frost) asking "Do you even polyglot?"

In this episode Jeff and Matt talk about the idea of polyglotism, the benefits, practical advice about choosing which languages to learn and how to be successful while learning new languages. You should go out and find a new language and prepare to give it the time it deserves. It’s best to find a mentor or someone to help you and step out of your language or paradigm comfort zone.

They mention several other topics including Clojure, the splat operator and fellow community members Joel Clermont and Igor Wiedler. You can listen to this latest episode either through the in-page audio player or by downloading the mp3 directly.

On the SitePoint PHP blog Bruno Skvorc has a new article with a few of the reasons why to choose PHP over other alternatives. It's a quick post with only a few points, but it's interesting for its choices of when not to use PHP.

It’s a popular question. Why indeed should one pick PHP over one of the alternatives? After all, PHP has often been dismissed as a unusable and badly designed language. Why would anyone choose it, when starting a project from scratch? Instead of listing the reasons why people do choose it (mostly widespread availability), let’s instead focus on why people should choose it. We can’t talk about that, however, without first mentioning why they shouldn’t.

Among their suggestions of when not to use PHP are things like building command line applications and "just because it's there" on your shared hosting. There's a section near the end of the article that talks about some of the work that's been done to try to dispel the "bad press" PHP has gotten and how other languages (his illustration is Javascript) have the same kind of taunting and nitpicking happening as well.