Tag: web development

Feature Flags in PHP

Today edition of the “Four short links” from the O’Reilly Radar, brings a quick overview of the different feature flag implementations.  It touches on the following:

  • Command-line flags, with the link to gflags.
  • A/B flags
  • Dynamic flags, which are more difficult
  • More complex systems.

I’ve dealt with feature flags before, but never found an elegant way to scale those.  Some of the issues that I came across were:

  1. Naming conventions.  With more and more features added to the system, naming things becomes more and more difficult.  Especially, when features cross over from one part of the system into another and need to be supported in different sub-modules.  In a way, this reminds me of the old argument in the blogging community about using hierarchical categories vs. flat tags, with categories providing more order and tags providing multiple paths to the destination.
  2. Modularization issues.  Feature flags are often need in the larger applications.  The kind that provides a lot of features (duh!).  But those large applications often consist of smaller parts, or modules.  Deciding whether or not to implement the feature on the application level, and/or on the module level is difficult. Especially if those module features will need to be later grouped into application features.

In terms of implementation, I haven’t used any special tools or libraries.  It was basically a set of configuration files, with feature variables defined per environment and altered during the deployment.

These days, something more robust than that is necessary for some of the projects at work.  Gladly, there are plenty of available tools to choose from – no need to reinvent the wheel.  For a good starting point, have a look at PHP Feature Flags website.  The ones listed so far are:

So, I guess, PHP is well covered when it comes to feature flags tools.  The above cover cookie-based, IP-based, URL-based dynamic features, configuration-based features, and A/B features.

The point now is to actually utilize them in the project.  After all, the lack of feature flags is one of the 5 toxic things for the scalability, as per this page:

  1. Object Relational Mappers (ORMs)
  2. Synchronous, Serial, Coupled or Locking Processes
  3. One Copy of Your Database
  4. Having No Metrics
  5. Lack of Feature Flags

I haven’t decided which library to use yet – will need to try them all and see which one is the most appropriate, but for now I don’t think I’ll dive as deep as cookie/URL/IP based features or A/B testing.  Even the simplest configuration-based implementation will be helpful.

Amazon Linux AMI : Let’s Encrypt : ImportError: No module named interface

Let’s Encrypt has only experimental support for the Amazon Linux AMI, so it’s kind of expected to have issues once in a while.   Here’s one I came across today:

# /opt/letsencrypt/certbot-auto renew
Creating virtual environment...
Installing Python packages...
Installation succeeded.
Traceback (most recent call last):
File "/root/.local/share/letsencrypt/bin/letsencrypt", line 7, in <module>
from certbot.main import main
File "/root/.local/share/letsencrypt/local/lib/python2.7/dist-packages/certbot/main.py", line 12, in <module>
import zope.component
File "/root/.local/share/letsencrypt/local/lib/python2.7/dist-packages/zope/component/__init__.py", line 16, in <module>
from zope.interface import Interface
ImportError: No module named interface

My first though was to install the system updates. It looks like something is off in the Python-land. But even after the “yum update” was done, the issue was still there. A quick Google search later, thanks to the this GitHub issue and this comment, the solution is the following:

pip install pip --upgrade
pip install virtualenv --upgrade
virtualenv -p /usr/bin/python27 venv27

Running the renewal of the certificates works as expected after this.

P.S.: I wish we had fewer package and dependency managers in the world…

JSON API? No … HAL!

Wait, what?  That’s exactly what I said when I read this blog post.  I am still making my way through the JSON API specification.  And now it seems I might be wasting my time, as I should be learning HAL.

Whereas JSON API is almost like an “ORM over HTTP”, HAL does a lot less for you though, so it’s not really an apples-to-apples type of comparison.

HAL really is just a document format for a hypermedia API, like HTML is for hypertext. It doesn’t tell you how to express your domain model, and doesn’t really tell you how to use HAL to submit changes.

Sometime I think that I should just stop learning.  What’s the point?  By the time you learn a thing or two, it’s already obsolete and somebody somewhere has created something better, or wiser, or cheaper.

Meh…

PHP Package Development Standards

Paul M. Jones announces the availability of PHP Package Development Standards for review:

This initiative researches the PHP package ecosystem to recognize commonly adopted development practices. It rationalizes and refines those practices, then publishes them as PDS packages for reference by PHP package authors.

PDS publications are derived from and supported by common practices existing in real packages, as adopted by existing authors who have a continuing interest in the quality and consistency of their own work.

Have a look at php-pds/skeleton GitHub repository.

Personally, I welcome this initiative.  PHP ecosystem exploded in the recent years with the help of composer and Packagist.org.  There are over 120,000 packages just on the Packagist.org.  I think, it’s good to have some standards and best practices.  The PHP Framework Interop Group (PHP-FIG) is doing its best with the PHP Standards Recommendations (PSRs).  But we could have some more guidelines in order to have some consistency.

PHP Package Development Standards takes, in my opinion, the right way of looking at what’s out there, what works and what doesn’t, and than setting the guidelines based on the real world practices.  They cover things like file and directory naming conventions, versioning, changelog and licensing – which are common issues for pretty much every package.

Looking at the packages that I am involved with, only a few minor changes are necessary to comply.  Mostly, the “config” folder instead of the Unix-style “etc“, CONTRIBUTING file, and a CHANGELOG file, which I’m still to find a good way to semi-automate.