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.

The Three Machines

It’s amazing how well-timed this article is for the things that go on around me right now.  But even if you are not spending most of your days, nights, and weekends building a company at this moment, have a go at it anyway.   Here’s a bit to get you started:

My current hypothesis is that if you are a CEO, focus your organization on the three machines. Product, Customer, and Company. Then, have a direct report own one of them. If you have a sub-scale leadership team (e.g. you are three founders and four other employees), as CEO you can own one, but not more than one. As you get bigger (probably greater than 20 employees), hopefully now you have enough leadership to have one person own each, but recognize that if someone is being ineffective as a leader of one of the machines, you will have to replace them in that role (either by firing them or re-assigning them).

 

Google and HTTPS

Here are some interesting news on the subject of Google and HTTPS:

In support of our work to implement HTTPS across all of our products (https://www.google.com/transparencyreport/https/) we have been operating our own subordinate Certificate Authority (GIAG2), issued by a third-party. This has been a key element enabling us to more rapidly handle the SSL/TLS certificate needs of Google products.

As we look forward to the evolution of both the web and our own products it is clear HTTPS will continue to be a foundational technology. This is why we have made the decision to expand our current Certificate Authority efforts to include the operation of our own Root Certificate Authority. To this end, we have established Google Trust Services (https://pki.goog/), the entity we will rely on to operate these Certificate Authorities on behalf of Google and Alphabet.

The process of embedding Root Certificates into products and waiting for the associated versions of those products to be broadly deployed can take time. For this reason we have also purchased two existing Root Certificate Authorities, GlobalSign R2 and R4. These Root Certificates will enable us to begin independent certificate issuance sooner rather than later.

We intend to continue the operation of our existing GIAG2 subordinate Certificate Authority.

If you need a bit of help putting this into perspective, this Hacker News thread has your back:

You can now have a website secured by a certificate issued by a Google CA, hosted on Google web infrastructure, with a domain registered using Google Domains, resolved using Google Public DNS, going over Google Fiber, in Google Chrome on a Google Chromebook. Google has officially vertically integrated the Internet.

Choosing the “best software”

Julia Evans has a nice blog post about choosing the “best software”.  Here is my favorite part:

So, let’s talk about another way to think about making decisions than “what is the Best Thing in this situation”.

I run an event series called “lightning talks and pie”. At the most recent one, Ines Sombra gave a talk about capacity planning. In it, she said that there are 3 reasons you might want to change something about your system:

  1. It’s too expensive
  2. It’s too difficult to operate (humans spend a ton of time worrying about it)
  3. It’s not doing the job it’s supposed to

I find these 3 criteria a lot easier to reason about than the “Choose The Best Thing” framework.

She provides some examples on how to apply this thinking, as well as how to deal with tradeoffs and limitations.

HTML Canvas Tutorial

Skilled.co put together this HTML Canvas Tutorial, which covers the HTML 5 <canvas> functionality, that allows web developers to draw all sorts of graphics on the fly, using JavaScript.  The tutorial is available for download in PNG and PDF formats, as well as on the webpage, and it covers the following:

  • Shapes
  • Styles and color
  • Text
  • Images
  • Transformations
  • Compositing and clipping
  • Animation
  • Pixel manipulation
  • Hit regions and accessibility

It also provides a few useful tips, inspiration, and links to other resources.

What’s the best framework for building mobile apps?

It’s been a while (a few years actually) since I looked at building a mobile application.  I don’t have the need to build one now, but I like keeping an eye on what’s going on that domain.

Even back when I was involved with mobile applications, the better approach was to use a framework, rather than building the app from scratch.  The frameworks that existed at the time would help with building a cross-platform (Android, iOS, Windows Mobile, etc) application, and have a better integration with the mobile’s hardware and features (touchscreen, networking, vibration, camera, etc.)

As with many other cutting edge technologies, things move very fast and things get outdated pretty quickly.  So it was interesting to read – What’s the best framework for building mobile apps? – which covers today’s options.  Some of the solutions survived the last few years, some didn’t, and there are a few new ones.  The frameworks covered in the article are:

The article is a good quick overview of what’s out there and why to pick one over the other.