In a new post to his site Leonid Mamchenkov talks about feature flags, a handy tool you can use in your application to enable/disable features and or risky changes in your code allowing you more production-level control.

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] and more complex systems.

I’ve dealt with feature flags before, but never found an elegant way to scale those. [...] 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.

He talks about some of the challenges that he had in his own feature flag implementation including naming of the flags and where the flags should be placed. He then links to the PHP Feature Flags site and various PHP libraries that implement feature flags slightly differently and cover cookie-based, IP-based and URL-based features. He ends the post by pointing out that the lack of feature flags in any complex application is usually considered toxic when it comes to being able to scale an application correctly.

The SitePoint PHP blog has posted a tutorial showing you how to use the Toggle library from Qandidate to handle the enabling and disabling of features in your application.

A frequently used development workflow in version control systems is feature branching. The idea is that we develop new features in branches other than the master one. After a feature is tested and ready to be released, it is merged back into the master branch or a release branch for deployment. This approach helps us develop new features without disturbing the main code base.

However, developing a feature branch might take much longer than a normal release cycle. [...] One of the techniques widely used as an alternative to feature branching is feature toggling. Feature toggles (or feature flippers) act like on/off switches. [...] We can temporarily hide a partially built or risky feature (release toggles) or limit finished stable features to a certain group of users (business toggles).

They introduce the basics of the Toggle library and it's main components: the Manager, Toggles, Operators, Conditions and Context. These are all combined together to help determine if a feature should be enabled or hidden. Examples of each are included along the way as well as one showing a toggle in action. They also show how to integrate it with a framework, in this case a Laravel project as middleware. The post ends with a look at strategies, giving you even more customization around the conditions of the toggle (example: Affirmative, Majority and Unanimous), statues and creating the conditions from either YAML or array configurations.

In a new post to his site Benjamin Eberlei takes a look at the idea of "feature flags" (settings to turn on and off major features) and how they can be used with Doctrine entities to handle sync issues between new properties and the database schema.

The problem of feature flags with Doctrine is easily explained: If you add properties for a new feature that is disabled in the Doctrine metadata, then you need to upgrade the database before deployment, even when the feature is not being rolled out for some days/weeks. Doctrine requires the database to look exactly like the metadata specifies it.

His solution was to use the "loadClassMetadata" event in the entity to dynamically append these new properties based on simple "if" checks of feature flags in the configuration object. Obviously using this is a bit of a hack until the new properties are in place, but once they are then the only change is removing this code.

In the process of some development he's been doing on various shared modules for PHP, Derick Rethans stumbled across an issue with using Valgrind to test his code:

While testing whether I correctly free all memory with Valgrind, I ran into the issue where I couldn't see the stack frames of where the memory leaks occurred in the extensions, and once I even ran into a Valgrind bug. The reason why Valgrind could not show the function names belonging to the stack frames is because PHP had already unloaded the shared extensions from memory.

A work-around he found was compiling the modules, but he wanted something "more correct" and less of a hassle. As a result he added a check for the ZEND_DONT_UNLOAD_MODULES environment flag to the PHP core to handles this case specifically. He includes a snippet of example code showing the Valgrind results with and without the flag.

On Tim's blog today (Design by Tim), he has a new post that talks about "learning to extract()" - using this function to create variables based on $_GET and $_POST entries.

The days of explicitly declaring variables passed in from a form for use - or (gasp) using $_GET[’varName’] in your code is no longer needed! Clear as well as clean code is the discussion for variable setting today, and we get to explore how easy it is to extract(), Typically you would have call the variable and then set it.

The world is changing. While that is not bad for small forms or simple tasks but what if your project is larger or lets just say after reading this article you abondon gathering all the $_GET data from your simple form?

He goes on to talk about the different flags that you can pass in for various options (like "overwrite existing variable" or "prefix variable names with this" sorts of things). Of course, this kind of methodology has to be used carefully so as not to create more security issues than it's worth...

On Tim's blog today (Design by Tim), he has a new post that talks about "learning to extract()" - using this function to create variables based on $_GET and $_POST entries.

The days of explicitly declaring variables passed in from a form for use - or (gasp) using $_GET[’varName’] in your code is no longer needed! Clear as well as clean code is the discussion for variable setting today, and we get to explore how easy it is to extract(), Typically you would have call the variable and then set it.

The world is changing. While that is not bad for small forms or simple tasks but what if your project is larger or lets just say after reading this article you abondon gathering all the $_GET data from your simple form?

He goes on to talk about the different flags that you can pass in for various options (like "overwrite existing variable" or "prefix variable names with this" sorts of things). Of course, this kind of methodology has to be used carefully so as not to create more security issues than it's worth...