On the StarTutorial.com site they've posted a tutorial for those that might be newer to the PHP language and ecosystem around it covering the use of Composer. In this latest tutorial they cover some of the basics of using this package manager to pull in and use dependencies in your PHP application.

In general, a block of code forms a method, a group of methods forms a class and a set of classes form a package. A reusable package can be dropped into any project and be used without any need to add functionality to it. A package exposes APIs for clients to achieve a single goal. Packages help our applications achieve DRY (Don't Repeat Yourself), a principle of software development, which reduces repetition of information of all kinds.

[...] In most cases, packages have dependencies. [...] We do need a package manager, a package manager that can solve all of these dependency headaches for us.

The tutorial then goes on to compare two of the main package managers in PHP: Composer and PEAR. It then walks through the installation of Composer and how to use it to pull in a package (in this case the "Faker" package for generating fake user data). It also explains the different commands and configuration files used in working with Composer.

Terry Chay has an interesting post on his site that wonders which language has better packages - PHP or Python?

It depends on the target utility. In the Python world, the most common package installer is pip; the PHP world didn’t settle on a dominant format/installation for packages until composer, and that was relatively recently (last 4 years).

[...] So which has better packages? The answer is it depends on the domain. In nearly any language you can find an adequate package for any of your needs, but overall you will find the packages are higher quality, more up-to-date, and sometimes just better overall in the domain the language seems to target well.

He starts off by talking some about PHP and Python's origins - PHP as a web-focused language and Python as more general purpose - and how this influenced their package implementations. He then shares his opinions on which kind of packages are a more natural fit for which languages:

• for data science/AI/ML applications, Python
• for DevOps, relying on other tools (Puppet/Chef/Ansible/etc) is better
• For server-side web-based packages, I feel PHP and Composer [are the solution]

He also includes some thoughts about other languages - Ruby, Javascript, Go - and their own package managers.

As is mentioned in this post on the Symfony Finland site, the PHP-PM project has hit their first stable release, v1.0, that includes some nice tools as well.

Running an application server written in PHP has been feasible for some years. One of the robus mature options for this has been PHP-PM, a process manager. Now the project has reached a major milestone with the release of 1.0.

The PHP-PM team released the first stable release on 8th of January 2018. It builds on the work done for some years and it builds on ReactPHP. ReactPHP is a low-level library for event-driven programming in PHP.

PHP-PM allows creating long running PHP processes that serve applications directly instead of relying an embedded PHP (like with Apache's mod_php) or a web server with PHP process manager (as with Nginx and PHP-FPM).

Updates for this release include the addition of bridges for static handling, PSR-7 integration and version bumps for Symfony components used in the system. You can check out the full list of changes in the release notes if you want to see more. The post also links to other articles with more reading and tutorials covering PHP-PM and how to put it to use (including Docker integration and basic benchmarks).

On the Madisoft Labs site they've posted a tutorial looking at how to split out your application's data into shards, showing how to do it using Doctrine in a Symfony application.

In the previous article we explored why sharding by tenant is a very good solution for us. In this article we dig into how to divide our Symfony app by shard. [...] We chose Doctrine as our ORM so let’s see what it offers to us.

First of all you have to note that Doctrine is composed mainly by two different parts: DBAL and ORM. ORM leverages DBAL functionalities and it’s completely transparent for sharding. DBAL is the layer we’re interested in.

The author then walks you through the configuration required to make the sharding work including default and a global connections. Next they show the creation of a ShardChoser class that reads a configuration option provided and pulls in the configuration that matches (from YAML files). Finally the ShardManager class is created to handle the connection pool that also includes a "query all" method allowing for the execution of the same SQL on all shards.

The Zend Framework blog has a new post from project lead Matthew Weier O'Phinney showing how you can use plugin managers in Expressive and how it can be used to integrate other components.

With the release of Expressive 2, one of the key stories was the ability to require ZF components within Expressive, and have their dependencies auto-wired into your application courtesy of the component installer.

However, we recently had a user in our Slack channel (need an invite?) indicating they were having issues with usage of custom validators, filters, and input filters. After a <a href=https://discourse.zendframework.com/t/validatormanager-not-calling-custom-validator-factory/109">more thorough writeup on our forums, I realized we'd missed something important when making these integrations, and set out to solve it.

The article then starts with the problem that they're trying to solve, mostly around configuration handling. The solution involved some work done on various packages (like zend-log, zend-filter and zend-form) to make the configuration loading a bit more automated (and with fallback handling).

On the Zend blog they've posted an article where Zend's own Cal Evans shares the answers to some of the questions he received from a "unit testing for product managers" webinar.

Thanks to everyone that joined our Unit testing for project managers webinar yesterday. It was great to see so many people engaged and asking questions. I’ve pulled together answers for your questions we didn’t get to on the webcast. If you have more questions, leave a comment below!

If you missed the webinar or want to re-watch it, the on-demand version is now available. The slides are also posted on Slideshare.

The questions he answers touch on topics that include:

• property-based testing
• testing on an existing project (medium or large)
• integration vs unit testing

The final answer covers something shared at the end of the presentation, the resolution to "just do it". Cal backs that statement up with some additional detail and puts it in the mindset of a project manager.

The Full Stack Radio podcast has posted their latest episode, Episode #37, featuring an interview with Chris Hartjes, most well known for his promotion and teaching about writing tests (unit, functional, integration, etc) for your applications.

n this episode, Adam talks to the Grumpy Programmer himself about getting started with testing PHP applications.

Topics include: recommended testing tools, PHPUnit vs. phpspec, Mockery vs. Prophecy, the benefits of defensive programming and how to convince your manager to let you write tests.

They also mention Chris' new book "Minimum Viable Tests" and the Patchwork monkey patching library. You can listen to this latest episode either using the in-page audio player or by downloading the mp3 of the episode directly. Be sure to subscribe to their feed or follow them on Twitter for more information as new episodes are released.

In this new post to his site Alejandro Celaya offers some advice on improving the dependency injection of your application with the help of the Zend Framework plugin managers. More specifically he talks about the AbstractPluginManager, a part of the ZendServiceManager package.

Generally it is a very bad practice to inject a service container into any object, but there are some situations where it could be even good, when certain conditions are met.

In one of the ZF2 mailing lists somebody asked which were these situations. I couldn't find the email, but the answers said that you can do it when the service container manages resources of the same type, and your object virtually depends on all of them. [...] If you have another object that needs to perform database connections, you don't want to inject all of the connection objects into it, you should rather inject the connection pool. That will reduce the number of dependencies of your object.

In this situation, the connection pool is some kind of service container, but injecting it has more benefits than disadvantages.

He shows how to use the AbstractPluginManager to achieve this goal, noting the existence of a validatePlugin method that can be used to ensure all necessary dependencies are available. He includes a real example of it in use, creating a simple "social plugin manager" that verifies that the plugin provided is either a closure or instance of FilterInterface.

In an effort to reduce some of the complexity and possible differences in the translated versions of its documentation, the Symfony project is removing those from the main website and splitting them into their own sections.

A few days ago, we updated the documentation section on symfony.com to remove the French and Italian community translations. From now on, on this website you will only find the original English documentation.

The main reason behind this decision is that when developers browse the documentation published on symfony.com, they must be sure that the contents are always the right ones. In the case of a translation, this means that all its contents in all branches must always be perfectly synced with the original English version.

The English version sees quite a bit of activity and the translated versions (with a lower contributor count) aren't always in sync. They've split out two of the translations and will now have them coordinated each by their own community leader: French and Italian

The SitePoint PHP blog has a new post today from editor Bruno Skvorc comparing two (almost) identical technologies - Bower and BowerPHP. The main different between the two? One is written in Javascript (Node.js) and the other is, surprise, in PHP. The Bower system is a dependency manager, originally for Node.js environments.

On October 28th, 2014, puppies all over the world spontaneously burst into flames – or so the community would have you believe. What happened was the reveal of BowerPHP (I shy from calling anything “alpha” a release), and here’s why it wasn’t anything nearly as apocalyptic as some would have you believe. BowerPHP is a PHP version of Bower, the NodeJS based front end package manager. We covered Bower before somewhat, but in essence, you use it to install front end libraries like jQuery, Angular or Foundation much in the same way you use Composer for PHP dependencies. You define a Bower file with dependencies, run bower install, and watch the magic happen.

He goes on to talk about what kinds of problems having the same tool in PHP solves and how to get it installed in your application (via Composer). He then includes an example of it in use installing a copy of the Foundation JS libraries and the resulting output HTML page. He finishes the post with a few reasons "why it's awesome" including there not being a need for yet another technology (Node) and that it's easy to install.