Alejandro Celaya has a recent post to his site showing you how you can delay constructor execution in your services by making use of the "lazy services" functionality provided by the Zend ServiceManager component.

A couple years ago I wrote a post about how to improve PHP applications performance by using zend-servicemanager lazy services.

In that article I explained how the ServiceManager takes advantage of the proxy design pattern to delay the creation of services, when they are marked as lazy.

That can improve performance if the object is resource consuming, but that is not the only advantage behind proxies.

He starts with a use case for using these "lazy services" based on some changes in an open source library he maintains to add in geolocation support. The library requires a database file when the object is created but on the first run, no file is downloaded yet. He made use of the lazy service loading to only initialize the GeoIp2 library when it is requested and not when the script starts.

In a new post to his site Tomas Votruba looks at autowiring Symfony services and parameters to make it even easier to integrate services into your application.

I love how Symfony caught up late autowiring integration in since Symfony 2.8. Then set a trend in Symfony 3.3 with service autoregistration.

That opens new possibilities to almost config-less registration, doesn't it?

He first looks at some of the "old" configuration handling, defining the services manually in the YAML configuration along with their arguments. He shows how this evolves with the addition of autowiring and autodiscovery, minus the parameters. He continues on to show how to integrate parameter handling into the services configuration via the bind option. He also shows how to improve this and use autowired parameters and call them directly in the constructor of your class and let the DI container do the rest.

Blackfire.io, the PHP performance profiling service, has announced a series of webinars aimed to help you learn more about the service and how it can help you get the most out of your code. These webinars are spread out all across the globe so anyone can attend at a timezone-appropriate hour.

Here's the list for the October and November sessions:

• [Getting Started with Blackfire (October 30th, 2018 – US Session)](Getting Started with Blackfire (October 30th, 2018 – US Session))
• Getting Started with Blackfire (October 30th, 2018 – European Session)
• Getting Started with Blackfire (November 6th, 2018 – US Session)
• Getting Started with Blackfire (November 6th, 2018 – European Session)
• Introduction to Blackfire (November 13th, 2018 – US Session)
• Introduction to Blackfire (November 13th, 2018 – European Session)
• Getting Started with Blackfire (November 20th, 2018 – US Session)
• Getting Started with Blackfire (November 20th, 2018 – European Session)
• Getting Started with Blackfire (November 21st, 2018 – Asian Session)

You can find out more about the contents of each sessions - "Getting Started with Blackfire", "Introduction to Blackfire" and "Automating Performance Testing with Blackfire" - by clicking on the link for the related event. If you're interested at all in improving the performance of your application, check one of these webinars out. Blackfire offers their "Hack" level of support to try out for free too so there's no reason not to give it a shot!

The TutsPlus.com site has continued their series looking at using the Pusher real-time communication service in your PHP application with a new tutorial. In this latest article, they show the use of presence channels, a feature that makes it simpler to know which users are connected to which channels.

In this series, we've been learning about Channels from Pusher, a platform that allows you to give your users the seamless real-time experience they want.

Presence channels build on the security provided by private channels, but they add the benefit of knowing which users are subscribed and connected to that channel. The best part is how easy it is to implement and use presence channels, and it's even easier if you've already configured your app to use private channels.

As in the previous articles in the series, they've provided both a screencast of the tutorial and the text-based version. They show how to modify the server you've already created to authorize a user and send that information along with the messages back to the Pusher service. They also include the changes to the frontend client to gather and send user information.

Kevin Schroeder has a post to his site sharing some helpful tips for monitoring Magento jobs and crons to help provide a bit more information about the job and its current state.

About a month ago a client of mine was lamenting the fact that they didn’t have insight into what was going on with their cron jobs. So I did what any idiot would do and built out a service that does just that. It works with any Magento version, 1 or 2, system crons, and you can use an API to integrate it with your own system with a very minimal amount of work. I call it the 10n Job Health Vault. With Magento 1 or 2 you can have it set up and running in under 5 minutes (minus DI compilation time, of course).

The tool tracks the execution of the job and notifies you if something's wrong and it hasn't finished. This also means it can track the execution time and report back if it's slower than usual. You can find out more information about this Magento monitoring tool on its website.

Rob Allen has posted a quick tutorial to his site showing how to user Composer in a PHP project on OpenWhisk. OpenWhisk is Apache's serverless cloud platform that's easy to scale and relatively easy to use. This is the latest in a series of posts from Rob covering its use in PHP projects.

Every PHP project I write has dependencies on components from Packagist and my Serverless OpenWhisk PHP projects are no different. It turns out that adding Composer dependencies is trivial.

He uses a simple action that coverts a number to the matching string, showing the yaml configuration changes and code to include to define the action. The action makes use of the NFNumberToWord package which is then added via Composer. He deploys the action and calls it directly, showing the result to be the correct string for the number "123". He also mentions an archive file (zip) that the serverless functionality creates containing all of the files related to the project. He shows the configuration option you can use to split these by action, making it easier to create a more modular system.

Tomas Vortuba has continued his series looking at building command line tools with PHP and the Symfony Console component. In this latest post he shows how to create an application using dependency injection in just four files.

Series about PHP CLI Apps continues with 3rd part about writing Symfony Console Application with Dependency Injection in the first place. Not last, not second, but the first. Luckily, is easy to start using it.

He starts with a bit of information about how Symfony has evolved from the previous method of using controllers as services to create CLI tools. Now commands can be used as services and be pushed into/pulled from a dependency injection container. He then walks through the three steps to adding a command as a service:

1. updating the services.yml file to include linking for the console application class.
2. updating the Kernel to load the yml configuration.
3. creating the bin file to execute the application.

With this structure in place, he then shows how to share functionality between services using a CompilerPass.

Tomas Vortuba has a tutorial posted to his site showing you how to test private services in Symfony in unit tests for pre-4.1 Symfony installations (it has been resolved via simpler testing methods in Symfony 4.1 with the FrameworkBundle).

2 versions of Symfony are affected by this dissonance between services and tests. Do you use Symfony 3.4 or 4.0? Do you want to test your services, but struggle to get them in a clean way?

Today we look at possible solutions.

He starts with an example of the error you'd face if you tried to pull a service directly from the container that was marked as private. While you can specifically make it public in the yaml configuration, this potentially means doing that for all of the services you need to test. While this might work for smaller projects, it's unmaintainable for larger ones. He then shares some other options that could help resolve the issue including the one he ended up on: a compiler pass. He gets into a bit of detail on the changes this would require and where the "magic" is that lets it work.

On his site Tomas Votruba continues his look at the Symfony/Console component of the Symfony framework. In this latest article he walks through the loading of configuration options from a file provided by a --config option on the command line.

PHP CLI apps usually accept config, to setup their behavior. For PHPUnit it's phpunit.xml, for PHP CS Fixer it's .php_cs, for EasyCodingStandard it's easy-coding-standard.yml, for PHPStan it's phpstan.neon and so on.

In the first post about PHP CLI Apps I wrote about poor DI support in PHP CLI projects.

Today we look on the first barrier that leads most people to prefer static over DI - how to load config with services.

He starts off talking about the "chicken and egg" issue when it comes to loading configuration: needing a configuration to create an Application instance which then needs the config (and so on...). He then walks through three possible solutions:

1. Not using a container to manage dependencies for the application
2. Setting up a container in a command
3. Using the ArgvInput input helper to pull directly from the arguments

He gets into more detail on this last method, providing code examples and input/output examples of it in use. Unfortunately this method also introduces some undesired dependencies between commands. He finishes the post with an alternative: setting up option definitions in the getDefaultInputDefinition method of the main application and having them available to all commands.

On the Laravel News site today there's a tutorial posted showing you how to combine Docker and Laravel's Scheduler/Queue and make them still run as they would on a virtual server.

In Laravel, one of the tricky changes when switching from a virtual server to Docker is figuring out how to run a scheduler and a queue worker. I see this question come up quite a bit when PHP developers are trying to figure out how to use Laravel with Docker.

Should you run them on the host server? Should you run via cron in a Docker container?

There are a couple of ways I recommend running the scheduler command and Laravel queues in Docker, and we’re going to cover the basics of running both with a complete (albeit simple) Docker setup you can use to experiment.

Their approach uses a single multi-purpose Docker image rather than splitting the functionality up and making it more complex (Laravel subscribes to the monolithic approach anyway). The post then gets into the setup of this environment using Docker and docker-compose to configure several services: application (app), a Redis container and a MySQL container. The contents of the docker-compose and Dockerfile configurations are included as well as the VirtualHost configuration for the main site. Next it shows the use of the CMD directive to run a bash script when the build is brought up. This is what kicks off the scheduler/queue handling. The post finishes up with a few other changes needed to the Docker configuration and the creation of the "scheduler" service.