Tomas Votruba has put together a new post with a list of five helpful hints for working with GitHub in your development projects.

The best programmers aren't the smartest in the field. They're lazy, they know their tools well and they know good tools other programmers don't.

Do you know the following tips?

His tips include using single-character console command aliases, receiving notifications only when a new package release is made, and the use of the refined-github browser (Chrome/FireFox/Opera) to help reduce required clicks. He also shows how to implement Composer "scripts" for use on the command line - a very useful extension to your Composer configuration.5 Tips to Effective Work with Github Repository

Matt Glaman has written up a post for his site showing how you can write better Drupal code using PHPStan, the PHP static analysis tool.

PHP is a loosely typed interpreted language. That means we cannot compile our scripts and find possible execution errors without doing explicit inspections of our code. It also means we need to rely on conditional type checking or using phpDoc comments to tell other devs or IDE what kind of value to expect. Really there is no way to assess the quality of the code or discover possible bugs without thorough test coverage and regular review.

If you use PhpStorm, you will notice all of their helpers which analyze your code and add static analysis. [...] That's awesome. It's pretty amazing that PhpStorm and a few plugins can give us some stability in our PHP code.

While the functionality in PhpStorm is useful, there are some pitfalls including the fact that everyone would have to use PhpStorm. He makes the suggestion that PHPStan can effectively replace these helpers and, with a bit of customization, provide just as much quality control for your Drupal code. He links over to a custom PHPStan extension for Drupal and an example YAML configuration. He also includes helpful tips around bootstrapping the autoloader, return typing and changes it provides for using the entity manager.

In this new post to his site Tomas Votruba shows how to configure a Symfony application without using the bundle or extension configurations.

Symfony Flex is moving towards of bundle-less applications. That doesn't mean you should create a monolith code in /src as fast as possible, but rather control everything via .yaml and .env files. It's takes few steps to remove extension and move to import of services.yaml.

But how would you approach a simple task as setup a account number parameter?

For those not familiar with "no-bundle applications" in Symfony, he starts with a link to the SymfonyCast course listing out the main points. Following this he covers what changes in the service registration and what changes in the configuration (with code examples). He then provides some options including keeping the extension, setting the parameter manually and binding the parameter, favoring the last two on his list as more maintainable.

In this post to his site Matthias Noback makes the argument that, during your normal development, classes should be final by default and only changed if there's a need to extend them.

I recently wrote about when to add an interface to a class. After explaining good reasons for adding an interface, I claim that if none of those reasons apply in your situation, you should just use a class and declare it "final".

[...] For a couple of years now I've been using the final keyword everywhere (thanks to Marco Pivetta for <a href="https://ocramius.github.io/blog/when-to-declare-classes-final/>getting me on track!). When I see a class that's not final, it feels to me like it's a very vulnerable class. Its internals are out in the open; people can do with it what they want, not only what its creator has imagined.

Still, I also remember my initial resistance to adding final to every class definition, and I often have to defend myself during workshops, so I thought it would help if I explained all about it here.

He starts off by talking about the alternative - non-final classes - and some of the issues that can come with it (and class extension). He makes the suggestion that "replacing is better than overriding" and creates less complexity overall. He also answers a question about the use of the "Template Method" design pattern that would allow for improvement from base "skeleton" logic designed to be extended. He covers "composition over inheritance", the use case of extension and how "final" is a better direction.

On the php[architect] site they've posted a full article from their July 2018 issue sharing information about a new kind of data store in MySQL.

Do you work on projects where you begin coding before knowing what your data looks like? Or are you part of the vast majority of developers who have had little or no training in database theory, relational calculus, Structured Query Language, or sets? Could you be working on a project without a database administrator to set up relational tables, indexes, and schemas? Or are you tired of embedding ugly lines of SQL in your pristine PHP code? There is new hope for you.

In the article Dave Stokes (of MySQL/Oracle) covers the new native JSON data type that was added in MySQL 5.7 but enhanced in MySQL 8 as a document store. He shows how to use this new functionality from the command line, what a "document" is and how to install and use the X DevAPI PECL extension to make use of it from your PHP code.

With each new major version of the PHP language comes a long list of changes. Along with these changes can come breakage with software that's not a direct part of the PHP core (or extensions). In this post to his site Remi Collet lists out a large number of the more popular PHP extensions and, along with the specific version numbers, breaks down which will work and which won't.

He actually has three lists: "compatible", "work in progress" and "not compatible for now". Fortunately, the "compatible" list is the longest and includes:

• geoip
• ip2location
• redis
• sphinx
• zookeeper
• varnish

There's also a pretty sizable list for the "work in progress" category, most of which are already in the "fixed upstream" category or have pull requests waiting for review to fix issues that were found. Most of the items in the "not compatible" list are either projects that are out of date or have moved away from the PECL extension approach to something more based in user-land code.

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.

On the Laravel News site there's a tutorial posted showing you how to use the Swole extension to speed up your Laravel-based application. Swole is a PHP extension written in C that provides missing asynchronous functionality to the language.

Swoole is a production-grade async programming framework for PHP. It is a PHP extension written in pure C language, which enables PHP developers to write high-performance, scalable, concurrent TCP, UDP, Unix socket, HTTP, WebSocket services in PHP without too much knowledge of the non-blocking I/O programming and low-level Linux kernel. You can think of Swoole as something like NodeJS but for PHP, with higher performance.

The post covers the "why?" question of using Swoole with Laravel, explaining how the traditional PHP request flow works. Swoole provides a way to reduce come of this processing overhead and increase performance. They then help you integrate Swoole and Laravel using a custom package (swooletw/laravel-swoole), installing both the package and using PECL to install the Swoole extension. Once the extension is enabled and the service provider is added, all it takes is an artisan command to start the web server up.

The post finishes with some quick benchmarks using wrk comparing it against a typical Nginx setup with PHP-FPM. Not surprisingly, Swoole outperforms the other setup well.

On the Zend Framework blog there's a new tutorial posted that wants to help you use Expressive for asynchronous request handling with the help of the Swoole extension.

When we were finalizing features for Expressive 3, we had a number of users testing using asynchronous PHP web servers. As a result, we made a number of changes in the last few iterations to ensure that Expressive will work well under these paradigms.

Specifically, we made changes to how response prototypes are injected into services.

The article starts by talking about the issue with the previous response prototype handling, mostly that, in an async world, all responses would be sharing the same instance rather than rebuilding a new one for each request. It then explains their reasoning behind even worrying about async support in the framework's response handling noting that the major reason had to do with the performance gain. The post mentions the Swoole extension and shows how to install it via PECL but you'll need to check out the project's documentation to see how to create a server that makes use of it.

In a new post to his site Derick Rethans talks about "analemmas" and shows how to use PHP's own DateTime handling to determine the locations of the sun at different intervals (that's what an "analemma" tracks).

Last week I listened to an The Sceptics' Guide to the Universe where the word of the week was "But as I am currently starting to update the Guide to Date and Time Programming for a second edition, I was wondering whether I could create an analemma from existing PHP functions. Unfortunately, PHP only provides functionality to calculate when the Sun is at its highest point, through date_sun_info().

He includes an example of this function in use to determine the time the sun was at its zenith. While PHP by itself can't calculate the position, Derick remembered a PHP extension he wrote that could help: php-solarsystem. He includes some code using this functionality to iterate and locate the sun via its azimuth and altitude based on his choice of location (London). The result is a CSV export of data that he then drops in to gnuplot to create the graph of the analemma during that time.