PHP - Leonid Mamchenkov

Highlights from Git 2.19 and PHP syntax

GitHub blog covers the highlights from Git 2.19, which was recently released.

One particular change that I want to highlight (which GitHub skipped in their highlights, but which exists in the Git release notes for this version) is the syntax pattern update for the PHP files.

Let’s have a look at the full diff of this release. The particular change I am referring to is in the userdiff.c file. Git now understands final, abstract, interface, and trait keywords.

If you are not sure where and how it is used, here are a couple of useful links for you:

.gitattributes documentation section on settings the syntax of the file for diffs. Basically, you just need to add “*.php diff=php” to the .gitattributes file. Unfortunately, this is done on a per-project level, rather than globally on a user level. (See this blog post for more details).
More info on the same subject: How Does Git Know What Functions Look Like?

Now that you have it all configured, there are a couple of ways to benefit from this functionality. First, you’ll see a more useful context comment in the diffs. Here’s the screenshot (using an older git version still). On the left, the diff without the PHP syntax configured, and on the right is the diff with the PHP syntax configured:

As you can see, on the left, the context shows that the change was done somewhere in the ChangeLogTrait trait. On the right, the context is much more specific – it shows that the change was done in the public function changelog.

This makes reviewing code changes a lot easier. But there is also one other place where this is useful – in reviewing the history of a particular function. For example, running “git log -L :changelog:ChangelogTrait.php” will produce the git log output containing only the commits and diffs on the function changelog in the file ChangelogTrait.php. Very handy!

laravolt/avatar – plug-n-play PHP library for quick dynamic avatars

laravolt/avatar is a PHP library that helps to avoid those old and boring anonymous face pictures for users who haven’t uploaded or configured their avatar in your application. With library you can use any string – name, email, initials, or anything else you fancy – to generate a dynamic avatar with random color and letters.

php-jsonq – a simple, elegant PHP package to query over any type of JSON data

php-jsonq provides an easy, yet powerful way to build queries for any JSON data (or PHP data structures for that matter, which are a step away). This has a variety of useful applications – data migration, API response filtering, complex configurations manipulation, and so on, and so forth.

The Complete Guide to WordPress Performance Optimization

SitePoint runs an extensive guide to the WordPress performance optimization. Not only it goes over the usual points like hosting selection and avoiding unnecessary plugins, but it also provides some insight into the WordPress database management and optimization, web server tweaks, and links to a few handy tools to help with performance of your site.

Semantic Versioning : Version 0 is unstable

We’ve been using Semantic Versioning for quite a while at work now. It’s easy to explain and follow, and it provides valuable context to the numerous releases of the projects and components that we are doing on a daily basis.

Turns out, however, that I missed a small, but important part of the standard. All releases in major version 0 are considered to be unstable, so even if they introduce backward compatibility breaking changes, there is no need to increment the major version to 1. Here’s the relevant quote:

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

If you are relying on the semantic versioning in your projects, make sure to check your dependency management tool, to verify that it handles major version 0 correctly. Gladly, for us, composer does the job:

The ^ operator behaves very similarly but it sticks closer to semantic versioning, and will always allow non-breaking updates. For example ^1.2.3 is equivalent to >=1.2.3 <2.0.0 as none of the releases until 2.0 should break backwards compatibility. For pre-1.0 versions it also acts with safety in mind and treats ^0.3 as >=0.3.0 <0.4.0.