Matthias Noback has continued his series about "mocking the edges" in your unit testing with this new post. In it, he talks about mocking "the network", those places where your application reaches out to external services to access data or perform other operations.

In this series, we've discussed several topics already. We talked about persistence and time, the filesystem and randomness. The conclusion for all these areas: whenever you want to "mock" these things, you may look for a solution at the level of programming tools used (use database or filesystem abstraction library, replace built-in PHP functions, etc.). But the better solution is always: add your own abstraction.

[...] The same really is true for the network. You don't want your unit tests to rely on a network connection, or a specific web service to be up and running. [...] The smarter solution again is to introduce your own interface, with its own implementation, and its own integration test. [...] Though this solution would be quite far from traditional mocking I thought it would be interesting to write a bit more about it, since there's also a lot to say.

In his example he shows the use of a file_get_contents call to fetch stock information. He introduces a ExchangeRateService interface with a getFor method to provide structure for the "wrapper" around the network call. He then covers the idea of an "anti-corruption layer" to change up the interface to use models instead of just a string value (code included). He ends the post talking about the inversion of the dependency - the option to have a job pull the value out-of-band and then have the application use that value.

In a post to his site Nikola Poša looks at a method that can be used to provide a slightly different object from a dependency injection container based on other criteria: making use of a factory as a service.

Dependency Injection Containers are a great invention - when used the right way, they allow us to keep our factories and assembly logic of services outside the core business logic of our application.

By default, a service created is shared, meaning that exactly the same instance will be returned whenever service is retrieved from a container. This is a desired behaviour in most of the cases. [...] Yet certain use cases may require services to be created conditionally during runtime, such as for example based on the value of a parameter resolved from the current request.

He first covers some of the anti-patterns that could be used to resolve this issue: a setter method on the returned object, using a service manager or creating a static factory instead. He offers a solution to the problem that makes use of a factory inside of the DI container. This factory then uses configuration values from the container to set up the object and return it.

Sergey Zhuk has posted the third part of his series covering the creation of a Memcached client using ReactPHP has the base and allowing for asynchronous operations. In this latest part of the series (part three) he focuses on emitting events for various actions/results in the client code.

In the previous article, we have faced with a problem: how to deal with a broken connection. Now, when the connection is closed all pending requests are rejected with the ConnectionClosedException. If we want to handle this situation we need to attach onRejected handlers to all promises because we can’t guess in advance which one will be the problem.

This [example] code already looks too complex, but also there is no way to find out if the connection was broken or we have manually close it. So, it becomes clear that we need a completely different approach.

He then shows how to make use of this event library to emit events at certain points in the client's state. He includes code examples showing how to use the emit method to throw the event focusing on handling when there's connection issues.

Sergey Zhuk has posted the second part of his series covering the creation of a ReactPHP-based memcached client for asynchronous cache handling. In part one he set up some of the basic structure of the client and got it to a working state. In this latest part he expands on that base and improved the error and connection handling to make it more robust.

In the previous article, we have created a simple streaming Memcached client for ReactPHP ecosystem. It can connect to Memcached server, execute commands and asynchronously return results. In this article we are going to implement some improvements: connection handling [and] errors handling.

He then goes through and makes changes to allow for correct handling of the connection closing where it can either be closed by an option you specify or a forced close from the server. On the error handling side he shows how to handle invalid commands (throwing a WrongCommandException) and a failed command, such as when the value couldn't be stored for one reason or another.

Michelangelo van Dam has a new post to his site looking at using Redis for PHP sessions storage and changes related to the use of PHP 7.1.

In case you have missed it, PHP 7.1.0 has been released recently. Now you can’t wait to upgrade your servers to the latest and greatest PHP version ever. But hold that thought a second…

With PHP 7 lots of things have changed underneath the hood. But these changed features can also put unexpected challenges on your path. [...] One of these challenges that we faced was getting PHP 7.1 to play nice storing sessions in our Redis storage. In order to store sessions in Redis, we needed to install the Redis PHP extension that not only provides PHP functions for Redis, but also installs the PHP session handler for Redis.

When he installed the extension, the latest version (redis-3.1.0), he was given an error message about a failure to read the session data. He shares a bit of code he used to try to debug and diagnose the problem (and a Docker environment) that still resulted in the error. Ultimately they narrowed it down and discovered that it was the Redis extensions causing the problems. Downgrading it from 3.1.0 to 3.0.0 solved the issue right away.

In this recent post to his site Remi Collet shows you how to set up your PHP installation to allow it to work with a Microsoft SQL Server as it's data store.

Here is a small comparison of the various solutions to use a [Microsoft SQL Server](https://en.wikipedia.org/wiki/Microsoft_SQL_Server) database from PHP, on Linux. All the tests have be run on Fedora 23 but should work on RHEL or CentOS version 7.

Several different extensions were tested as a part of making the connection to the SQL server:

• Using PDO, ODBC and FreeTDS
• Using PDO, mssql and FreeTDS
• Using PDO, ODBC and Microsoft® ODBC Driver
• Using the Microsoft® Driver
• Using PDO and the Microsoft® Driver

Each item comes with a list of the requirements involved (other modules/extensions), examples of the configuration changes you'll need to make and some sample code to create the connection.

The TutsPlus.com site has posted the next part of their "Build Your Startup with PHP" series today. This time they show you how to make it even easier for the users of your site to sign up using OAuth and third-party authentication.

In this tutorial, I'll guide you through implementing OAuth integration with common social networks to make signing up and repeated usage easier and more efficient. I'll explore Facebook, Google, Twitter and LinkedIn, the networks I see as being most appropriate to Meeting Planner's target users.

The tutorial makes use of the Yii framework's own AuthClient functionality to make the actual requests to the 3rd party services. They help you get it installed via Composer and the configuration changes you'll need to make for it to be available and functional.

The tutorial then shows how to create developer applications on a few different services: Twitter, Facebook, Google and LinkedIn. They help you update your configuration with the secret keys for each and create a new database update for storing the 3rd party identifiers when the connection is made. Finally they hook it into the user profile and the login page for use by your users.

In this new tutorial posted to his site Freek Van der Herten shows you how to connect your application to the Google Calendar API, complete with screenshots for a step-by-step process.

For a project I’m working on I needed to interact with a Google Calendar. I’ve your ever worked with some API’s by Google then you know their documentation can be very confusing. It’s not that they don’t have documentation, but code examples of common use cases are simply not present. You must wade through a lot of pages to learn basic things such as how to make an authorized request let alone how to fetch calendar events. In this post I’d like to explain in a human readable way how setup and use the Google Calendar API.

He starts on the Google side with the setup of the application and getting the credentials you'll need for the connection. Next up is setting up the calendar itself and the permissions to allow access to all event information. The post then finishes with a PHP example using the "google/apiclient" library to make the Calendar connection and get all events currently on the calendar. As a bonus he also points out a library he's creating to make it easier to work with events in Laravel-based applications.

Kevin Schroeder has a quick post to his site showing the Magento users out there how to configure the SSL connection to their MySQL database backend.

’ve been asked a few times now if there is a way to use encrypted MySQL connections in Magento. [...] The answer, to my surprise, is that there is no way of doing it out of the box.

[...] All database configurations are stored in the local.xml file and the XML specification does not allow numbers for XML node names. So no matter how you try to slice it it looks like getting the SSL settings into the Magento adapter will not work without a code change. The Internet seems to confirm this. But that doesn’t mean that it can’t be done. So I wrote a quick Magento adapter that allows you to pass in the constant values.

He walks you through the process of getting the adapter installed, configuring MySQL to allow for the SSL connections and the configuration change to make. He includes the XML you'll need to update, including the addition of a secure_driver_options to the XML to provide the necessary SSL connection information.

Cees-Jan Kiewiet has a new post today talking about some interesting trickery he was able to do with the AWS (Amazon Web Services) PHP SDK to allow requests to be made asynchronously.

Just got off the AWS SDK for PHP Office Hour hangout and it was great talking with both team members Jeremy and Michael. And one of the things we talked about was async access to the AWS services using the PHP SDK. The goal of this post is to get the AWS PHP SDK client working asynchronously.

He starts with brief instructions on getting the SDK installed (via Composer) along with a library of his own that brings in a few other dependencies. The ReactPHP event loop is what makes the asynchronous connections possible. He includes the code to create the new handler stack and how to use it to make the asynchronous calls. A demo screencast is also included in the post to illustrate the output from a simple set of requests.