Morphos – morphological solution in PHP for English and Russian

If you ever had to deal with morphology in English, you probably found one or two libraries to help you out.  But if you had to do that for Russian, than I’m sure you are missing a few hairs, and the ones that you still have are grayer than they used to be.  I’ve got some good news for you though, now there is Morphos (GitHub repository).

Morphos is a morphological solution written completely in the PHP language. Supports Russian and English. Provides classes to decline First/Middle/Last names/nouns and generate cardinal numerals.

Just look at this beauty!

var_dump($dec->getForms($user_name, $dec->detectGender($user_name)));
/* Will produce something like
  array(6) {
    string(8) "Иван"
    string(10) "Ивана"
    string(10) "Ивану"
    string(10) "Ивана"
    string(12) "Иваном"
    string(15) "об Иване"

Just this alone can make user interfaces and emails so much better.  But there is more to it than that.

Vim setup for PHP development

Robert Basic shares his “current Vim setup for PHP development“.  He shows how setup the Gutentags plugin, jump to definitions with CtrlP plugin, display of the current file and method in the status line, add support for PHP namespaces, improve linting with Asynchronous Lint Engine, and add support for PHPStan.

Via PHPDeveloper.

PHP overwrite of built-in constants (true is false)

Here is a scary thing I picked up on Reddit PHP:

use const true as false;
if (false) {
    echo "uh-oh";

Until PHP 5.6 this was throwing a parse error, but from then on – it’s just fine.  Scary, right?

The comments on the Reddit thread are quite helpful.  Technically, this is not overwriting (shadowing?) since the original constant is still available:

use const true as false;
if (\false) {
    echo "uh-oh";

If you are a fan of nightmares, there is also this link, which will shake your religious beliefs …

pds/skeleton is now stable

PHP Package Development Standard, aka pds/skeleton, is now stable.  I’ve linked to it before and I think it’s a great idea and I’m glad I’m not alone:

Roughly 78,000 packages already comply with the pds/skeleton standard, although they may not know it. To formally show that your package has adopted the standard, “require-dev” it via Composer, or display a badge on your README.

I’d gladly follow this standard for my own work too, except that I mostly work with WordPress and CakePHP these days, both of which do things differently from the standard and from each other.

WordPress kind of assumes that the whole project is public, so you don’t really get public/ folder.  It also organizes the code into wp-includes/, wp-admin/ and wp-content/ folders, instead of the src/ suggested by PDS.  And, in terms of configuration, everything goes into wp-config.php file instead of something in the config/ folder.

CakePHP is much closer to PDS in terms of organization of files.  The only difference that I can spot is the use of webroot/ folder instead of the suggested public/.

I’d really love to see larger libraries and frameworks adhere to the PDS, but until that happens, I’ll keep an eye on things.

P.S.: The standards comic strip is of course from xkcd.

PHP assertions

When I hear the word “assertion”, the first thing that comes to my mind is PHPUnit assertions.  Sure, I write assertions in my unit tests.  But is that the only application?  Today I decided to figure it out, or, at least, learn more about the subject.

It turns out that PHP has assert() and assert_options() functions.  And those were there since the ancient times of PHP 4.  Sounds cool, but how useful are these?  Well, not that much:

Assertions should be used as a debugging feature only. You may use them for sanity-checks that test for conditions that should always be TRUE and that indicate some programming errors if not or to check for the presence of certain features like extension functions or certain system limits and features.

Assertions should not be used for normal runtime operations like input parameter checks. As a rule of thumb your code should always be able to work correctly if assertion checking is not activated.

This StackOverflow discussion expands a bit on the subject and concludes that assertions are just a developer tool used for troubleshooting and such. Bummer!

But I’m not that easily stopped.  Next stop – search for tools and libraries on GitHub and Packagist.  There’s more luck here!  A whole lot of different libraries exist that help with asserting facts and matching values to patterns.  I’ve checked a few of them and here’s the Top 3 List that I’m considering for use in my code:

  • beberlei/assert – simple to use library, with a respectable number of implemented assertions.  It supports chained methods, lazy assertions, and is easy to extend.  (See this blog post, announcing version 2 a few years back.) Also, the fact that almost 300 projects depend on it, makes it an attractive choice.
  • nilportugues/php-assert – also an easy to use library, which offers even more assertions, grouped into a number of categories (generic, string, integer, float, array, date and time, object, and file upload).  It’s not anywhere near as popular as the previous option, but that is probably just a question of time.
  • peridot-php/leo – a much more advanced assertion and matching library than the previous two options.  In fact, so much more advanced, that it has a dedicated documentation website.  This is understandable, as this library is a part of the Peridot BDD testing framework.  It is easy to extend too, but I’m not sure yet that I need that level of complexity in my projects.

I found a few more alternatives, but they looked like side projects or small toolboxes for specific needs.  None of those impressed me enough to be linked here.

It’s too late at night to make a decision right now on which project I like the most.  But I will definitely play more with the ones above.  If you have any experience with those or with any other assertion/matching library, I’m interested to hear.


PHP vs Python vs Ruby: Detailed Comparison

PHP vs Python vs Ruby: Detailed Comparison compares the three popular languages in a variety of categories, such as total market share, large website deployments, usability, learning curve, popularity, performance, etc.  It’s a nice overview if you are about to pick one of these languages for the future projects, or if you are (like me) have been stuck with one of them for a long time, and haven’t really kept an eye on what’s going on in the rest of the world.

Migrating a PHP 5 App to PHP 7

This year I’ll be migrating quite a bit of stuff from PHP 5 to PHP 7.  We haven’t started with the process yet, but with the recent indicators like PHPUnit 6 release, I’m sure the priority of this work will start rising.

Obviously, I’m familiar with the new features of PHP 7 and some of the things that will have to be done in order to port the applications and make use of the new version.  But it still helps reading through articles like “Migrating a PHP 5 App to PHP 7 “, which comes in two parts:


Preparing for the PHPUnit 6 and PHP 7

If you woke up today and found that most of your PHP projects’ and libraries’ tests break and fail, I have news for you:  you are doing something wrong.  How do I know?  Because I was doing something wrong too…

First of all, let me save you all the extra Googling.  Your tests are failing, because a new major version of PHPUnit has been released – version 6.0.0.  This version drops support for PHP 5 and, using the opportunity of the major version bump, gets rid of a bunch of stuff that was marked obsolete earlier.

But why does it fail, you ask.  Well, because PHPUnit is included in pretty much every composer.json file out there.  And the way it’s included is almost always is this:

"require-dev": {
"phpunit/phpunit": "*",

PHPUnit being a part of pretty much every composer.json file, is probably the reason why people want to be much more relaxed with the used version, than with any other component of the system.  That’s usually good.  Until it breaks, much like today with the release of the PHPUnit 6.

How can you fix the problem? Well, the quickest and the easiest solution is to update the composer.json with “^5.0” instead of “*”.  This will prevent PHPUnit from upgrading until you are ready.

While you are doing it, check the other dependencies and make sure that none of them are using the asterisk either.  Because, chances are, the exact same problem will happen later with those too.

The only difficult bit about this whole situation is the correlated drop for the PHP 5 support.  Yes, sure, it has reached its end of life, but there are still a lot of projects and environments that require it, and will require it for a lonweg time.

As you are the master of your code and dependencies, other people are of their own.  So you can’t really control when each of your dependencies will update the requirement for the PHPUnit 6, or any other tool that requires PHP 7.

On the bright side, major releases of PHP don’t happen that often, so this shouldn’t be the frequent problem.

composer-patches – Simple patches plugin for Composer

composer-patches is a plugin for Composer which helps with applying patches to the installed dependencies.  It supports patches from URLs, local files, and from other dependencies.

I think this is absolutely brilliant!

It’s quite often that one finds bugs and issues in external dependencies.  Once the bug (or even the pull request with the fix) is submitted to the vendor, it can take anywhere from a few hours to a few weeks to be resolved and a new version to be released.

If you have a fix for the problem and need it in your project right away, and can’t wait until the vendor releases the new version, your best choice is to fork the dependency, fix the problem, and use your repository instead of the vendor’s package.  This works, but it’s messy.

With the patches plugin to composer, you can still use the vendor’s package and just apply a patch with composer, until the new version is available.  Clean and simple.

This also helps with testing things and working with different changes by different people, if you want to try things out – no need to choose between multiple repositories.  Just select the patches that you want and apply them at the environment you need.

Given that most development work is happening on GitHub these days, this composer plugin is even more useful than what I might think at first.  You see, GitHub provides patch and diff URL for each commit – all you need to do is add the extension to the URL.  For example, take this recent commit to my dotfiles repository.

Commit screen

If you add a “.patch” extension to this URL, you’ll get a patch output, which is useful for git am, and other commands (more on using git with email):

Patch screen


If you add a “.diff” extension to this URL, you’ll get a unified diff output, which you can either apply with diff and patch utils, or use with the composer-patches plugin.

Unified diff screen

So, this gives you a way of applying any commit on GitHub (and other repositories) via composer to any of your dependencies.  This is mind blowing!