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!

 

Sharing constants between PHP classes

When writing larger applications, it is often useful to have some constants defined, which can then be shared between different parts of the application.  There are several ways to do this, and there is no real rocket science here.

However, the question is: what’s the best way to do so?

Until now I haven’t seen an elegant solution to this problem.  The old school way was defining the constants in the separate include file or in a class, and then accessing them through the global scope or via a specific class.  With a moderately modern PHP version, class constants can also be redefined by an inheriting class, which is, I think, more useful than painful.

Today, I came across an implementation that I really liked.  It’s simple and elegant: define constants in the interface and let classes implement it.  I saw it in the HTTP Message Util library, which defines HTTP methods, status codes and the like for the libraries and applications implementing PSR-7 standard (HTTP message interface).  Look here, for example.

I played around for a few minutes with this and it worked really well.  Until I stumbled upon something.  PHP classes can override the constants from the classes they inherit.  But not from the interface.  Here’s what PHP manual on Object Interfaces has to say about that:

It’s possible for interfaces to have constants. Interface constants works exactly like class constants except they cannot be overridden by a class/interface that inherits them.

This seems reasonable.  After all, the interface is a contract, and whatever is part of it should be precisely so in the implementing classes.  If you try to redefine the constants in the class:

<?php
interface FooInterface
{
    const FOO = 1;
}

class Foo implements FooInterface
{
    const FOO = 1;
}

echo "Foo = " . Foo::FOO . "\n";

you get an error:

PHP Fatal error: Cannot inherit previously-inherited or override constant FOO from interface FooInterface in foo.php on line 7

That sounds about right.  But!  It looks like you can overwrite the interface constants by extending the class.  The following snippet happily prints out two and throws no errors or warnings (my Fedora 25 runs PHP 7.0.14, if you were wondering):

<?php
interface FooInterface
{
    const FOO = 1;
}

class Foo implements FooInterface
{
}
class Bar extends Foo
{
    const FOO = 2;
}

echo "Foo = " . Bar::FOO . "\n";

Weird, right?  But there is more.  If the extending class implements the interface, rather than inherit its implementation from the parent, then the error is back:

<?php
interface FooInterface
{
    const FOO = 1;
}

class Foo implements FooInterface
{
}
class Bar extends Foo implements FooInterface
{
    const FOO = 2;
}

echo "Foo = " . Bar::FOO . "\n";

results in the familiar error, with the adjusted line number:

PHP Fatal error: Cannot inherit previously-inherited or override constant FOO from interface FooInterface in foo.php on line 10

Additionally, PHP provides the final keyword, which can be used to prevent overwriting of the inherited method by the child classes.  However, final keyword is not allowed on the constants, which makes results a bit more difficult to predict.  Especially so with the late static binding.  Here is an example:

<?php
interface FooInterface
{
    const FOO = 1;

    public function hello();
}

class Foo implements FooInterface
{
    public function hello()
    {   
        echo __FUNCTION__ . ": Self " . self::FOO . "\n";
        echo __FUNCTION__ . ": Static " . static::FOO . "\n";
    }   

    final public function bye()
    {   
        echo __FUNCTION__ . ": Self " . self::FOO . "\n";
        echo __FUNCTION__ . ": Static " . static::FOO . "\n";
    }   
}
class Bar extends Foo 
{
    const FOO = 2;
}

echo "\nFrom Foo\n";
$foo = new Foo();
$foo->hello();
$foo->bye();

echo "\nFrom Bar\n";
$bar = new Bar();
$bar->hello();
$bar->bye();

Which results in:


From Foo
hello: Self 1
hello: Static 1
bye: Self 1
bye: Static 1

From Bar
hello: Self 1
hello: Static 2
bye: Self 1
bye: Static 2

I can’t say for sure whether overwriting interface constants in inherited classes is a bug or not, but the current behavior does feel weird.

RethinkDB: why we failed

Startups are born and gone every single day.  Much more often so in technology sector.  Most of these just disappear into the ether.  RethinkDB at least leaves the useful trace of analysis of what happened and why they failed.

When we announced that RethinkDB is shutting down, I promised to write a post-mortem. I took some time to process the experience, and I can now write about it clearly.

In the HN discussion thread people proposed many reasons for why RethinkDB failed, from inexplicable perversity of human nature and clever machinations of MongoDB’s marketing people, to failure to build an experienced go-to-market team, to lack of numeric type support beyond 64-bit float. I aggregated the comments into a list of proposed failure reasons here.

Some of these reasons have a ring of truth to them, but they’re symptoms rather than causes. For example, saying that we failed to monetize is tautological. It doesn’t illuminate the reasons for why we failed.

In hindsight, two things went wrong – we picked a terrible market and optimized the product for the wrong metrics of goodness. Each mistake likely cut RethinkDB’s valuation by one to two orders of magnitude. So if we got either of these right, RethinkDB would have been the size of MongoDB, and if we got both of them right, we eventually could have been the size of Red Hat[1].

Thank you, guys.  There are valuable lessons in there.  And three points, of course:

If you remember anything about this post, remember these:

  • Pick a large market but build for specific users.
  • Learn to recognize the talents you’re missing, then work like hell to get them on your team.
  • Read The Economist religiously. It will make you better faster.

Generate PHP Class Inheritance Diagrams with Graphviz

It’s not a secret that I’m a big fan of GraphViz – powerful, yet easy to use graph visualization software.  And I’ve blog about it quite a few times.  Well, guess what – today is a perfect day for one more post.

Over the weekend I was working on refactoring some CakePHP code that I had my on for a long time now.  As with any powerful framework, the projects can get quite big and it might be difficult to make sense of the hierarchy and relationship of certain files, especially if it’s been a while since you looked at that code, and you are not a fan of IDEs, and you’ve been non-stop coding for more than 24 hours.

I had this problem once or twice before.  To the extent that I’ve written a CakePHP plugin, which was using GraphViz to visualize models and their relationships.  But that was a long time ago.  The plugin got outdated (it was for CakePHP 1 and/or 2, so not very useful now that we are in version 3).  Furthermore, today I needed to look not at the models and their relationships, but at a hierarchy of the PHP classes in some other directory.

A quick Google search suggested Nigel Chapman’s post – How to Generate PHP Class Inheritance Diagrams in Graphviz.  Not only it was pretty much exactly what I was looking for, but it was also from a fellow CakePHP developer!

I’ve taken (borrowed?) Nigel’s script and modified it slightly.  You can find my version here.  The changes are:

  1. Added two parameters which allow to specify the name of the destination file and the GraphViz tool to use for the generation of the graph (more on that below).  If omitted, the destination file will be created with the temporary name in the temporary directory, and the sfdp script will be used as default.
  2. Added the resulting path to the output at the end of the execution of the script, so that if it is a temporary file, I would know where to look for it.
  3. Added grep and sed patterns to work correctly with abstract classes.
  4. Changed grep to look only for the *.php files, instead of anything.  This can make things much faster on messy projects, and it also removes the need for working around the binary files.

Now it’s so handy that I made it a part of my dotfiles, so that I can save a few precious moments looking for the solution in 2024.

This also seems like a good opportunity to review the which tools are available for generating the graph and what are the differences between them.  For that, we don’t need to look any further than the front page of the GraphViz website (in the Roadmap section):

dot – “hierarchical” or layered drawings of directed graphs. This is the default tool to use if edges have directionality.

neato – “spring model” layouts.  This is the default tool to use if the graph is not too large (about 100 nodes) and you don’t know anything else about it. Neato attempts to minimize a global energy function, which is equivalent to statistical multi-dimensional scaling.

fdp – “spring model” layouts similar to those of neato, but does this by reducing forces rather than working with energy.

sfdp – multiscale version of fdp for the layout of large graphs.

twopi – radial layouts, after Graham Wills 97. Nodes are placed on concentric circles depending their distance from a given root node.

circo – circular layout, after Six and Tollis 99, Kauffman and Wiese 02. This is suitable for certain diagrams of multiple cyclic structures, such as certain telecommunications networks.

As they say, GraphViz to the rescue once again!

NCR Patents the Internet

I came across this old story (back from 2003) on Slashdot – NCR Patents the Internet – and it even more hilarious now than it was back than:

We all know about NCR’s lawsuit against Palm & Handspring, but I haven’t seen much press about patent infringements they are claiming against some of the biggest sites on the planet. According to documentation that a friend’s company has recently received, their patents protect everything from keyword searching to product categorization. Patents to look for (and filed in 1998) include 6,253,203, 6,169,997, 6,151,601, 6,085,223 and 5,991,791 . IMHO, this is absolutely outrageous and is likely to cause billions in both legal fees and eventual licensing fees (eBay, Amazon and MSFT have already licensed from NCR). How is this not the lead story on every site? every day? Maybe because no one wants to get sued for having an online business.

The comments are hilarious as well.