On TheCodingMachine.io there's a tutorial posted by David Négrier covering an interesting idea when handling "falseness" in your PHP application - throwing exceptions rather than returning false. In this case, he introduces the "safe" library to help make this easier.

At TheCodingMachine, we are huge fans of PHPStan. PHPStan is an open-source static analysis tool for your PHP code. [...] PHPStan has this notion of "levels" and we strive on each of our projects to reach "level 7" (the maximum level). But PHPStan is constantly improving, and reaching level 7 becomes harder and harder as the tool becomes more strict (this is a good thing!).

The post includes an example of this increasing strictness, showing how a more recent check looks at a file_get_contents call and ensures all possible return values are evaluated (it returns false when it errors). They refactor the code example to more correctly check for this, but losing some of the "expressiveness". The tutorial then spends some time talking about the history of PHP and why things return false rather than throw exceptions on error. It covers some of the basics of how the safe library works and a PHPStan extension that can help find places that need to be wrapped by "safe" to throw exceptions when false is returned.

Earlier this month, the Symfony blog made an announcement about a new browser testing and web scraping tool that's been released under the Symfony umbrella: Panther.

Since the very first version of Symfony 2, the framework provides a suite of convenient tools to create functional tests. They use the BrowserKit and DomCrawler components to simulate a web browser with a developer-friendly API.

The post starts with a "refresh" of the current WebTestCase helper functionality to create these functional tests. They also include an example of a repository class that stores/retrieves the news and a matching controller to handle the requests (and Twig templates for output). They then create a test using the WebTestCase functionality to get the index and ensure that some of the content is correct.

The tutorial then takes this same scenario and applies tests using the new Panther functionality. Where the WebTestCase uses a simulated browser internal to the framework, Panther uses an actual browser to run is tests using the Facebook PHP WebDriver library. They show the slight updates that would need to be made to the current test and the resulting output.

The tutorial goes on to provide other examples of tests for API requests and Javascript functionality for a Vue.js frontend. It wraps up mentioning some of the additional functionality Panther includes such as the ability to take screenshots and injecting Javascript into the pre-rendered page.

Larry Garfield has written up a post with a somewhat controversial headline, especially for anyone that's done any kind of unit testing on a larger codebase. His suggestion is to no use mocking libraries and some other techniques that can replace them.

I am all for testing. [...] There's a lot of opinions on what constitutes a "good" test, of course, and much is subjective to the type of code you're working on. However, since the release of PHP 7 I've found that while writing tests... I am never using a mocking library. In fact, I'm going to go as far and say that you should never use a mocking library in PHP 7.

Before all of you gasp, clutch your pearls, and send ninja hit squads after me, let me justify that position.

He starts off by defining what a "mock" is a more general sense and then, more specifically, how mocking libraries are mostly implemented in PHP. He covers the DSL (domain specific language) knowledge that's required to use most of them and how something already included in PHP 7 - anonymous classes - could be a viable alternative. He goes on to show examples of using this method rather than a mock for simple object handling and even recommends making an actual class (just for testing) if the need is there. He ends the post talking about the "upper bounds" of when this might not be as useful and how this can actually be good (using it as an indicator that you need to refactor the main code to simplify).

In a new post to his site Matthias Noback takes a look at the concept of assertions and some libraries including some effective ways to use them in your code for validation of values.

When you're looking at a function (an actual function or a method), you can usually identify several blocks of code in there. There are pre-conditions, there's the function body, and there may be post-conditions. The pre-conditions are there to verify that the function can safely proceed to do its real job. Post-conditions may be there to verify that you're going to give something back to the caller that will make sense to them.

[...] Sometimes the programming language itself can help with these pre-conditions: for instance, the language may support strict typing, which prevents certain types of invalid input to be provided. Some languages offer more advanced ways of defining pre-conditions, like pattern matching.

Following a brief use case for assertions (at a high level) he gets more specific to PHP and mentions two assertions libraries that could be used to add these kinds of checks to your code (in addition to PHP's own assert function). He then answers the "why use assertions?" question and some basic rules around using them:

• don't use assertions to validate user input, use it to validate function arguments.
• don't use assertions to validate return values from other functions.
• don't use assertions as a replacement for exceptions.

For each of these, he provides a summary with a bit more background and code examples to help illustrate the point. He ends the post with some useful "rules of thumb" when using assertions and a reminder:

Assertions are sanity checks. When they would be left out, you should still have a correctly function application. They should never become user-facing errors.

On the Laravel News site there's a post spotlighting an interesting string manipulation library (Twine) and some of its basica features and use.

Twine is a stand-alone PHP 7 package by Chris Kankiewicz for string manipulation and comparison with an expressive fluid syntax.

They provide several code examples showing the package in action:

• adding padding to the left/right
• uppercase/lowercase
• starts with/contains/ends with
• converting the string to a hash
• basic string formatting

The package also makes use of a fluent interface, making it easier to stack multiple operations onto a string (like checking to see if a substring equals a value). You can find out more about the package on its GitHub repository.

Vladimir Goncharov has a tutorial posted to his Medium.com site showing how to integrate machine learning and computer vision into a PHP application using the opencv library. The php-opencv library is a C-level implementation (via an extension) making it easer to use it directly from PHP.

Now, “Machine learning” is developing very fast, it has already written a lot of articles, including the ones on the medium, and almost every developer would like to start using it in their work tasks and home projects, but where to start and what to use is not always understandable. Most articles for beginners offer a bunch of literature, on the reading of which there is not enough life, “inexpensive” courses, etc.

[...] I was considering writing a php-opencv module by myself using SWIG and spent a lot of time on it, but I did not achieve anything. [...] Then I found the library of php-opencv on the github space, it is a module for php7, which makes calls to opencv methods.

He then starts in on the code making use of the library to read in images, perform face detection, facial recognition, and locating facial marks/landmarks. He also includes a section covering the use of neural networks to improve the quality of images, classify them and the use of Tensorflow models to detect certain kinds of objects. The post ends with a look at getting the requirements installed to use the tool and links to other examples.

Joe Watkins has a post on his site sharing a project he has been working on to create a debugger for PHP applications that can be installed easily and understood by those already having knowledge of PHP.

We already have several options for debugging code within the PHP ecosystem. XDebug is extremely mature software, and phpdbg has been slowly gaining traction also, if for no other reason than it's very fast to collect code coverage compared to XDebug.

[...] Debugging is a necessary part of writing code; If you disagree with this statement, then I don't know what you are talking about. [...] Using a debugger is like having an army of nano bots at your disposal, each one trained exquisitely in a top nano-bot-training-camp, they live to kill cockroaches, some of them also have mean looking tattoos, chew tobacco, and spit on the ground at the start of every sentence ...

He goes on to talk about why he made the choice to write the debugger with a PHP interface. He then gets into some of the specifics of debugging needs and links to the krakjoe/inspector repository for the tool. The README has more information about the interface and functionality than the blog post does, so if you're interested to read more, head over there.

The TutsPlus.com site has a new tutorial posted showing you how to boost the performance of your PHP application with the help of PhpFastCache. PhpFastCache is a library that can either be installed manually or via Composer.

PhpFastCache is a library that makes it a breeze to implement caching in your PHP applications. It's an easy-to-use and yet powerful library that provides several APIs to help you implement a caching strategy of your choice without much hassle.

Don't make the mistake of assuming that it's merely a traditional file system caching scheme. In fact, PhpFastCache supports a plethora of adapters that let you choose from high-performance back-ends like Memcache, Redis, MongoDB, CouchDB, and others.

The article starts by helping you install (via Composer) and configure the library with the default file storage method. They talk you through all the code required to configure the caching and using the CacheManager to get and set values as well as checking to see if they're already cached. The tutorial also includes a bonus section showing how to use Redis for the storage rather than local file storage making it easier to share the cache data across multiple systems/servers.

Tomas Votruba has a post to his site that (sort of) continues his look at the parsing of PHP code into an AST and the use of the nikic/php-parser library. In this new post however, he covers several of the things that can be changed in PHP code using the library.

Today we can do amazing things with PHP. Thanks to AST and nikic/php-parser we can create very narrow artificial intelligence, which can work for us.

Let's create first its synapse!

He starts with a clarification about the difference between "php-ast" (an extension) and "PHP AST" (the actual abstract syntax tree). It then gets into some of the functionality that the php-parser library provides for modifying the PHP code being parsed. This includes changing method names, renaming properties, splitting classes and even potentially upgrading an application to a newer version. As an example he shows how to change the name of a method and write the result out to a file (all code is included).

In a new post to his site Cees-Jan Kiewiet covers a new library he discovered - Cigar - and how to use it for smoke testing a ReactPHP application. Smoke testing (or "sanity testing") is the evaluation of the major functionality of an application rather than individual pieces of code.

Last week I came across Cigar, a smoke testing tool by Matt Brunt. Which, to me, is great stepping stone for my personal projects/sites to integration tests. In this post we not only go into Cigar, but also how to start your HTTP ReactPHP application, run cigar against it, and shut it down again. (Note that it doesn't have to be a ReactPHP application it can also be a NodeJS app, or PHP's build in webserver you use for testing.)

He then walks through the process of installing Cigar and creating the initial configuration file of endpoints to test (along with expected statuses). He then shows how to automate things further and creates a bash script that starts the ReactPHP application, runs the tests then shuts the application down. It's a simple script but can help save a few keystrokes every time the tests are run.