100 lines
No EOL
7.1 KiB
JSON
100 lines
No EOL
7.1 KiB
JSON
{
|
|
"uuid": [
|
|
{
|
|
"value": "46d61e2a-514f-48aa-8ce8-6b8d4778594b"
|
|
}
|
|
],
|
|
"langcode": [
|
|
{
|
|
"value": "en"
|
|
}
|
|
],
|
|
"type": [
|
|
{
|
|
"target_id": "daily_email",
|
|
"target_type": "node_type",
|
|
"target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
|
|
}
|
|
],
|
|
"revision_timestamp": [
|
|
{
|
|
"value": "2025-04-21T01:21:36+00:00"
|
|
}
|
|
],
|
|
"revision_uid": [
|
|
{
|
|
"target_type": "user",
|
|
"target_uuid": "b8966985-d4b2-42a7-a319-2e94ccfbb849"
|
|
}
|
|
],
|
|
"revision_log": [],
|
|
"status": [
|
|
{
|
|
"value": true
|
|
}
|
|
],
|
|
"uid": [
|
|
{
|
|
"target_type": "user",
|
|
"target_uuid": "b8966985-d4b2-42a7-a319-2e94ccfbb849"
|
|
}
|
|
],
|
|
"title": [
|
|
{
|
|
"value": "Feature flags should be short-lived"
|
|
}
|
|
],
|
|
"created": [
|
|
{
|
|
"value": "2024-03-11T00:00:00+00:00"
|
|
}
|
|
],
|
|
"changed": [
|
|
{
|
|
"value": "2025-04-21T01:21:36+00:00"
|
|
}
|
|
],
|
|
"promote": [
|
|
{
|
|
"value": false
|
|
}
|
|
],
|
|
"sticky": [
|
|
{
|
|
"value": false
|
|
}
|
|
],
|
|
"default_langcode": [
|
|
{
|
|
"value": true
|
|
}
|
|
],
|
|
"revision_translation_affected": [
|
|
{
|
|
"value": true
|
|
}
|
|
],
|
|
"path": [
|
|
{
|
|
"alias": "\/daily\/2024\/03\/11\/feature-flags-should-be-short-lived",
|
|
"langcode": "en"
|
|
}
|
|
],
|
|
"body": [
|
|
{
|
|
"value": "\n <p>Today, I <a href=\"https:\/\/twitter.com\/opdavies\/status\/1767846980250714261\">posted a tweet<\/a> with a screenshot of some code.<\/p>\n\n<p>When previously working on the <a href=\"https:\/\/www.oliverdavies.uk\/daily\/2024\/02\/19\/introducing-versa\">Versa CLI tool<\/a>, I had a TODO comment saying \"What if there are multiple languages?\".<\/p>\n\n<p>Versa is a tool for standardising commands between different languages and frameworks, but some projects, like my personal website, use multiple languages.<\/p>\n\n<p>The website is powered by Sculpin, a static site generator written in PHP (so there is a composer.json file) and node to compile the front-end assets (so there is also a package.json file).<\/p>\n\n<h2 id=\"what-problem-am-i-trying-to-solve%3F\">What Problem Am I Trying to Solve?<\/h2>\n\n<p>Depending on the language, commands like <code>versa install<\/code> will need to execute a different command - e.g., composer install<code>or<\/code>npm install` (or an equivalent node package manager).<\/p>\n\n<p>I added PHP support first, so if a composer.json file is found, the PHP command is run as the default.<\/p>\n\n<p>What I thought was for projects with multiple languages, to prompt the user to select the language when running the command if no explicit language is set.<\/p>\n\n<p>This led me to do a spike of using Symfony Console's <code>choice<\/code> method to see what that would look like so I could add a screenshot to the GitHub issue.<\/p>\n\n<p>Once I'd finished with the spike, rather than deleting the code, I wrapped it in an <code>if (false)<\/code> condition so it wouldn't be executed, but I could still re-enable it in the future.<\/p>\n\n<p>The screenshot in the tweet showed this, along with the text \"Minimum viable feature flag.\"<\/p>\n\n<p>This is only supposed to be there for a short time until I revisit the code and implement the feature I was spiking on.<\/p>\n\n<p>If it would be a long time before I looked at it again, I'd take a different approach.<\/p>\n\n<h2 id=\"here%27s-the-thing\">Here's the Thing<\/h2>\n\n<p>One of the main rules of using feature flags is that they should be short-lived.<\/p>\n\n<p>It's less than ideal to read through a codebase and see it scattered with feature flags that are no longer needed and were used to release a feature several months ago, but the flag hasn't been removed.<\/p>\n\n<p>A feature flag is a temporary solution for separating the deployment of code from the release of a change.<\/p>\n\n<p>Once it's been released, the flag should be removed.<\/p>\n\n ",
|
|
"format": "full_html",
|
|
"processed": "\n <p>Today, I <a href=\"https:\/\/twitter.com\/opdavies\/status\/1767846980250714261\">posted a tweet<\/a> with a screenshot of some code.<\/p>\n\n<p>When previously working on the <a href=\"https:\/\/www.oliverdavies.uk\/daily\/2024\/02\/19\/introducing-versa\">Versa CLI tool<\/a>, I had a TODO comment saying \"What if there are multiple languages?\".<\/p>\n\n<p>Versa is a tool for standardising commands between different languages and frameworks, but some projects, like my personal website, use multiple languages.<\/p>\n\n<p>The website is powered by Sculpin, a static site generator written in PHP (so there is a composer.json file) and node to compile the front-end assets (so there is also a package.json file).<\/p>\n\n<h2 id=\"what-problem-am-i-trying-to-solve%3F\">What Problem Am I Trying to Solve?<\/h2>\n\n<p>Depending on the language, commands like <code>versa install<\/code> will need to execute a different command - e.g., composer install<code>or<\/code>npm install` (or an equivalent node package manager).<\/p>\n\n<p>I added PHP support first, so if a composer.json file is found, the PHP command is run as the default.<\/p>\n\n<p>What I thought was for projects with multiple languages, to prompt the user to select the language when running the command if no explicit language is set.<\/p>\n\n<p>This led me to do a spike of using Symfony Console's <code>choice<\/code> method to see what that would look like so I could add a screenshot to the GitHub issue.<\/p>\n\n<p>Once I'd finished with the spike, rather than deleting the code, I wrapped it in an <code>if (false)<\/code> condition so it wouldn't be executed, but I could still re-enable it in the future.<\/p>\n\n<p>The screenshot in the tweet showed this, along with the text \"Minimum viable feature flag.\"<\/p>\n\n<p>This is only supposed to be there for a short time until I revisit the code and implement the feature I was spiking on.<\/p>\n\n<p>If it would be a long time before I looked at it again, I'd take a different approach.<\/p>\n\n<h2 id=\"here%27s-the-thing\">Here's the Thing<\/h2>\n\n<p>One of the main rules of using feature flags is that they should be short-lived.<\/p>\n\n<p>It's less than ideal to read through a codebase and see it scattered with feature flags that are no longer needed and were used to release a feature several months ago, but the flag hasn't been removed.<\/p>\n\n<p>A feature flag is a temporary solution for separating the deployment of code from the release of a change.<\/p>\n\n<p>Once it's been released, the flag should be removed.<\/p>\n\n ",
|
|
"summary": null
|
|
}
|
|
],
|
|
"feeds_item": [
|
|
{
|
|
"imported": "2025-04-21T01:21:36+00:00",
|
|
"guid": null,
|
|
"hash": "5433ca25d20eea02dd4ac8345d46c026",
|
|
"target_type": "feeds_feed",
|
|
"target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
|
|
}
|
|
]
|
|
} |