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.

The QaFoo blog has written up an interesting post looking at languages and scalability and some of the constraints that can come along with them.

Micro-Services or any set of small services are common again right now. While it can make a lot of sense to use a dedicated service for a well defined problem those services are sometimes used just to play with a different server software. While it is pretty obvious for most that selecting the right database is important the same is true for selecting the right language (virtual machine) for the job.

There are different types of services or server applications where different types of virtual machines (executing the opcodes / bytecode of the compiled source code) make more or less sense. What are the criteria we should base such a decision on and which language should we choose when?

As their primary work is related to PHP, they focus in on it. They talk about why PHP has become such a popular language (the "LCoDC$SS" acronym) and why it fits in with HTTP's statelessness perfectly. On the flip side, they also talk about when it doesn't make sense to use PHP - mostly centering around what would take long-running PHP processes. They then compare this to a similar setup with other languages like Node.js, Go and Java (and how well those scale themselves).

On the Symfony Finland site there's a post encouraging you to "get expressive" with the Symfony Expression Language. The Symfony Expression Language is a part of a component in the Symfony framework that allows for custom evaluation and action in the form of a specially formatted string.

Way back in November 2014 the Symfony team introduced the ExpressionLanguage component. It is essentially a simplified version of control structures that you use in the Twig templating language, producing a single value in the end.

The feature has a number of uses, but seems to be under utilized by the Symfony and PHP communities - especially in higher level functionalities. [...] I think there is a lot of room for developers to adopt the component in many different functionalities, not only for routing, access control and so on.

The post goes on to talk about expression languages in general and how they're present in other languages too (like Java with JUEL). He then shares a basic example evaluating the data in an array and getting back a pass/fail result.

On DZone.com today there's a new post that welcomes those coming from Java over to PHP with a few recommendations and suggestions about what's different and some things they might find familiar in the transition.

We are welcoming some new colleagues that come from a Java background in the Onebip team, both from the development and operations field. Here's a primer on learning PHP in this situation, that you may find useful when introducing similar people in your PHP-based projects.

He breaks it up into a few sections:

• the "absolute basics" (like the differences in variable handling)
• things to not care about (like procedural PHP or the installation of Apache+PHP)
• how to "write to a graph" (things like PDO, DateTime)
• things to watch out for (like == vs === and some php.ini settings)

He also recommends doing some coding katas with TDD to give you a "crash course" in the language and help you learn from more than just reading.

PHPClasses.org has posted the latest episode of their "Lately in PHP" podcast series - episode #29, Should PHP be Copying the Java features and practices?.

Particularly since version 5.0, PHP has been copying many of Java features and practices of Java programmers. This means that if Java programmers practices tend to be bureacratic and less productive, PHP programmers that use those features or adopt those Java practices may also become less productive. This was one of the main topics discussed by Manuel Lemos and Michael Kimsal on the episode 29 of the Lately in PHP podcast.

There's also a bit of discussion about adding generics to PHP and using OAuth in PHP. You can listen to this latest episode either via the in-page player, by downloading the mp3 or by watching the video of the recording. You can also subscribe to their feed to get the latest in the podcast series.

Matt Frost has posted a two part series of some of his experiences in setting up Selenium to execute it in a VM and run tests on your application.

I was a little scared when it came to setting up Selenium, I figured it was going to be difficult to setup and configure. So I was pleasantly surprised when it really wasn't. So here are a few of the mistakes I made; since I use Vagrant to do all my development I actually grabbed Selenium and started from there. Not a good place to start, although as I found out later; not a total dead end.

He includes the initial setup of things like PHPUnit and the Selenium .jar file as well as a sample test that loads a page and checks the title of the page. His second post shows how to set it up in the VM (using Vagrant, xvfb to capture the output and Firefox to execute the tests).

In his latest post Chad Minick shares some thoughts as to why he thinks PHP frameworks are obsolete and how, despite there still being a use for them, a lot of them are just trying to solve the same problems all over again.

Now before I start getting hate mail, let me explain that I still think there is a market for PHP frameworks. I think if you have a moderately low traffic site that’s going to live on shared hosting, and is basically a CRUD application on top of MySQL, disregard this article, it probably isn’t for you. However, I’ve seen so many projects start out with that scope. They either grow or the developer/client wants to add more fancy new features they are starting to see elsewhere on the web. Then I see all these PHP developers hacking things that the PHP stack really isn’t meant to do.

He takes some of the core features of several of the popular frameworks out there and breaks them out into a list of technologies that do that work themselves (such as "Web Server", "Dependency Management", "Caching" and "Messaging"). He points to a Java/Scala framework, Play as an example of having several of these technologies built-in where you don't have to have a whole other set of skills to use them effectively. It's an interesting idea but seems a little NIH to me.

According to this new post on Nerds Central, there's been speculation that Facebook, needing even more of a performance boost than hiphop gave them, is moving into using PHP in a JVM.

The presence of Facebook engineers at the JVM Language Summit in San-Francisco along with their interest in implementing PHP using invoke-dynamic on the JVM is a the shock. The main seismic event will be nothing less than the complete removal of interpretors from main stream general purpose programming.

He talks some about the JVM environment (and the Magik project) as well as wondering about what sort of performance boost it might actually give.

So Are Facebook Doing The Right Thing? Yes! The rise and rise of Javascript over the last 4 years as shown us just how powerful JIT compilation of once interpreted languages can be. The fall and fail of complete re-writes has shown us just how unrealistic it is to completely move a working system from one language to another. Facebook has a stupid amount of PHP and so it is by far the most sensible thing to port that to mlvm. Actually it should be pretty easy.

On his Reflective Thought blog Luis Atencio takes a look at the current state of dependency injection in PHP and shares a simple refactor from non-DI to code that uses it as a service locator.

If you have worked with frameworks such as Spring or Google Guice, you will understand the power and flexibility that dependency injection provides your humongous code base. [...] One quick drawback that I see is that the stateless nature of PHP makes things like object containers not very practical.

He proposes a slightly different kind of dependency injection system, one more akin to what's provided in the Java world where annotation and reflection are components of the integration. He provides a code sample of how this would look and points to Java's JSR-330 standard for some of the annotation examples (like "@inject" or "@scope").

On PHPMaster.com today, they've started a new series about integrating two popular technologies - PHP and the Android OS - in this new tutorial from Matthew Turland. He'll show both sides of the code needed to get your Android app talking to a PHP backend.

This two-part article will guide you through the process of building an efficient PHP-based REST web service to be consumed by an Android-based application. Some of the concepts presented here are also applicable to other mobile platforms, such as iOS. I assume you already know the basics of PHP and Android development and that you have a suitable development environments set up for both. I’ll focus mainly on showing you how to handle data serialization and compression in both environments.

In this first part, he starts from the client side, creating the code (Java) that's needed to create the connection to the backend. He stets it up as a background task so its execution won't block the main app from working. He shows how to execute it, running an "on create" method and checking to ensure the network is available for the request.