\/** @test *\/\nfunction should_activate_a_pending_user(): void {\n \/\/ Arrange.\n\n \/\/ Act.\n\n \/\/ Assert.\n}\n<\/code><\/pre>\n\nThis makes me think about the different stages and what each might need to contain.<\/p>\n\n
Option 2<\/h2>\n\n
Or I might write it out in the \"Given, When, Then\" format:<\/p>\n\n
\/** @test *\/\nfunction should_activate_a_pending_user(): void {\n \/\/ Given I have a user.\n \/\/ And the user is pending.\n\n \/\/ When I run the user update command.\n\n \/\/ Then the user should no longer be 'pending'.\n \/\/ And the user status should be 'active'.\n}\n<\/code><\/pre>\n\nThis takes a little longer to write but feels more familiar if you're used to a behavioural testing framework like Behat.<\/p>\n\n
Either way, sometimes, I'll remove the comments once I've written the code around them or leave them to provide additional context.<\/p>\n\n ",
+ "format": "full_html",
+ "processed": "\n
Test cases are usually split into two or three sections - \"Arrange, Act, Assert\" or \"Given, When, Then\".<\/p>\n\n
If the test has a prerequisite, such as some users or content to be created or in a given state, you create the required environment for the test. With unit tests, this would include mocking any dependencies you need to use.<\/p>\n\n
Then you perform an action on the subject under test and, finally, assert that the system is in the desired state.<\/p>\n\n
Maybe a user was pending initially, and they're active after running a command or a cron task. You can assert the initial state of the user as well as the final state to ensure the action did what it was supposed to do.<\/p>\n\n
Option 1<\/h2>\n\n
To help me get started, I'll sometimes write a test like this with placeholders to separate the test into its separate stages:<\/p>\n\n
\/** @test *\/\nfunction should_activate_a_pending_user(): void {\n \/\/ Arrange.\n\n \/\/ Act.\n\n \/\/ Assert.\n}\n<\/code><\/pre>\n\nThis makes me think about the different stages and what each might need to contain.<\/p>\n\n
Option 2<\/h2>\n\n
Or I might write it out in the \"Given, When, Then\" format:<\/p>\n\n
\/** @test *\/\nfunction should_activate_a_pending_user(): void {\n \/\/ Given I have a user.\n \/\/ And the user is pending.\n\n \/\/ When I run the user update command.\n\n \/\/ Then the user should no longer be 'pending'.\n \/\/ And the user status should be 'active'.\n}\n<\/code><\/pre>\n\nThis takes a little longer to write but feels more familiar if you're used to a behavioural testing framework like Behat.<\/p>\n\n
Either way, sometimes, I'll remove the comments once I've written the code around them or leave them to provide additional context.<\/p>\n\n ",
+ "summary": null
+ }
+ ],
+ "feeds_item": [
+ {
+ "imported": "2025-05-11T09:00:44+00:00",
+ "guid": null,
+ "hash": "a1a228d3231ffab8895ec0cbd78f0b1d",
+ "target_type": "feeds_feed",
+ "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
+ }
+ ]
+}
\ No newline at end of file
diff --git a/content/node.00204e36-4f2d-4b4a-bcf6-c0140209e835.json b/content/node.00204e36-4f2d-4b4a-bcf6-c0140209e835.json
deleted file mode 100644
index 71512eafd..000000000
--- a/content/node.00204e36-4f2d-4b4a-bcf6-c0140209e835.json
+++ /dev/null
@@ -1,100 +0,0 @@
-{
- "uuid": [
- {
- "value": "00204e36-4f2d-4b4a-bcf6-c0140209e835"
- }
- ],
- "langcode": [
- {
- "value": "en"
- }
- ],
- "type": [
- {
- "target_id": "daily_email",
- "target_type": "node_type",
- "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
- }
- ],
- "revision_timestamp": [
- {
- "value": "2025-05-01T23:43:31+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": "Writing good commit messages"
- }
- ],
- "created": [
- {
- "value": "2025-04-04T00:00:00+00:00"
- }
- ],
- "changed": [
- {
- "value": "2025-05-01T23:43:31+00:00"
- }
- ],
- "promote": [
- {
- "value": false
- }
- ],
- "sticky": [
- {
- "value": false
- }
- ],
- "default_langcode": [
- {
- "value": true
- }
- ],
- "revision_translation_affected": [
- {
- "value": true
- }
- ],
- "path": [
- {
- "alias": "\/daily\/2025\/04\/04\/good",
- "langcode": "en"
- }
- ],
- "body": [
- {
- "value": "\n
There are many good resources and interesting articles online about how to write good messages when committing changes to a Git repository.<\/p>\n\n
The post I often refer to is How to Write a Git Commit Message<\/a> by Chris Beams.<\/p>\n\nIn his post, he explains why good commit messages matter and gives these seven rules:<\/p>\n\n
\n \n - Separate the subject from body with a blank line.<\/li>\n
- Limit the subject line to 50 characters.<\/li>\n
- Capitalize the subject line.<\/li>\n
- Do not end the subject line with a period.<\/li>\n
- Use the imperative mood in the subject line.<\/li>\n
- Wrap the body at 72 characters.<\/li>\n
- Use the body to explain what and why vs. how.<\/li>\n <\/ul>\n<\/blockquote>\n\n
I'd recommend reading the article to get the full context.<\/p>\n\n
Rules two and six suggest lengths for the subject line and body which is another reason why I rarely use -m<\/code><\/a> when committing changes.<\/p>\n\nWhilst you can create multi-line commit messages on the command line, by opening it in my preferred editor (Neovim for me), I can see where the lines should end and be warned if I exceed them.<\/p>\n\n
I can even include Chris' rules in my commit message template so I see them whenever I'm about to commit something.<\/p>\n\n
This additional feedback helps me create my commit messages how I intend.<\/p>\n\n ",
- "format": "full_html",
- "processed": "\n
There are many good resources and interesting articles online about how to write good messages when committing changes to a Git repository.<\/p>\n\n
The post I often refer to is How to Write a Git Commit Message<\/a> by Chris Beams.<\/p>\n\nIn his post, he explains why good commit messages matter and gives these seven rules:<\/p>\n\n
\n \n - Separate the subject from body with a blank line.<\/li>\n
- Limit the subject line to 50 characters.<\/li>\n
- Capitalize the subject line.<\/li>\n
- Do not end the subject line with a period.<\/li>\n
- Use the imperative mood in the subject line.<\/li>\n
- Wrap the body at 72 characters.<\/li>\n
- Use the body to explain what and why vs. how.<\/li>\n <\/ul>\n<\/blockquote>\n\n
I'd recommend reading the article to get the full context.<\/p>\n\n
Rules two and six suggest lengths for the subject line and body which is another reason why I rarely use -m<\/code><\/a> when committing changes.<\/p>\n\nWhilst you can create multi-line commit messages on the command line, by opening it in my preferred editor (Neovim for me), I can see where the lines should end and be warned if I exceed them.<\/p>\n\n
I can even include Chris' rules in my commit message template so I see them whenever I'm about to commit something.<\/p>\n\n
This additional feedback helps me create my commit messages how I intend.<\/p>\n\n ",
- "summary": null
- }
- ],
- "feeds_item": [
- {
- "imported": "2025-05-01T23:43:31+00:00",
- "guid": null,
- "hash": "7430242f1d716198aa6fb01f727d1f9a",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.00497277-4b40-4d36-a473-8d8e1a187c18.json b/content/node.00497277-4b40-4d36-a473-8d8e1a187c18.json
new file mode 100644
index 000000000..272aa017e
--- /dev/null
+++ b/content/node.00497277-4b40-4d36-a473-8d8e1a187c18.json
@@ -0,0 +1,100 @@
+{
+ "uuid": [
+ {
+ "value": "00497277-4b40-4d36-a473-8d8e1a187c18"
+ }
+ ],
+ "langcode": [
+ {
+ "value": "en"
+ }
+ ],
+ "type": [
+ {
+ "target_id": "daily_email",
+ "target_type": "node_type",
+ "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
+ }
+ ],
+ "revision_timestamp": [
+ {
+ "value": "2025-05-11T09:00:44+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": "Consistency is key\n"
+ }
+ ],
+ "created": [
+ {
+ "value": "2023-04-18T00:00:00+00:00"
+ }
+ ],
+ "changed": [
+ {
+ "value": "2025-05-11T09:00:44+00:00"
+ }
+ ],
+ "promote": [
+ {
+ "value": false
+ }
+ ],
+ "sticky": [
+ {
+ "value": false
+ }
+ ],
+ "default_langcode": [
+ {
+ "value": true
+ }
+ ],
+ "revision_translation_affected": [
+ {
+ "value": true
+ }
+ ],
+ "path": [
+ {
+ "alias": "\/daily\/2023\/04\/18\/consistency-is-key",
+ "langcode": "en"
+ }
+ ],
+ "body": [
+ {
+ "value": "\n
A side effect of using a tool to generate build configuration files<\/a> with templates is the consistency that it introduces.<\/p>\n\nThe majority of my projects use a PHP-FPM or PHP CLI container. In my Docker Compose file, the service was mostly named php<\/code> but sometimes it was php-fpm<\/code>. In the templated file, it's always named php<\/code>.<\/p>\n\nSome projects would use mysql<\/code> or mariadb<\/code> for the database service and nginx<\/code> or caddy<\/code> depending on which server was being used. These are now always database<\/code> and web<\/code> respectively.<\/p>\n\nAs well as being easier to switch between projects and not having to think about which names are used in each codebase, it's also much easier to write tools and automation when the names are consistent.<\/p>\n\n
For example, I'd always write a long-ish command to import a database file - reading and unzipping it, and importing it by connecting to the database running in its container. The command would essentially be the same with slight changes based on that project - such as the database service name.<\/p>\n\n
Now the command is the same for all projects, and I can automate it by writing a script that works on any project meaning I no longer need to write the long command at all.<\/p>\n\n ",
+ "format": "full_html",
+ "processed": "\n
A side effect of using a tool to generate build configuration files<\/a> with templates is the consistency that it introduces.<\/p>\n\nThe majority of my projects use a PHP-FPM or PHP CLI container. In my Docker Compose file, the service was mostly named php<\/code> but sometimes it was php-fpm<\/code>. In the templated file, it's always named php<\/code>.<\/p>\n\nSome projects would use mysql<\/code> or mariadb<\/code> for the database service and nginx<\/code> or caddy<\/code> depending on which server was being used. These are now always database<\/code> and web<\/code> respectively.<\/p>\n\nAs well as being easier to switch between projects and not having to think about which names are used in each codebase, it's also much easier to write tools and automation when the names are consistent.<\/p>\n\n
For example, I'd always write a long-ish command to import a database file - reading and unzipping it, and importing it by connecting to the database running in its container. The command would essentially be the same with slight changes based on that project - such as the database service name.<\/p>\n\n
Now the command is the same for all projects, and I can automate it by writing a script that works on any project meaning I no longer need to write the long command at all.<\/p>\n\n ",
+ "summary": null
+ }
+ ],
+ "feeds_item": [
+ {
+ "imported": "2025-05-11T09:00:44+00:00",
+ "guid": null,
+ "hash": "aacb745c094cf5a9f668c64b15000f49",
+ "target_type": "feeds_feed",
+ "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
+ }
+ ]
+}
\ No newline at end of file
diff --git a/content/node.00519b3f-3eaf-4595-9620-4ff1a1fb3b6d.json b/content/node.00519b3f-3eaf-4595-9620-4ff1a1fb3b6d.json
deleted file mode 100644
index 1a21db4e0..000000000
--- a/content/node.00519b3f-3eaf-4595-9620-4ff1a1fb3b6d.json
+++ /dev/null
@@ -1,100 +0,0 @@
-{
- "uuid": [
- {
- "value": "00519b3f-3eaf-4595-9620-4ff1a1fb3b6d"
- }
- ],
- "langcode": [
- {
- "value": "en"
- }
- ],
- "type": [
- {
- "target_id": "daily_email",
- "target_type": "node_type",
- "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
- }
- ],
- "revision_timestamp": [
- {
- "value": "2025-05-11T06:09:49+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": "Building different-looking UIs with consistent class names"
- }
- ],
- "created": [
- {
- "value": "2024-11-22T00:00:00+00:00"
- }
- ],
- "changed": [
- {
- "value": "2025-05-11T06:09:49+00:00"
- }
- ],
- "promote": [
- {
- "value": false
- }
- ],
- "sticky": [
- {
- "value": false
- }
- ],
- "default_langcode": [
- {
- "value": true
- }
- ],
- "revision_translation_affected": [
- {
- "value": true
- }
- ],
- "path": [
- {
- "alias": "\/daily\/2024\/11\/22\/building-different-looking-uis-with-consistent-class-names",
- "langcode": "en"
- }
- ],
- "body": [
- {
- "value": "\n
Something I've said when speaking about Tailwind CSS<\/a> and also during my recent consulting engagement<\/a>, is that you can build dramatically different-looking UIs even though you're using the same class names.<\/p>\n\nFor example, I've rebuilt the Bartik theme<\/a>, the Acquia hosting dashboard<\/a> and various other UIs<\/a> for talk demos - none of which look the same or are even similar.<\/p>\n\nThis website is themed with Tailwind CSS.<\/p>\n\n
As the classes are very low-level, there is no \"Tailwind-looking website\" like there is with other CSS frameworks.<\/p>\n\n
And, when you move to other application, the same classes are there and available to use.<\/p>\n\n
You just need to customise them, use what you need and ignore what you don't.<\/p>\n\n ",
- "format": "full_html",
- "processed": "\n
Something I've said when speaking about Tailwind CSS<\/a> and also during my recent consulting engagement<\/a>, is that you can build dramatically different-looking UIs even though you're using the same class names.<\/p>\n\nFor example, I've rebuilt the Bartik theme<\/a>, the Acquia hosting dashboard<\/a> and various other UIs<\/a> for talk demos - none of which look the same or are even similar.<\/p>\n\nThis website is themed with Tailwind CSS.<\/p>\n\n
As the classes are very low-level, there is no \"Tailwind-looking website\" like there is with other CSS frameworks.<\/p>\n\n
And, when you move to other application, the same classes are there and available to use.<\/p>\n\n
You just need to customise them, use what you need and ignore what you don't.<\/p>\n\n ",
- "summary": null
- }
- ],
- "feeds_item": [
- {
- "imported": "2025-05-11T06:09:49+00:00",
- "guid": null,
- "hash": "5b4b4815f291bc6b2a7f37552c3d1102",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.0086c29b-9324-4d72-bdc0-c2a75c2aaca5.json b/content/node.0086c29b-9324-4d72-bdc0-c2a75c2aaca5.json
deleted file mode 100644
index a45d6fb23..000000000
--- a/content/node.0086c29b-9324-4d72-bdc0-c2a75c2aaca5.json
+++ /dev/null
@@ -1,100 +0,0 @@
-{
- "uuid": [
- {
- "value": "0086c29b-9324-4d72-bdc0-c2a75c2aaca5"
- }
- ],
- "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:17+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": "Building fonts with Nix"
- }
- ],
- "created": [
- {
- "value": "2025-04-16T00:00:00+00:00"
- }
- ],
- "changed": [
- {
- "value": "2025-04-21T01:21:17+00:00"
- }
- ],
- "promote": [
- {
- "value": false
- }
- ],
- "sticky": [
- {
- "value": false
- }
- ],
- "default_langcode": [
- {
- "value": true
- }
- ],
- "revision_translation_affected": [
- {
- "value": true
- }
- ],
- "path": [
- {
- "alias": "\/daily\/2025\/04\/16\/fonts",
- "langcode": "en"
- }
- ],
- "body": [
- {
- "value": "\n
I recently started using Nix to build my PDF presentation slides<\/a> that I create with rst2pdf<\/a>.<\/p>\n\nI removed the custom build script that was generating the PDF files and moved that code into a Nix derivation.<\/p>\n\n
Now I can run nix build .#test-driven-drupal<\/code> and it will generate the slides for that talk.<\/p>\n\nAs well as the files specific to each presentation, I also have a derivation for shared assets that apply to all talks - i.e. the stylesheets and fonts that are embedded within the PDF.<\/p>\n\n
The font files were stored in the repository but I wanted to remove them and use the font files available in nixpkgs.<\/p>\n\n
After some small changes, I was able to do it<\/a> and remove the font files from my repository.<\/p>\n\nThe Inter font is available in nixpkgs, but it downloads an InterVariable.ttf<\/code> font that rst2pdf didn't know how to change the font weight for, so I made my own derivation of the static Inter font based on the releases from GitHub.<\/p>\n\nI'm happy that I was able to achieve this, as my repository is leaner and I'm continuing to find new and interesting uses for Nix in my workflows.<\/p>\n\n ",
- "format": "full_html",
- "processed": "\n
I recently started using Nix to build my PDF presentation slides<\/a> that I create with rst2pdf<\/a>.<\/p>\n\nI removed the custom build script that was generating the PDF files and moved that code into a Nix derivation.<\/p>\n\n
Now I can run nix build .#test-driven-drupal<\/code> and it will generate the slides for that talk.<\/p>\n\nAs well as the files specific to each presentation, I also have a derivation for shared assets that apply to all talks - i.e. the stylesheets and fonts that are embedded within the PDF.<\/p>\n\n
The font files were stored in the repository but I wanted to remove them and use the font files available in nixpkgs.<\/p>\n\n
After some small changes, I was able to do it<\/a> and remove the font files from my repository.<\/p>\n\nThe Inter font is available in nixpkgs, but it downloads an InterVariable.ttf<\/code> font that rst2pdf didn't know how to change the font weight for, so I made my own derivation of the static Inter font based on the releases from GitHub.<\/p>\n\nI'm happy that I was able to achieve this, as my repository is leaner and I'm continuing to find new and interesting uses for Nix in my workflows.<\/p>\n\n ",
- "summary": null
- }
- ],
- "feeds_item": [
- {
- "imported": "2025-04-21T01:21:17+00:00",
- "guid": null,
- "hash": "663165d347672170986b3ba5d0f0ac13",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.008a122d-b219-46fa-8774-999d1e56e18b.json b/content/node.008a122d-b219-46fa-8774-999d1e56e18b.json
deleted file mode 100644
index 9a7b08d9e..000000000
--- a/content/node.008a122d-b219-46fa-8774-999d1e56e18b.json
+++ /dev/null
@@ -1,100 +0,0 @@
-{
- "uuid": [
- {
- "value": "008a122d-b219-46fa-8774-999d1e56e18b"
- }
- ],
- "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:56+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": "Consistency is key\n"
- }
- ],
- "created": [
- {
- "value": "2023-04-18T00:00:00+00:00"
- }
- ],
- "changed": [
- {
- "value": "2025-04-21T01:21:56+00:00"
- }
- ],
- "promote": [
- {
- "value": false
- }
- ],
- "sticky": [
- {
- "value": false
- }
- ],
- "default_langcode": [
- {
- "value": true
- }
- ],
- "revision_translation_affected": [
- {
- "value": true
- }
- ],
- "path": [
- {
- "alias": "\/daily\/2023\/04\/18\/consistency-is-key",
- "langcode": "en"
- }
- ],
- "body": [
- {
- "value": "\n
A side effect of using a tool to generate build configuration files<\/a> with templates is the consistency that it introduces.<\/p>\n\nThe majority of my projects use a PHP-FPM or PHP CLI container. In my Docker Compose file, the service was mostly named php<\/code> but sometimes it was php-fpm<\/code>. In the templated file, it's always named php<\/code>.<\/p>\n\nSome projects would use mysql<\/code> or mariadb<\/code> for the database service and nginx<\/code> or caddy<\/code> depending on which server was being used. These are now always database<\/code> and web<\/code> respectively.<\/p>\n\nAs well as being easier to switch between projects and not having to think about which names are used in each codebase, it's also much easier to write tools and automation when the names are consistent.<\/p>\n\n
For example, I'd always write a long-ish command to import a database file - reading and unzipping it, and importing it by connecting to the database running in its container. The command would essentially be the same with slight changes based on that project - such as the database service name.<\/p>\n\n
Now the command is the same for all projects, and I can automate it by writing a script that works on any project meaning I no longer need to write the long command at all.<\/p>\n\n ",
- "format": "full_html",
- "processed": "\n
A side effect of using a tool to generate build configuration files<\/a> with templates is the consistency that it introduces.<\/p>\n\nThe majority of my projects use a PHP-FPM or PHP CLI container. In my Docker Compose file, the service was mostly named php<\/code> but sometimes it was php-fpm<\/code>. In the templated file, it's always named php<\/code>.<\/p>\n\nSome projects would use mysql<\/code> or mariadb<\/code> for the database service and nginx<\/code> or caddy<\/code> depending on which server was being used. These are now always database<\/code> and web<\/code> respectively.<\/p>\n\nAs well as being easier to switch between projects and not having to think about which names are used in each codebase, it's also much easier to write tools and automation when the names are consistent.<\/p>\n\n
For example, I'd always write a long-ish command to import a database file - reading and unzipping it, and importing it by connecting to the database running in its container. The command would essentially be the same with slight changes based on that project - such as the database service name.<\/p>\n\n
Now the command is the same for all projects, and I can automate it by writing a script that works on any project meaning I no longer need to write the long command at all.<\/p>\n\n ",
- "summary": null
- }
- ],
- "feeds_item": [
- {
- "imported": "2025-04-21T01:21:56+00:00",
- "guid": null,
- "hash": "aacb745c094cf5a9f668c64b15000f49",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.00d62e94-80d1-4792-bdea-88a064f6bf65.json b/content/node.00d62e94-80d1-4792-bdea-88a064f6bf65.json
new file mode 100644
index 000000000..377ab8a41
--- /dev/null
+++ b/content/node.00d62e94-80d1-4792-bdea-88a064f6bf65.json
@@ -0,0 +1,100 @@
+{
+ "uuid": [
+ {
+ "value": "00d62e94-80d1-4792-bdea-88a064f6bf65"
+ }
+ ],
+ "langcode": [
+ {
+ "value": "en"
+ }
+ ],
+ "type": [
+ {
+ "target_id": "daily_email",
+ "target_type": "node_type",
+ "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
+ }
+ ],
+ "revision_timestamp": [
+ {
+ "value": "2025-05-11T09:00:18+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": "80% of PHP?"
+ }
+ ],
+ "created": [
+ {
+ "value": "2024-03-13T00:00:00+00:00"
+ }
+ ],
+ "changed": [
+ {
+ "value": "2025-05-11T09:00:18+00:00"
+ }
+ ],
+ "promote": [
+ {
+ "value": false
+ }
+ ],
+ "sticky": [
+ {
+ "value": false
+ }
+ ],
+ "default_langcode": [
+ {
+ "value": true
+ }
+ ],
+ "revision_translation_affected": [
+ {
+ "value": true
+ }
+ ],
+ "path": [
+ {
+ "alias": "\/daily\/2024\/03\/13\/80--of-php",
+ "langcode": "en"
+ }
+ ],
+ "body": [
+ {
+ "value": "\n
Something I see on many Developers' websites and CVs is percentages or levels of how well they know certain tools and frameworks.<\/p>\n\n
Things like \"80% of PHP\" or \"Advanced in HTML and CSS\".<\/p>\n\n
But how do you quantify that?<\/p>\n\n
Do people alter their percentages accordingly if a new feature is added to a language or framework?<\/p>\n\n
Or, instead of trying to show how much you understand, focus on what problems you can solve with those tools and how you can provide value to customers or employers instead of what tools you'd use to do it.<\/p>\n\n ",
+ "format": "full_html",
+ "processed": "\n
Something I see on many Developers' websites and CVs is percentages or levels of how well they know certain tools and frameworks.<\/p>\n\n
Things like \"80% of PHP\" or \"Advanced in HTML and CSS\".<\/p>\n\n
But how do you quantify that?<\/p>\n\n
Do people alter their percentages accordingly if a new feature is added to a language or framework?<\/p>\n\n
Or, instead of trying to show how much you understand, focus on what problems you can solve with those tools and how you can provide value to customers or employers instead of what tools you'd use to do it.<\/p>\n\n ",
+ "summary": null
+ }
+ ],
+ "feeds_item": [
+ {
+ "imported": "2025-05-11T09:00:18+00:00",
+ "guid": null,
+ "hash": "3bf8b7e44f82bf7d6ad5ce1fda692ae6",
+ "target_type": "feeds_feed",
+ "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
+ }
+ ]
+}
\ No newline at end of file
diff --git a/content/node.00e8b0fc-a551-47e4-b0df-b568beada250.json b/content/node.00e8b0fc-a551-47e4-b0df-b568beada250.json
deleted file mode 100644
index 845f8ee50..000000000
--- a/content/node.00e8b0fc-a551-47e4-b0df-b568beada250.json
+++ /dev/null
@@ -1,100 +0,0 @@
-{
- "uuid": [
- {
- "value": "00e8b0fc-a551-47e4-b0df-b568beada250"
- }
- ],
- "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:17+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": "Legacy code is anything older than..."
- }
- ],
- "created": [
- {
- "value": "2025-03-22T00:00:00+00:00"
- }
- ],
- "changed": [
- {
- "value": "2025-04-21T01:21:17+00:00"
- }
- ],
- "promote": [
- {
- "value": false
- }
- ],
- "sticky": [
- {
- "value": false
- }
- ],
- "default_langcode": [
- {
- "value": true
- }
- ],
- "revision_translation_affected": [
- {
- "value": true
- }
- ],
- "path": [
- {
- "alias": "\/daily\/2025\/03\/22\/legacy",
- "langcode": "en"
- }
- ],
- "body": [
- {
- "value": "\n
How do you define legacy code?<\/p>\n\n
Code that was written by someone else?<\/p>\n\n
Code that doesn't have tests?<\/p>\n\n
Any code that has been released to production?<\/p>\n\n
Code that's more than a day old?<\/p>\n\n
In a talk I recently watched, the speaker suggested that any code written more than thirty minutes ago is legacy code.<\/p>\n\n
Once you've written some code and left it for half an hour, you need to re-read it to remember and re-learn what the code does and decide how you want to implement your next requirement.<\/p>\n\n
This is the same approach for code that was written longer ago or written by someone else.<\/p>\n\n
What do you think?<\/p>\n\n ",
- "format": "full_html",
- "processed": "\n
How do you define legacy code?<\/p>\n\n
Code that was written by someone else?<\/p>\n\n
Code that doesn't have tests?<\/p>\n\n
Any code that has been released to production?<\/p>\n\n
Code that's more than a day old?<\/p>\n\n
In a talk I recently watched, the speaker suggested that any code written more than thirty minutes ago is legacy code.<\/p>\n\n
Once you've written some code and left it for half an hour, you need to re-read it to remember and re-learn what the code does and decide how you want to implement your next requirement.<\/p>\n\n
This is the same approach for code that was written longer ago or written by someone else.<\/p>\n\n
What do you think?<\/p>\n\n ",
- "summary": null
- }
- ],
- "feeds_item": [
- {
- "imported": "2025-04-21T01:21:17+00:00",
- "guid": null,
- "hash": "9983c859dafd94ec45282b7438b9cb59",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.0100be71-79ef-44ea-922e-e75fcc26ae16.json b/content/node.0100be71-79ef-44ea-922e-e75fcc26ae16.json
new file mode 100644
index 000000000..776387f74
--- /dev/null
+++ b/content/node.0100be71-79ef-44ea-922e-e75fcc26ae16.json
@@ -0,0 +1,100 @@
+{
+ "uuid": [
+ {
+ "value": "0100be71-79ef-44ea-922e-e75fcc26ae16"
+ }
+ ],
+ "langcode": [
+ {
+ "value": "en"
+ }
+ ],
+ "type": [
+ {
+ "target_id": "daily_email",
+ "target_type": "node_type",
+ "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
+ }
+ ],
+ "revision_timestamp": [
+ {
+ "value": "2025-05-11T09:00:03+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": "How quickly can you create or update an environment?"
+ }
+ ],
+ "created": [
+ {
+ "value": "2024-12-27T00:00:00+00:00"
+ }
+ ],
+ "changed": [
+ {
+ "value": "2025-05-11T09:00:03+00:00"
+ }
+ ],
+ "promote": [
+ {
+ "value": false
+ }
+ ],
+ "sticky": [
+ {
+ "value": false
+ }
+ ],
+ "default_langcode": [
+ {
+ "value": true
+ }
+ ],
+ "revision_translation_affected": [
+ {
+ "value": true
+ }
+ ],
+ "path": [
+ {
+ "alias": "\/daily\/2024\/12\/27\/quick",
+ "langcode": "en"
+ }
+ ],
+ "body": [
+ {
+ "value": "\n
A common reason why environments aren't updated and get out of sync is because it's a time-consuming or complex task.<\/p>\n\n
The process should be simple to run, quick, reliable and reproducible.<\/p>\n\n
It's the same as deploying a change to a staging or production environment.<\/p>\n\n
You want the same result on every time on every environment.<\/p>\n\n
You want every environment - including local development environments<\/a> to be as consistent as possible to minimise bugs and errors.<\/p>\n\nTo do this, I automate things to make them as simple as possible.<\/p>\n\n
I use run files<\/a> with commands to import databases, perform updates and run pre-update and post-update tasks.<\/p>\n\nI use tools like Nix and devenv<\/a> to create identical and reproducible environments.<\/p>\n\nThe simpler and quicker is it, the more it can and will be done.<\/p>\n\n
You can also use automation to perform long or complex tasks outside of working hours such as sanitising and importing large databases.<\/p>\n\n
The more you can automate, the better.<\/p>\n\n ",
+ "format": "full_html",
+ "processed": "\n
A common reason why environments aren't updated and get out of sync is because it's a time-consuming or complex task.<\/p>\n\n
The process should be simple to run, quick, reliable and reproducible.<\/p>\n\n
It's the same as deploying a change to a staging or production environment.<\/p>\n\n
You want the same result on every time on every environment.<\/p>\n\n
You want every environment - including local development environments<\/a> to be as consistent as possible to minimise bugs and errors.<\/p>\n\nTo do this, I automate things to make them as simple as possible.<\/p>\n\n
I use run files<\/a> with commands to import databases, perform updates and run pre-update and post-update tasks.<\/p>\n\nI use tools like Nix and devenv<\/a> to create identical and reproducible environments.<\/p>\n\nThe simpler and quicker is it, the more it can and will be done.<\/p>\n\n
You can also use automation to perform long or complex tasks outside of working hours such as sanitising and importing large databases.<\/p>\n\n
The more you can automate, the better.<\/p>\n\n ",
+ "summary": null
+ }
+ ],
+ "feeds_item": [
+ {
+ "imported": "2025-05-11T09:00:03+00:00",
+ "guid": null,
+ "hash": "957251b7baf05530d91b2a9731016317",
+ "target_type": "feeds_feed",
+ "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
+ }
+ ]
+}
\ No newline at end of file
diff --git a/content/node.01090310-9114-436a-93d8-55c966a816ea.json b/content/node.01090310-9114-436a-93d8-55c966a816ea.json
deleted file mode 100644
index 305bd0946..000000000
--- a/content/node.01090310-9114-436a-93d8-55c966a816ea.json
+++ /dev/null
@@ -1,100 +0,0 @@
-{
- "uuid": [
- {
- "value": "01090310-9114-436a-93d8-55c966a816ea"
- }
- ],
- "langcode": [
- {
- "value": "en"
- }
- ],
- "type": [
- {
- "target_id": "daily_email",
- "target_type": "node_type",
- "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
- }
- ],
- "revision_timestamp": [
- {
- "value": "2025-05-11T06:09:49+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": "How long should a feature flag live?\n"
- }
- ],
- "created": [
- {
- "value": "2023-06-05T00:00:00+00:00"
- }
- ],
- "changed": [
- {
- "value": "2025-05-11T06:09:49+00:00"
- }
- ],
- "promote": [
- {
- "value": false
- }
- ],
- "sticky": [
- {
- "value": false
- }
- ],
- "default_langcode": [
- {
- "value": true
- }
- ],
- "revision_translation_affected": [
- {
- "value": true
- }
- ],
- "path": [
- {
- "alias": "\/daily\/2023\/06\/05\/how-long-should-a-feature-flag-live",
- "langcode": "en"
- }
- ],
- "body": [
- {
- "value": "\n
Instead of creating a branch that lives for as long as the code takes to write, if it's behind a feature flag, the code can be merged into the mainline branch without affecting the rest of the codebase.<\/p>\n\n
Being able to release changes incrementally lowers the risk compared to releasing a large change all at once.<\/p>\n\n
But the same issue can occur with feature flags, and the longer that code is behind a feature flag, the more risk there will be when enabling the feature.<\/p>\n\n
So, like feature branches, feature flags should be short-lived and only used for as long as is needed to create the first releasable version of the feature. The feature flag can be removed once the feature is live, and the feature can continue to be iterated on and improved.<\/p>\n\n ",
- "format": "full_html",
- "processed": "\n
Instead of creating a branch that lives for as long as the code takes to write, if it's behind a feature flag, the code can be merged into the mainline branch without affecting the rest of the codebase.<\/p>\n\n
Being able to release changes incrementally lowers the risk compared to releasing a large change all at once.<\/p>\n\n
But the same issue can occur with feature flags, and the longer that code is behind a feature flag, the more risk there will be when enabling the feature.<\/p>\n\n
So, like feature branches, feature flags should be short-lived and only used for as long as is needed to create the first releasable version of the feature. The feature flag can be removed once the feature is live, and the feature can continue to be iterated on and improved.<\/p>\n\n ",
- "summary": null
- }
- ],
- "feeds_item": [
- {
- "imported": "2025-05-11T06:09:49+00:00",
- "guid": null,
- "hash": "d7e1f6d61d5541ac83cd2bfe9bc3e669",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.01230324-62b5-442b-80e4-09268a31819b.json b/content/node.01230324-62b5-442b-80e4-09268a31819b.json
new file mode 100644
index 000000000..c7288424c
--- /dev/null
+++ b/content/node.01230324-62b5-442b-80e4-09268a31819b.json
@@ -0,0 +1,100 @@
+{
+ "uuid": [
+ {
+ "value": "01230324-62b5-442b-80e4-09268a31819b"
+ }
+ ],
+ "langcode": [
+ {
+ "value": "en"
+ }
+ ],
+ "type": [
+ {
+ "target_id": "daily_email",
+ "target_type": "node_type",
+ "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
+ }
+ ],
+ "revision_timestamp": [
+ {
+ "value": "2025-05-11T09:00:05+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": "Drupal 11 is not Drupal 6"
+ }
+ ],
+ "created": [
+ {
+ "value": "2024-11-06T00:00:00+00:00"
+ }
+ ],
+ "changed": [
+ {
+ "value": "2025-05-11T09:00:05+00:00"
+ }
+ ],
+ "promote": [
+ {
+ "value": false
+ }
+ ],
+ "sticky": [
+ {
+ "value": false
+ }
+ ],
+ "default_langcode": [
+ {
+ "value": true
+ }
+ ],
+ "revision_translation_affected": [
+ {
+ "value": true
+ }
+ ],
+ "path": [
+ {
+ "alias": "\/daily\/2024\/11\/06\/drupal-11-is-not-drupal-6",
+ "langcode": "en"
+ }
+ ],
+ "body": [
+ {
+ "value": "\n
I started learning software and web development with HTML and CSS in 2007. Then I started with PHP and soon after started to learn Drupal 6 (or maybe 5).<\/p>\n\n
A lot of Developers' first programming language was PHP and maybe used earlier versions of Drupal before moving to another CMS, framework or language.<\/p>\n\n
They still remember, though, how things were when they used it and aren't aware of the advancements and improvements that have been made.<\/p>\n\n
The PHP language itself has improved significantly in recent versions with new features and much better peformance.<\/p>\n\n
Drupal is more powerful with a lot more available in core compared to when I started to use it and, since adopting modern PHP approaches and third-party code in Drupal 8, writing custom Drupal modules is different with fewer Drupalisms and more industry-standard approaches.<\/p>\n\n
If there's a tool you haven't tried for a while, maybe take another look and see if it's improved since you last used it.<\/p>\n\n ",
+ "format": "full_html",
+ "processed": "\n
I started learning software and web development with HTML and CSS in 2007. Then I started with PHP and soon after started to learn Drupal 6 (or maybe 5).<\/p>\n\n
A lot of Developers' first programming language was PHP and maybe used earlier versions of Drupal before moving to another CMS, framework or language.<\/p>\n\n
They still remember, though, how things were when they used it and aren't aware of the advancements and improvements that have been made.<\/p>\n\n
The PHP language itself has improved significantly in recent versions with new features and much better peformance.<\/p>\n\n
Drupal is more powerful with a lot more available in core compared to when I started to use it and, since adopting modern PHP approaches and third-party code in Drupal 8, writing custom Drupal modules is different with fewer Drupalisms and more industry-standard approaches.<\/p>\n\n
If there's a tool you haven't tried for a while, maybe take another look and see if it's improved since you last used it.<\/p>\n\n ",
+ "summary": null
+ }
+ ],
+ "feeds_item": [
+ {
+ "imported": "2025-05-11T09:00:05+00:00",
+ "guid": null,
+ "hash": "3baa147faae6a26ac886bb26940c8f43",
+ "target_type": "feeds_feed",
+ "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
+ }
+ ]
+}
\ No newline at end of file
diff --git a/content/node.012bd3a8-e679-4f0c-acf3-cef4523591f7.json b/content/node.012bd3a8-e679-4f0c-acf3-cef4523591f7.json
deleted file mode 100644
index 08b40cd2b..000000000
--- a/content/node.012bd3a8-e679-4f0c-acf3-cef4523591f7.json
+++ /dev/null
@@ -1,100 +0,0 @@
-{
- "uuid": [
- {
- "value": "012bd3a8-e679-4f0c-acf3-cef4523591f7"
- }
- ],
- "langcode": [
- {
- "value": "en"
- }
- ],
- "type": [
- {
- "target_id": "daily_email",
- "target_type": "node_type",
- "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
- }
- ],
- "revision_timestamp": [
- {
- "value": "2025-05-11T06:09:49+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": "Open source software all the way down"
- }
- ],
- "created": [
- {
- "value": "2024-12-07T00:00:00+00:00"
- }
- ],
- "changed": [
- {
- "value": "2025-05-11T06:09:49+00:00"
- }
- ],
- "promote": [
- {
- "value": false
- }
- ],
- "sticky": [
- {
- "value": false
- }
- ],
- "default_langcode": [
- {
- "value": true
- }
- ],
- "revision_translation_affected": [
- {
- "value": true
- }
- ],
- "path": [
- {
- "alias": "\/daily\/2024\/12\/07\/open-source",
- "langcode": "en"
- }
- ],
- "body": [
- {
- "value": "\n
As someone who develops with open-source software such as Drupal, Symfony, and Sculpin and uses Linux to host my applications<\/a> and configure my laptop<\/a>, I've recently started to explore creating a home lab and self-hosting services based on other open source software.<\/p>\n\nI've started using Jellyfin for media management and playback, Immich for photos, Gitea for hosting my private Git repositories, and Tube Archivist for backing up YouTube videos.<\/p>\n\n
There are a lot of other popular applications that people self-host that I want to look at, as well as maybe hosting my own website.<\/p>\n\n
I've removed proprietary note-taking applications in favour of plain text files<\/a> and continued searching for free and open source alternatives to services I've used.<\/p>\n\nMy ethos is to be open source first and to favour an open source solution if there is one.<\/p>\n\n
And if there isn't, I can write one.<\/p>\n\n
As well as creating free and open source software, I want to use it as much as I can as well as using open source software to create my open source software.<\/p>\n\n ",
- "format": "full_html",
- "processed": "\n
As someone who develops with open-source software such as Drupal, Symfony, and Sculpin and uses Linux to host my applications<\/a> and configure my laptop<\/a>, I've recently started to explore creating a home lab and self-hosting services based on other open source software.<\/p>\n\nI've started using Jellyfin for media management and playback, Immich for photos, Gitea for hosting my private Git repositories, and Tube Archivist for backing up YouTube videos.<\/p>\n\n
There are a lot of other popular applications that people self-host that I want to look at, as well as maybe hosting my own website.<\/p>\n\n
I've removed proprietary note-taking applications in favour of plain text files<\/a> and continued searching for free and open source alternatives to services I've used.<\/p>\n\nMy ethos is to be open source first and to favour an open source solution if there is one.<\/p>\n\n
And if there isn't, I can write one.<\/p>\n\n
As well as creating free and open source software, I want to use it as much as I can as well as using open source software to create my open source software.<\/p>\n\n ",
- "summary": null
- }
- ],
- "feeds_item": [
- {
- "imported": "2025-05-11T06:09:49+00:00",
- "guid": null,
- "hash": "826ea7f42a178becea87291123dedc78",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.015fc769-e2c2-49c2-9eb6-95bfc3bfe06e.json b/content/node.015fc769-e2c2-49c2-9eb6-95bfc3bfe06e.json
deleted file mode 100644
index d20543412..000000000
--- a/content/node.015fc769-e2c2-49c2-9eb6-95bfc3bfe06e.json
+++ /dev/null
@@ -1,100 +0,0 @@
-{
- "uuid": [
- {
- "value": "015fc769-e2c2-49c2-9eb6-95bfc3bfe06e"
- }
- ],
- "langcode": [
- {
- "value": "en"
- }
- ],
- "type": [
- {
- "target_id": "daily_email",
- "target_type": "node_type",
- "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
- }
- ],
- "revision_timestamp": [
- {
- "value": "2025-05-11T06:09:49+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": "Running tests in parallel with Paratest"
- }
- ],
- "created": [
- {
- "value": "2024-02-07T00:00:00+00:00"
- }
- ],
- "changed": [
- {
- "value": "2025-05-11T06:09:49+00:00"
- }
- ],
- "promote": [
- {
- "value": false
- }
- ],
- "sticky": [
- {
- "value": false
- }
- ],
- "default_langcode": [
- {
- "value": true
- }
- ],
- "revision_translation_affected": [
- {
- "value": true
- }
- ],
- "path": [
- {
- "alias": "\/daily\/2024\/02\/07\/running-tests-in-parallel-with-paratest",
- "langcode": "en"
- }
- ],
- "body": [
- {
- "value": "\n
Something that I've recently added to my PHP projects is Paratest<\/a>.<\/p>\n\nIt adds parallel testing to PHPUnit, so your tests will be run in parallel instead of sequentially.<\/p>\n\n
For the example module in my automated testing in Drupal email course<\/a>, using Paratest reduces the execution time from ~16 seconds to ~8 seconds.<\/p>\n\nIn a client project with 136 tests, it reduces the time from four and a half minutes to less than two minutes.<\/p>\n\n
This is a big improvement just from running a single Composer command to add Paratest.<\/p>\n\n
There's also an open issue<\/a> for using it for Drupal core's tests, which is something I'll keep an eye on and will look to contribute to.<\/p>\n\n ",
- "format": "full_html",
- "processed": "\n Something that I've recently added to my PHP projects is Paratest<\/a>.<\/p>\n\nIt adds parallel testing to PHPUnit, so your tests will be run in parallel instead of sequentially.<\/p>\n\n
For the example module in my automated testing in Drupal email course<\/a>, using Paratest reduces the execution time from ~16 seconds to ~8 seconds.<\/p>\n\nIn a client project with 136 tests, it reduces the time from four and a half minutes to less than two minutes.<\/p>\n\n
This is a big improvement just from running a single Composer command to add Paratest.<\/p>\n\n
There's also an open issue<\/a> for using it for Drupal core's tests, which is something I'll keep an eye on and will look to contribute to.<\/p>\n\n ",
- "summary": null
- }
- ],
- "feeds_item": [
- {
- "imported": "2025-05-11T06:09:49+00:00",
- "guid": null,
- "hash": "d6723cf0326f529b61786870511d23ff",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.01893784-8f45-4466-8586-17df23e7e4b5.json b/content/node.01893784-8f45-4466-8586-17df23e7e4b5.json
new file mode 100644
index 000000000..67c45f252
--- /dev/null
+++ b/content/node.01893784-8f45-4466-8586-17df23e7e4b5.json
@@ -0,0 +1,100 @@
+{
+ "uuid": [
+ {
+ "value": "01893784-8f45-4466-8586-17df23e7e4b5"
+ }
+ ],
+ "langcode": [
+ {
+ "value": "en"
+ }
+ ],
+ "type": [
+ {
+ "target_id": "daily_email",
+ "target_type": "node_type",
+ "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
+ }
+ ],
+ "revision_timestamp": [
+ {
+ "value": "2025-05-11T09:00:00+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": "What's the correct way to add PHPStan to an existing codebase?"
+ }
+ ],
+ "created": [
+ {
+ "value": "2025-03-16T00:00:00+00:00"
+ }
+ ],
+ "changed": [
+ {
+ "value": "2025-05-11T09:00:00+00:00"
+ }
+ ],
+ "promote": [
+ {
+ "value": false
+ }
+ ],
+ "sticky": [
+ {
+ "value": false
+ }
+ ],
+ "default_langcode": [
+ {
+ "value": true
+ }
+ ],
+ "revision_translation_affected": [
+ {
+ "value": true
+ }
+ ],
+ "path": [
+ {
+ "alias": "\/daily\/2025\/03\/16\/what-s-the-correct-way-to-add-phpstan-to-an-existing-codebase",
+ "langcode": "en"
+ }
+ ],
+ "body": [
+ {
+ "value": "\n PHPStan is a static analysis tool for PHP.<\/p>\n\n
It finds potential issues in PHP code without needing to run it, so Developers can find and resolve potential issues sooner.<\/p>\n\n
I use it on all my projects including existing ones I've inherited.<\/p>\n\n
But how can you add a static analysis tool to a codebase without getting a lot of errors from the existing code?<\/p>\n\n
PHPStan has different levels of strictness.<\/p>\n\n
Level 0 is the least strict and each level adds more rules and strictness, resulting in more errors.<\/p>\n\n
Most of the time, people will start by running PHPStan on level 0, fixing any errors and committing the changes.<\/p>\n\n
Then repeat the process as many times as needed until you reach the level you want to achieve.<\/p>\n\n
I don't think this is the right approach.<\/p>\n\n
This could mean that you need to edit the same files multiple times as you work through the levels.<\/p>\n\n
There's also a period of time where Developers can still write suboptimal code whilst you work your way up to your desired level.<\/p>\n\n
Another approach is to use a feature of PHPStan called the baseline.<\/p>\n\n
The baseline is a way of capturing and saving all the existing errors up to the selected level so they are no longer reported.<\/p>\n\n
If you did this for an existing project, it would return no errors as everything would be included in the baseline.<\/p>\n\n
Once you decide what level you want your project to run, you can start as soon as the baseline is generated and without needing to change files multiple times.<\/p>\n\n
Instead of spending time working through the levels one at a time, commit some time to pruning the baseline and reducing the errors in it.<\/p>\n\n
This I think is a better approach and how I add PHPStan to existing codebases.<\/p>\n\n
To learn more about static analysis and PHPStan, listen to episode 22 of the Beyond Blocks podcast<\/a> with Dave Liddament.<\/p>\n\n ",
+ "format": "full_html",
+ "processed": "\n PHPStan is a static analysis tool for PHP.<\/p>\n\n
It finds potential issues in PHP code without needing to run it, so Developers can find and resolve potential issues sooner.<\/p>\n\n
I use it on all my projects including existing ones I've inherited.<\/p>\n\n
But how can you add a static analysis tool to a codebase without getting a lot of errors from the existing code?<\/p>\n\n
PHPStan has different levels of strictness.<\/p>\n\n
Level 0 is the least strict and each level adds more rules and strictness, resulting in more errors.<\/p>\n\n
Most of the time, people will start by running PHPStan on level 0, fixing any errors and committing the changes.<\/p>\n\n
Then repeat the process as many times as needed until you reach the level you want to achieve.<\/p>\n\n
I don't think this is the right approach.<\/p>\n\n
This could mean that you need to edit the same files multiple times as you work through the levels.<\/p>\n\n
There's also a period of time where Developers can still write suboptimal code whilst you work your way up to your desired level.<\/p>\n\n
Another approach is to use a feature of PHPStan called the baseline.<\/p>\n\n
The baseline is a way of capturing and saving all the existing errors up to the selected level so they are no longer reported.<\/p>\n\n
If you did this for an existing project, it would return no errors as everything would be included in the baseline.<\/p>\n\n
Once you decide what level you want your project to run, you can start as soon as the baseline is generated and without needing to change files multiple times.<\/p>\n\n
Instead of spending time working through the levels one at a time, commit some time to pruning the baseline and reducing the errors in it.<\/p>\n\n
This I think is a better approach and how I add PHPStan to existing codebases.<\/p>\n\n
To learn more about static analysis and PHPStan, listen to episode 22 of the Beyond Blocks podcast<\/a> with Dave Liddament.<\/p>\n\n ",
+ "summary": null
+ }
+ ],
+ "feeds_item": [
+ {
+ "imported": "2025-05-11T09:00:00+00:00",
+ "guid": null,
+ "hash": "9a7b258b69b97c51304c0aa8d6b87263",
+ "target_type": "feeds_feed",
+ "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
+ }
+ ]
+}
\ No newline at end of file
diff --git a/content/node.018a674d-e084-4947-b3d9-9459fb4b5e43.json b/content/node.018a674d-e084-4947-b3d9-9459fb4b5e43.json
deleted file mode 100644
index 246d80197..000000000
--- a/content/node.018a674d-e084-4947-b3d9-9459fb4b5e43.json
+++ /dev/null
@@ -1,100 +0,0 @@
-{
- "uuid": [
- {
- "value": "018a674d-e084-4947-b3d9-9459fb4b5e43"
- }
- ],
- "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:42+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": "Finding the best test base\n"
- }
- ],
- "created": [
- {
- "value": "2023-11-27T00:00:00+00:00"
- }
- ],
- "changed": [
- {
- "value": "2025-04-21T01:21:42+00:00"
- }
- ],
- "promote": [
- {
- "value": false
- }
- ],
- "sticky": [
- {
- "value": false
- }
- ],
- "default_langcode": [
- {
- "value": true
- }
- ],
- "revision_translation_affected": [
- {
- "value": true
- }
- ],
- "path": [
- {
- "alias": "\/daily\/2023\/11\/27\/finding-the-best-test-base",
- "langcode": "en"
- }
- ],
- "body": [
- {
- "value": "\n As well as different base classes for types of tests - i.e. functional, kernel and unit - there are other test base classes within those that can be used to simplify things.<\/p>\n\n
For example, if we have this test:<\/p>\n\n
<?php\n\nnamespace Drupal\\Tests\\example\\Kernel;\n\nuse Drupal\\KernelTests\\KernelTestBase;\nuse Drupal\\Tests\\node\\Traits\\NodeCreationTrait;\nuse Drupal\\Tests\\user\\Traits\\UserCreationTrait;\n\nclass ExampleTest extends KernelTestBase {\n\n use NodeCreationTrait;\n use UserCreationTrait;\n\n protected static $modules = [\n 'node',\n 'user',\n ];\n\n public function setUp(): void {\n parent::setUp();\n\n $this->installEntitySchema(entity_type_id: 'node');\n $this->installEntitySchema(entity_type_id: 'user');\n }\n\n public function testExample(): void {\n $user = $this->createUser();\n\n $article = $this->createNode([\n 'title' => 'Test article',\n 'uid' => $user,\n ]);\n\n self::assertSame('1', $article->getOwnerId());\n }\n\n}\n<\/code><\/pre>\n\nBoth creation traits must be imported, the node<\/code> and user<\/code> modules must be enabled, and the entity tables must be installed.<\/p>\n\nWhen writing a lot of tests, this can result in duplication and more complex tests that take longer to write.<\/p>\n\n
This can be simplified using EntityKernelTestBase<\/code> instead of KernelTestBase<\/code>:<\/p>\n\n<?php\n\nuse Drupal\\KernelTests\\Core\\Entity\\EntityKernelTestBase;\nuse Drupal\\Tests\\node\\Traits\\NodeCreationTrait;\n\nclass ExampleTest extends EntityKernelTestBase {\n\n use NodeCreationTrait;\n\n protected static $modules = [\n 'node',\n ];\n\n public function testExample(): void {\n $user = $this->createUser();\n\n $article = $this->createNode([\n 'title' => 'Test article',\n 'uid' => $user,\n ]);\n\n self::assertSame('1', $article->getOwnerId());\n }\n\n}\n<\/code><\/pre>\n\nThe class is simpler, fewer modules must be specified, and the entity schemas are automatically installed.<\/p>\n\n
As well as the core modules, some contrib modules also provide their own base test cases.<\/p>\n\n
If you're using the Webform module, you may want to use WebformAccessTestBase<\/code> instead of the standard UnitTestCase<\/code>.<\/p>\n\nIt's definitely worth spending some time looking at what base test cases are available and which are the best ones to use for your own tests.<\/p>\n\n ",
- "format": "full_html",
- "processed": "\n
As well as different base classes for types of tests - i.e. functional, kernel and unit - there are other test base classes within those that can be used to simplify things.<\/p>\n\n
For example, if we have this test:<\/p>\n\n
<?php\n\nnamespace Drupal\\Tests\\example\\Kernel;\n\nuse Drupal\\KernelTests\\KernelTestBase;\nuse Drupal\\Tests\\node\\Traits\\NodeCreationTrait;\nuse Drupal\\Tests\\user\\Traits\\UserCreationTrait;\n\nclass ExampleTest extends KernelTestBase {\n\n use NodeCreationTrait;\n use UserCreationTrait;\n\n protected static $modules = [\n 'node',\n 'user',\n ];\n\n public function setUp(): void {\n parent::setUp();\n\n $this->installEntitySchema(entity_type_id: 'node');\n $this->installEntitySchema(entity_type_id: 'user');\n }\n\n public function testExample(): void {\n $user = $this->createUser();\n\n $article = $this->createNode([\n 'title' => 'Test article',\n 'uid' => $user,\n ]);\n\n self::assertSame('1', $article->getOwnerId());\n }\n\n}\n<\/code><\/pre>\n\nBoth creation traits must be imported, the node<\/code> and user<\/code> modules must be enabled, and the entity tables must be installed.<\/p>\n\nWhen writing a lot of tests, this can result in duplication and more complex tests that take longer to write.<\/p>\n\n
This can be simplified using EntityKernelTestBase<\/code> instead of KernelTestBase<\/code>:<\/p>\n\n<?php\n\nuse Drupal\\KernelTests\\Core\\Entity\\EntityKernelTestBase;\nuse Drupal\\Tests\\node\\Traits\\NodeCreationTrait;\n\nclass ExampleTest extends EntityKernelTestBase {\n\n use NodeCreationTrait;\n\n protected static $modules = [\n 'node',\n ];\n\n public function testExample(): void {\n $user = $this->createUser();\n\n $article = $this->createNode([\n 'title' => 'Test article',\n 'uid' => $user,\n ]);\n\n self::assertSame('1', $article->getOwnerId());\n }\n\n}\n<\/code><\/pre>\n\nThe class is simpler, fewer modules must be specified, and the entity schemas are automatically installed.<\/p>\n\n
As well as the core modules, some contrib modules also provide their own base test cases.<\/p>\n\n
If you're using the Webform module, you may want to use WebformAccessTestBase<\/code> instead of the standard UnitTestCase<\/code>.<\/p>\n\nIt's definitely worth spending some time looking at what base test cases are available and which are the best ones to use for your own tests.<\/p>\n\n ",
- "summary": null
- }
- ],
- "feeds_item": [
- {
- "imported": "2025-04-21T01:21:42+00:00",
- "guid": null,
- "hash": "550456dfd70a84795f8c61ba84691a1d",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.018bf894-2d3e-4130-b0bd-43450ef5753a.json b/content/node.018bf894-2d3e-4130-b0bd-43450ef5753a.json
new file mode 100644
index 000000000..c26cf8b53
--- /dev/null
+++ b/content/node.018bf894-2d3e-4130-b0bd-43450ef5753a.json
@@ -0,0 +1,100 @@
+{
+ "uuid": [
+ {
+ "value": "018bf894-2d3e-4130-b0bd-43450ef5753a"
+ }
+ ],
+ "langcode": [
+ {
+ "value": "en"
+ }
+ ],
+ "type": [
+ {
+ "target_id": "daily_email",
+ "target_type": "node_type",
+ "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
+ }
+ ],
+ "revision_timestamp": [
+ {
+ "value": "2025-05-11T09:00:00+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": "Do we still need CSS preprocessors?"
+ }
+ ],
+ "created": [
+ {
+ "value": "2025-02-28T00:00:00+00:00"
+ }
+ ],
+ "changed": [
+ {
+ "value": "2025-05-11T09:00:00+00:00"
+ }
+ ],
+ "promote": [
+ {
+ "value": false
+ }
+ ],
+ "sticky": [
+ {
+ "value": false
+ }
+ ],
+ "default_langcode": [
+ {
+ "value": true
+ }
+ ],
+ "revision_translation_affected": [
+ {
+ "value": true
+ }
+ ],
+ "path": [
+ {
+ "alias": "\/daily\/2025\/02\/28\/preprocessors",
+ "langcode": "en"
+ }
+ ],
+ "body": [
+ {
+ "value": "\n
Before I started to use [Tailwind CSS][0], I used CSS preprocessors like Less and Sass to add features like variables and nesting to my CSS files.<\/p>\n\n
Stylesheets would be written in .scss, .sass or .less files and processed to create the stylesheets that would be used by browsers.<\/p>\n\n
But, with the recent improvements to CSS, do we still need these preprocessors?<\/p>\n\n
Here's a very small example of some CSS that just works:<\/p>\n\n
:root {\n --color-primary: red;\n --color-secondary: green;\n}\n\na {\n color: var(--color-primary);\n\n &:hover, &:focus {\n color: var(--color-secondary);\n }\n}\n<\/code><\/pre>\n\nIt looks like a Sass file, but it's native CSS.<\/p>\n\n
It has variables (a.k.a. custom properties) and nesting, which I think are the most used features from preprocessors.<\/p>\n\n
But there's no additional build step to generate the end stylesheet. I can use this stylesheet as it is - making it easier to work on and less confusing for new Developers.<\/p>\n\n
If I'm not using Tailwind CSS or atomic styles, writing plain CSS files is the approach I'd use.<\/p>\n\n
No preprocessors needed.<\/p>\n\n ",
+ "format": "full_html",
+ "processed": "\n
Before I started to use [Tailwind CSS][0], I used CSS preprocessors like Less and Sass to add features like variables and nesting to my CSS files.<\/p>\n\n
Stylesheets would be written in .scss, .sass or .less files and processed to create the stylesheets that would be used by browsers.<\/p>\n\n
But, with the recent improvements to CSS, do we still need these preprocessors?<\/p>\n\n
Here's a very small example of some CSS that just works:<\/p>\n\n
:root {\n --color-primary: red;\n --color-secondary: green;\n}\n\na {\n color: var(--color-primary);\n\n &:hover, &:focus {\n color: var(--color-secondary);\n }\n}\n<\/code><\/pre>\n\nIt looks like a Sass file, but it's native CSS.<\/p>\n\n
It has variables (a.k.a. custom properties) and nesting, which I think are the most used features from preprocessors.<\/p>\n\n
But there's no additional build step to generate the end stylesheet. I can use this stylesheet as it is - making it easier to work on and less confusing for new Developers.<\/p>\n\n
If I'm not using Tailwind CSS or atomic styles, writing plain CSS files is the approach I'd use.<\/p>\n\n
No preprocessors needed.<\/p>\n\n ",
+ "summary": null
+ }
+ ],
+ "feeds_item": [
+ {
+ "imported": "2025-05-11T09:00:00+00:00",
+ "guid": null,
+ "hash": "cdd9ab25b0351a9082e1580898e5ecbc",
+ "target_type": "feeds_feed",
+ "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
+ }
+ ]
+}
\ No newline at end of file
diff --git a/content/node.01b112a4-915a-4518-a75d-f9af67d2b119.json b/content/node.01b112a4-915a-4518-a75d-f9af67d2b119.json
deleted file mode 100644
index f021b0a4b..000000000
--- a/content/node.01b112a4-915a-4518-a75d-f9af67d2b119.json
+++ /dev/null
@@ -1,100 +0,0 @@
-{
- "uuid": [
- {
- "value": "01b112a4-915a-4518-a75d-f9af67d2b119"
- }
- ],
- "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:40+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": "Just..."
- }
- ],
- "created": [
- {
- "value": "2023-12-31T00:00:00+00:00"
- }
- ],
- "changed": [
- {
- "value": "2025-04-21T01:21:40+00:00"
- }
- ],
- "promote": [
- {
- "value": false
- }
- ],
- "sticky": [
- {
- "value": false
- }
- ],
- "default_langcode": [
- {
- "value": true
- }
- ],
- "revision_translation_affected": [
- {
- "value": true
- }
- ],
- "path": [
- {
- "alias": "\/daily\/2023\/12\/31\/just",
- "langcode": "en"
- }
- ],
- "body": [
- {
- "value": "\n
If you have a request that starts with \"Just\", it's likely a red flag!<\/p>\n\n
Why is it being made?<\/p>\n\n
What problem is it going to solve?<\/p>\n\n
Whose problem does it solve?<\/p>\n\n
Is the problem time-sensitive?<\/p>\n\n
What value does it add?<\/p>\n\n
Is it the best solution to fix the problem?<\/p>\n\n
Is it the best solution to fix the problem right now?<\/p>\n\n
To know this, we need to know why it's needed and it \"just\" needs doing.<\/p>\n\n ",
- "format": "full_html",
- "processed": "\n
If you have a request that starts with \"Just\", it's likely a red flag!<\/p>\n\n
Why is it being made?<\/p>\n\n
What problem is it going to solve?<\/p>\n\n
Whose problem does it solve?<\/p>\n\n
Is the problem time-sensitive?<\/p>\n\n
What value does it add?<\/p>\n\n
Is it the best solution to fix the problem?<\/p>\n\n
Is it the best solution to fix the problem right now?<\/p>\n\n
To know this, we need to know why it's needed and it \"just\" needs doing.<\/p>\n\n ",
- "summary": null
- }
- ],
- "feeds_item": [
- {
- "imported": "2025-04-21T01:21:40+00:00",
- "guid": null,
- "hash": "4f25a7d5fdd045a4a767afa851b0d6f0",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.01ba9676-20ed-4ba2-80de-5caf92ba7407.json b/content/node.01ba9676-20ed-4ba2-80de-5caf92ba7407.json
deleted file mode 100644
index 6bd38d432..000000000
--- a/content/node.01ba9676-20ed-4ba2-80de-5caf92ba7407.json
+++ /dev/null
@@ -1,100 +0,0 @@
-{
- "uuid": [
- {
- "value": "01ba9676-20ed-4ba2-80de-5caf92ba7407"
- }
- ],
- "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:25+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": "Why \"no build\" is appealing"
- }
- ],
- "created": [
- {
- "value": "2024-10-28T00:00:00+00:00"
- }
- ],
- "changed": [
- {
- "value": "2025-04-21T01:21:25+00:00"
- }
- ],
- "promote": [
- {
- "value": false
- }
- ],
- "sticky": [
- {
- "value": false
- }
- ],
- "default_langcode": [
- {
- "value": true
- }
- ],
- "revision_translation_affected": [
- {
- "value": true
- }
- ],
- "path": [
- {
- "alias": "\/daily\/2024\/10\/28\/why-no-build-is-appealing",
- "langcode": "en"
- }
- ],
- "body": [
- {
- "value": "\n
You're or a new\u00a0team member are\u00a0onboarded to a project to make some CSS changes.<\/p>\n\n
The project uses Sass, Less or another preprocessor.<\/p>\n\n
Not knowing this, the generated CSS files are changed instead of the Sass files.<\/p>\n\n
The changes are committed and pushed, but because they weren't added to the Sass files, they will be lost when the\u00a0CSS files are re-generated in the future.<\/p>\n\n
Or, if the Sass and CSS files become too out of sync, everyone will be too worried about losing changes to use the Sass files, so they will be abandoned\u00a0and not used.<\/p>\n\n
What if you change the\u00a0correct files but don't know the magic command to generate the assets for that project?<\/p>\n\n
I've seen things like this happen on numerous projects and is an example of why the \"no build\" approach is appealing.<\/p>\n\n
Especially with enhancements to CSS, such as custom properties (variables) and nesting, a lot of the functionality from preprocessors can now be done with normal CSS.<\/p>\n\n
This means the front-end build steps can be simplified\u00a0or removed entirely, reducing the technical overhead and dependency cost, and it's easier for new Developers to get started.<\/p>\n\n
Win, win!<\/p>\n\n ",
- "format": "full_html",
- "processed": "\n
You're or a new team member are onboarded to a project to make some CSS changes.<\/p>\n\n
The project uses Sass, Less or another preprocessor.<\/p>\n\n
Not knowing this, the generated CSS files are changed instead of the Sass files.<\/p>\n\n
The changes are committed and pushed, but because they weren't added to the Sass files, they will be lost when the CSS files are re-generated in the future.<\/p>\n\n
Or, if the Sass and CSS files become too out of sync, everyone will be too worried about losing changes to use the Sass files, so they will be abandoned and not used.<\/p>\n\n
What if you change the correct files but don't know the magic command to generate the assets for that project?<\/p>\n\n
I've seen things like this happen on numerous projects and is an example of why the \"no build\" approach is appealing.<\/p>\n\n
Especially with enhancements to CSS, such as custom properties (variables) and nesting, a lot of the functionality from preprocessors can now be done with normal CSS.<\/p>\n\n
This means the front-end build steps can be simplified or removed entirely, reducing the technical overhead and dependency cost, and it's easier for new Developers to get started.<\/p>\n\n
Win, win!<\/p>\n\n ",
- "summary": null
- }
- ],
- "feeds_item": [
- {
- "imported": "2025-04-21T01:21:25+00:00",
- "guid": null,
- "hash": "247a1b12455fa21f13c5bcd13b69f5c7",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.01d71d60-5764-4631-9294-38db7515d1d4.json b/content/node.01d71d60-5764-4631-9294-38db7515d1d4.json
deleted file mode 100644
index d62eb9dc7..000000000
--- a/content/node.01d71d60-5764-4631-9294-38db7515d1d4.json
+++ /dev/null
@@ -1,100 +0,0 @@
-{
- "uuid": [
- {
- "value": "01d71d60-5764-4631-9294-38db7515d1d4"
- }
- ],
- "langcode": [
- {
- "value": "en"
- }
- ],
- "type": [
- {
- "target_id": "daily_email",
- "target_type": "node_type",
- "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
- }
- ],
- "revision_timestamp": [
- {
- "value": "2025-05-11T06:09:49+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": "The best solution is the one that gets the tests to pass\n"
- }
- ],
- "created": [
- {
- "value": "2023-10-04T00:00:00+00:00"
- }
- ],
- "changed": [
- {
- "value": "2025-05-11T06:09:49+00:00"
- }
- ],
- "promote": [
- {
- "value": false
- }
- ],
- "sticky": [
- {
- "value": false
- }
- ],
- "default_langcode": [
- {
- "value": true
- }
- ],
- "revision_translation_affected": [
- {
- "value": true
- }
- ],
- "path": [
- {
- "alias": "\/daily\/2023\/10\/04\/the-best-solution-is-the-one-that-gets-the-tests-to-pass",
- "langcode": "en"
- }
- ],
- "body": [
- {
- "value": "\n
As I said yesterday, there is no perfect solution or approach for every situation.<\/p>\n\n
However, when doing test-driven development, there is a best solution.<\/p>\n\n
The simplest thing that gets a failing test to pass.<\/p>\n\n
Whether it's hard-coding a return value or putting the initial logic in a Controller, that's the objective.<\/p>\n\n
Once the test is passing, you can refactor the code or continue writing tests, which will each have their own best solution.<\/p>\n\n ",
- "format": "full_html",
- "processed": "\n
As I said yesterday, there is no perfect solution or approach for every situation.<\/p>\n\n
However, when doing test-driven development, there is a best solution.<\/p>\n\n
The simplest thing that gets a failing test to pass.<\/p>\n\n
Whether it's hard-coding a return value or putting the initial logic in a Controller, that's the objective.<\/p>\n\n
Once the test is passing, you can refactor the code or continue writing tests, which will each have their own best solution.<\/p>\n\n ",
- "summary": null
- }
- ],
- "feeds_item": [
- {
- "imported": "2025-05-11T06:09:49+00:00",
- "guid": null,
- "hash": "f999f40729d1c4017022ac0e4fd81a1d",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.01edae5a-f2cd-4e26-8de3-999d4ea7af3a.json b/content/node.01edae5a-f2cd-4e26-8de3-999d4ea7af3a.json
deleted file mode 100644
index 220b2411d..000000000
--- a/content/node.01edae5a-f2cd-4e26-8de3-999d4ea7af3a.json
+++ /dev/null
@@ -1,100 +0,0 @@
-{
- "uuid": [
- {
- "value": "01edae5a-f2cd-4e26-8de3-999d4ea7af3a"
- }
- ],
- "langcode": [
- {
- "value": "en"
- }
- ],
- "type": [
- {
- "target_id": "daily_email",
- "target_type": "node_type",
- "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
- }
- ],
- "revision_timestamp": [
- {
- "value": "2025-05-11T06:09:49+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": "Docker or Nix?\n"
- }
- ],
- "created": [
- {
- "value": "2023-07-02T00:00:00+00:00"
- }
- ],
- "changed": [
- {
- "value": "2025-05-11T06:09:49+00:00"
- }
- ],
- "promote": [
- {
- "value": false
- }
- ],
- "sticky": [
- {
- "value": false
- }
- ],
- "default_langcode": [
- {
- "value": true
- }
- ],
- "revision_translation_affected": [
- {
- "value": true
- }
- ],
- "path": [
- {
- "alias": "\/daily\/2023\/07\/02\/docker-or-nix",
- "langcode": "en"
- }
- ],
- "body": [
- {
- "value": "\n
I've been a Nix user for about a year, starting with its package manager on my previously installed Linux distribution.<\/p>\n\n
I started to use Home Manager for my user configuration and dotfiles and later switched to the NixOS operating system.<\/p>\n\n
Using Nix for software development<\/h2>\n\n
I've also been using Nix Flakes for per-project configuration.<\/p>\n\n
A Flake file is a simple file written in the Nix language that defines the project's dependencies and installs them from the Nix package manager.<\/p>\n\n
Here is an example Flake for a PHP CLI application:<\/p>\n\n
{\n\u00a0 inputs.nixpkgs.url = \"github:NixOS\/nixpkgs\/nixos-unstable\";\n\n\u00a0 outputs = inputs@{ flake-parts, ... }:\n\u00a0 \u00a0 flake-parts.lib.mkFlake { inherit inputs; } {\n\u00a0 \u00a0 \u00a0 systems = [ \"x86_64-linux\" ];\n\n\u00a0 \u00a0 \u00a0 perSystem = { config, self', inputs', pkgs, system, ... }: {\n\u00a0 \u00a0 \u00a0 \u00a0 devShells = {\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 default = pkgs.mkShell {\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 buildInputs = with pkgs; [ php82 php82Packages.composer ];\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 };\n\u00a0 \u00a0 \u00a0 \u00a0 };\n\u00a0 \u00a0 \u00a0 };\n\u00a0 \u00a0 };\n}\n<\/code><\/pre>\n\nIt declares that PHP 8.2 and Composer are available, even if I have different versions installed globally.<\/p>\n\n
Will Nix replace Docker?<\/h2>\n\n
Nix and Flakes have replaced Docker for me on some projects.<\/p>\n\n
If I have a simple setup and need a specific version of PHP or Node and some additional programs, I can get those from the Flake.<\/p>\n\n
I don't know if it'll replace Docker for me completely and work on more complex projects, but it's working well for me where I'm using it.<\/p>\n\n ",
- "format": "full_html",
- "processed": "\n
I've been a Nix user for about a year, starting with its package manager on my previously installed Linux distribution.<\/p>\n\n
I started to use Home Manager for my user configuration and dotfiles and later switched to the NixOS operating system.<\/p>\n\n
Using Nix for software development<\/h2>\n\n
I've also been using Nix Flakes for per-project configuration.<\/p>\n\n
A Flake file is a simple file written in the Nix language that defines the project's dependencies and installs them from the Nix package manager.<\/p>\n\n
Here is an example Flake for a PHP CLI application:<\/p>\n\n
{\n inputs.nixpkgs.url = \"github:NixOS\/nixpkgs\/nixos-unstable\";\n\n outputs = inputs@{ flake-parts, ... }:\n flake-parts.lib.mkFlake { inherit inputs; } {\n systems = [ \"x86_64-linux\" ];\n\n perSystem = { config, self', inputs', pkgs, system, ... }: {\n devShells = {\n default = pkgs.mkShell {\n buildInputs = with pkgs; [ php82 php82Packages.composer ];\n };\n };\n };\n };\n}\n<\/code><\/pre>\n\nIt declares that PHP 8.2 and Composer are available, even if I have different versions installed globally.<\/p>\n\n
Will Nix replace Docker?<\/h2>\n\n
Nix and Flakes have replaced Docker for me on some projects.<\/p>\n\n
If I have a simple setup and need a specific version of PHP or Node and some additional programs, I can get those from the Flake.<\/p>\n\n
I don't know if it'll replace Docker for me completely and work on more complex projects, but it's working well for me where I'm using it.<\/p>\n\n ",
- "summary": null
- }
- ],
- "feeds_item": [
- {
- "imported": "2025-05-11T06:09:49+00:00",
- "guid": null,
- "hash": "7f55d425fa5b0836f5c8d0f6980cc54e",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.01f3b831-e981-471f-aef9-076b054e3495.json b/content/node.01f3b831-e981-471f-aef9-076b054e3495.json
new file mode 100644
index 000000000..3cad7197c
--- /dev/null
+++ b/content/node.01f3b831-e981-471f-aef9-076b054e3495.json
@@ -0,0 +1,100 @@
+{
+ "uuid": [
+ {
+ "value": "01f3b831-e981-471f-aef9-076b054e3495"
+ }
+ ],
+ "langcode": [
+ {
+ "value": "en"
+ }
+ ],
+ "type": [
+ {
+ "target_id": "daily_email",
+ "target_type": "node_type",
+ "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
+ }
+ ],
+ "revision_timestamp": [
+ {
+ "value": "2025-05-11T09:00: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": "Testing is all about confidence\n"
+ }
+ ],
+ "created": [
+ {
+ "value": "2023-07-24T00:00:00+00:00"
+ }
+ ],
+ "changed": [
+ {
+ "value": "2025-05-11T09:00:36+00:00"
+ }
+ ],
+ "promote": [
+ {
+ "value": false
+ }
+ ],
+ "sticky": [
+ {
+ "value": false
+ }
+ ],
+ "default_langcode": [
+ {
+ "value": true
+ }
+ ],
+ "revision_translation_affected": [
+ {
+ "value": true
+ }
+ ],
+ "path": [
+ {
+ "alias": "\/daily\/2023\/07\/24\/testing-is-all-about-confidence",
+ "langcode": "en"
+ }
+ ],
+ "body": [
+ {
+ "value": "\n
Testing - manual or automated - is about building confidence.<\/p>\n\n
If we deploy this change or release this feature, are we confident it will work as expected and not cause regressions elsewhere?<\/p>\n\n
What if someone asked you on a scale between one and ten?<\/p>\n\n
From an automated perspective, have you written enough tests for the feature to be confident it works?<\/p>\n\n
If you're fixing a bug, do you have a test that reproduces the bug that was originally failing but now passing since you've added the fix?<\/p>\n\n
Do the tests have enough assertions, and have you covered enough use cases and scenarios?<\/p>\n\n
Here's the thing<\/h2>\n\n
You can utilise code coverage metrics, but no hard rule says that the feature will work once x percentage is covered. Something with 100% coverage can still contain bugs.<\/p>\n\n
For me, it's about the answer to the question:<\/p>\n\n
If we deploy this change, how confident are you that it will work as expected?<\/p>\n\n ",
+ "format": "full_html",
+ "processed": "\n
Testing - manual or automated - is about building confidence.<\/p>\n\n
If we deploy this change or release this feature, are we confident it will work as expected and not cause regressions elsewhere?<\/p>\n\n
What if someone asked you on a scale between one and ten?<\/p>\n\n
From an automated perspective, have you written enough tests for the feature to be confident it works?<\/p>\n\n
If you're fixing a bug, do you have a test that reproduces the bug that was originally failing but now passing since you've added the fix?<\/p>\n\n
Do the tests have enough assertions, and have you covered enough use cases and scenarios?<\/p>\n\n
Here's the thing<\/h2>\n\n
You can utilise code coverage metrics, but no hard rule says that the feature will work once x percentage is covered. Something with 100% coverage can still contain bugs.<\/p>\n\n
For me, it's about the answer to the question:<\/p>\n\n
If we deploy this change, how confident are you that it will work as expected?<\/p>\n\n ",
+ "summary": null
+ }
+ ],
+ "feeds_item": [
+ {
+ "imported": "2025-05-11T09:00:36+00:00",
+ "guid": null,
+ "hash": "60c550711c51c2b739051e4640eba954",
+ "target_type": "feeds_feed",
+ "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
+ }
+ ]
+}
\ No newline at end of file
diff --git a/content/node.01f4015e-252c-4e96-9e0c-91cf1045044b.json b/content/node.01f4015e-252c-4e96-9e0c-91cf1045044b.json
deleted file mode 100644
index 6a02ffbf8..000000000
--- a/content/node.01f4015e-252c-4e96-9e0c-91cf1045044b.json
+++ /dev/null
@@ -1,100 +0,0 @@
-{
- "uuid": [
- {
- "value": "01f4015e-252c-4e96-9e0c-91cf1045044b"
- }
- ],
- "langcode": [
- {
- "value": "en"
- }
- ],
- "type": [
- {
- "target_id": "daily_email",
- "target_type": "node_type",
- "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
- }
- ],
- "revision_timestamp": [
- {
- "value": "2025-05-11T06:09:49+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": "Busy working on client projects\n"
- }
- ],
- "created": [
- {
- "value": "2023-03-02T00:00:00+00:00"
- }
- ],
- "changed": [
- {
- "value": "2025-05-11T06:09:49+00:00"
- }
- ],
- "promote": [
- {
- "value": false
- }
- ],
- "sticky": [
- {
- "value": false
- }
- ],
- "default_langcode": [
- {
- "value": true
- }
- ],
- "revision_translation_affected": [
- {
- "value": true
- }
- ],
- "path": [
- {
- "alias": "\/daily\/2023\/03\/02\/busy-working-on-client-projects",
- "langcode": "en"
- }
- ],
- "body": [
- {
- "value": "\n
As well as starting to speak again at conferences and meetups, I've been very busy lately with various client projects. I've been working on completing the next phase and launch of the next website for a long-term client and handed over some other completed projects.<\/p>\n\n
This has affected me sending out these emails every day and I missed a few days last month.<\/p>\n\n
I'll do better!<\/p>\n\n ",
- "format": "full_html",
- "processed": "\n
As well as starting to speak again at conferences and meetups, I've been very busy lately with various client projects. I've been working on completing the next phase and launch of the next website for a long-term client and handed over some other completed projects.<\/p>\n\n
This has affected me sending out these emails every day and I missed a few days last month.<\/p>\n\n
I'll do better!<\/p>\n\n ",
- "summary": null
- }
- ],
- "feeds_item": [
- {
- "imported": "2025-05-11T06:09:49+00:00",
- "guid": null,
- "hash": "6b223577d98aafcacf18ecbf423a3497",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.020b3de3-da10-4107-9616-a40786092144.json b/content/node.020b3de3-da10-4107-9616-a40786092144.json
deleted file mode 100644
index 487e76a28..000000000
--- a/content/node.020b3de3-da10-4107-9616-a40786092144.json
+++ /dev/null
@@ -1,100 +0,0 @@
-{
- "uuid": [
- {
- "value": "020b3de3-da10-4107-9616-a40786092144"
- }
- ],
- "langcode": [
- {
- "value": "en"
- }
- ],
- "type": [
- {
- "target_id": "daily_email",
- "target_type": "node_type",
- "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
- }
- ],
- "revision_timestamp": [
- {
- "value": "2025-05-11T06:09:49+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": "Don't estimate separately for testing\n"
- }
- ],
- "created": [
- {
- "value": "2023-08-13T00:00:00+00:00"
- }
- ],
- "changed": [
- {
- "value": "2025-05-11T06:09:49+00:00"
- }
- ],
- "promote": [
- {
- "value": false
- }
- ],
- "sticky": [
- {
- "value": false
- }
- ],
- "default_langcode": [
- {
- "value": true
- }
- ],
- "revision_translation_affected": [
- {
- "value": true
- }
- ],
- "path": [
- {
- "alias": "\/daily\/2023\/08\/13\/dont-estimate-separately-for-testing",
- "langcode": "en"
- }
- ],
- "body": [
- {
- "value": "\n
A common issue I see for people introducing automated testing is estimating the testing and implementation of a task separately.<\/p>\n\n
Something like, \"It'll take x to do the work and x to write the tests for it\".<\/p>\n\n
As well as implying you'd write all the code and then all the tests or vice versa, if you provide separate estimates, it's easy for someone to think the tests are optional and can be removed.<\/p>\n\n
If you provide one estimate for both, this can't happen.<\/p>\n\n ",
- "format": "full_html",
- "processed": "\n
A common issue I see for people introducing automated testing is estimating the testing and implementation of a task separately.<\/p>\n\n
Something like, \"It'll take x to do the work and x to write the tests for it\".<\/p>\n\n
As well as implying you'd write all the code and then all the tests or vice versa, if you provide separate estimates, it's easy for someone to think the tests are optional and can be removed.<\/p>\n\n
If you provide one estimate for both, this can't happen.<\/p>\n\n ",
- "summary": null
- }
- ],
- "feeds_item": [
- {
- "imported": "2025-05-11T06:09:49+00:00",
- "guid": null,
- "hash": "b2a503f52e0d13b65158e0770ce490d5",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.021e00c1-b813-4edd-8064-71285bc3647d.json b/content/node.021e00c1-b813-4edd-8064-71285bc3647d.json
new file mode 100644
index 000000000..b4fb222a2
--- /dev/null
+++ b/content/node.021e00c1-b813-4edd-8064-71285bc3647d.json
@@ -0,0 +1,100 @@
+{
+ "uuid": [
+ {
+ "value": "021e00c1-b813-4edd-8064-71285bc3647d"
+ }
+ ],
+ "langcode": [
+ {
+ "value": "en"
+ }
+ ],
+ "type": [
+ {
+ "target_id": "daily_email",
+ "target_type": "node_type",
+ "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
+ }
+ ],
+ "revision_timestamp": [
+ {
+ "value": "2025-05-11T09:00:10+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": "Recording architectural decisions"
+ }
+ ],
+ "created": [
+ {
+ "value": "2024-06-12T00:00:00+00:00"
+ }
+ ],
+ "changed": [
+ {
+ "value": "2025-05-11T09:00:10+00:00"
+ }
+ ],
+ "promote": [
+ {
+ "value": false
+ }
+ ],
+ "sticky": [
+ {
+ "value": false
+ }
+ ],
+ "default_langcode": [
+ {
+ "value": true
+ }
+ ],
+ "revision_translation_affected": [
+ {
+ "value": true
+ }
+ ],
+ "path": [
+ {
+ "alias": "\/daily\/2024\/06\/12\/recording-architectural-decisions",
+ "langcode": "en"
+ }
+ ],
+ "body": [
+ {
+ "value": "\n
I recently saw this post on X<\/a>, talking about an open-source project.<\/p>\n\nThis was the part that I want to highlight:<\/p>\n\n
\n I was also impressed by the decisions documents. More projects should implement this concept.<\/p>\n<\/blockquote>\n\n
Looking at the repository, it contains records of 36 decisions made on the project between May 2023 and April 2024.<\/p>\n\n
Decision records provide useful information to new people to a project, whether you want to contribute to an open-source project or it's a new client or work codebase.<\/p>\n\n
The code and project will likely continue once you've finished working on it, so capturing decisions for future Developers is key.<\/p>\n\n
I've often joined projects and wondered why or how something was done, and can only guess as the decision wasn't recorded or is somewhere not available to me, such as an old wiki or ticketing system.<\/p>\n\n
Here's the thing<\/h2>\n\n
I agree with the poster.<\/p>\n\n
More people should record the decisions made on their project, whether it's open-source or not.<\/p>\n\n ",
+ "format": "full_html",
+ "processed": "\n
I recently saw this post on X<\/a>, talking about an open-source project.<\/p>\n\nThis was the part that I want to highlight:<\/p>\n\n
\n I was also impressed by the decisions documents. More projects should implement this concept.<\/p>\n<\/blockquote>\n\n
Looking at the repository, it contains records of 36 decisions made on the project between May 2023 and April 2024.<\/p>\n\n
Decision records provide useful information to new people to a project, whether you want to contribute to an open-source project or it's a new client or work codebase.<\/p>\n\n
The code and project will likely continue once you've finished working on it, so capturing decisions for future Developers is key.<\/p>\n\n
I've often joined projects and wondered why or how something was done, and can only guess as the decision wasn't recorded or is somewhere not available to me, such as an old wiki or ticketing system.<\/p>\n\n
Here's the thing<\/h2>\n\n
I agree with the poster.<\/p>\n\n
More people should record the decisions made on their project, whether it's open-source or not.<\/p>\n\n ",
+ "summary": null
+ }
+ ],
+ "feeds_item": [
+ {
+ "imported": "2025-05-11T09:00:10+00:00",
+ "guid": null,
+ "hash": "bc11c3125e2e228f16b76f91b749c764",
+ "target_type": "feeds_feed",
+ "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
+ }
+ ]
+}
\ No newline at end of file
diff --git a/content/node.0231b26c-ac28-44e8-a2bf-cc7c86984e7e.json b/content/node.0231b26c-ac28-44e8-a2bf-cc7c86984e7e.json
new file mode 100644
index 000000000..c003dbb60
--- /dev/null
+++ b/content/node.0231b26c-ac28-44e8-a2bf-cc7c86984e7e.json
@@ -0,0 +1,100 @@
+{
+ "uuid": [
+ {
+ "value": "0231b26c-ac28-44e8-a2bf-cc7c86984e7e"
+ }
+ ],
+ "langcode": [
+ {
+ "value": "en"
+ }
+ ],
+ "type": [
+ {
+ "target_id": "daily_email",
+ "target_type": "node_type",
+ "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
+ }
+ ],
+ "revision_timestamp": [
+ {
+ "value": "2025-05-11T09:00:48+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": "To squash or not to squash\n"
+ }
+ ],
+ "created": [
+ {
+ "value": "2023-01-25T00:00:00+00:00"
+ }
+ ],
+ "changed": [
+ {
+ "value": "2025-05-11T09:00:48+00:00"
+ }
+ ],
+ "promote": [
+ {
+ "value": false
+ }
+ ],
+ "sticky": [
+ {
+ "value": false
+ }
+ ],
+ "default_langcode": [
+ {
+ "value": true
+ }
+ ],
+ "revision_translation_affected": [
+ {
+ "value": true
+ }
+ ],
+ "path": [
+ {
+ "alias": "\/daily\/2023\/01\/25\/to-squash-or-not-to-squash",
+ "langcode": "en"
+ }
+ ],
+ "body": [
+ {
+ "value": "\n
When reviewing a pull or merge request, tools like GitHub and GitHub offer the option to squash the commits before merging.<\/p>\n\n
If the request had twenty commits, they'd be combined into a single commit before being merged.<\/p>\n\n
But should you do it?<\/p>\n\n
The answer will be \"it depends\" based on the project or team, but I'm personally not a fan of squashing commits.<\/p>\n\n
Even though I commit small changes often, I put quite a bit of effort into crafting commits and writing detailed commit messages<\/a> that capture the reason for each change. If the commits are squashed, either the messages will be combined into one extra-long commit message or I've seen them be deleted completely.<\/p>\n\nOne large commit message would be very difficult to read and connect specific messages with their changes, and deleting the commit body would lose the history completely and waste the time it took to write the messages and craft the commits. It may be available within the pull or merge request page but there's no guarantee that you'll continue to use the same repository hosting service in the future.<\/p>\n\n
One large commit would also be difficult to debug if there was an error. If the whole feature was added in a single commit, tools like git bisect<\/a> would no longer work and a single commit couldn't be simply reverted if it contained a bug.<\/p>\n\nI prefer to keep the original small commits and instead prefer to use rebasing and only fast-forward merges to avoid merge commits and keep a simple, linear history in my Git log, and be able to easily read, find and, if needed, fix the code that's been committed.<\/p>\n\n ",
+ "format": "full_html",
+ "processed": "\n
When reviewing a pull or merge request, tools like GitHub and GitHub offer the option to squash the commits before merging.<\/p>\n\n
If the request had twenty commits, they'd be combined into a single commit before being merged.<\/p>\n\n
But should you do it?<\/p>\n\n
The answer will be \"it depends\" based on the project or team, but I'm personally not a fan of squashing commits.<\/p>\n\n
Even though I commit small changes often, I put quite a bit of effort into crafting commits and writing detailed commit messages<\/a> that capture the reason for each change. If the commits are squashed, either the messages will be combined into one extra-long commit message or I've seen them be deleted completely.<\/p>\n\nOne large commit message would be very difficult to read and connect specific messages with their changes, and deleting the commit body would lose the history completely and waste the time it took to write the messages and craft the commits. It may be available within the pull or merge request page but there's no guarantee that you'll continue to use the same repository hosting service in the future.<\/p>\n\n
One large commit would also be difficult to debug if there was an error. If the whole feature was added in a single commit, tools like git bisect<\/a> would no longer work and a single commit couldn't be simply reverted if it contained a bug.<\/p>\n\nI prefer to keep the original small commits and instead prefer to use rebasing and only fast-forward merges to avoid merge commits and keep a simple, linear history in my Git log, and be able to easily read, find and, if needed, fix the code that's been committed.<\/p>\n\n ",
+ "summary": null
+ }
+ ],
+ "feeds_item": [
+ {
+ "imported": "2025-05-11T09:00:48+00:00",
+ "guid": null,
+ "hash": "54447bfd288cd6e71d4b06bd0646502d",
+ "target_type": "feeds_feed",
+ "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
+ }
+ ]
+}
\ No newline at end of file
diff --git a/content/node.024f2c81-68af-4eef-bea5-1b1d43bd1b39.json b/content/node.024f2c81-68af-4eef-bea5-1b1d43bd1b39.json
new file mode 100644
index 000000000..4bfd30fdd
--- /dev/null
+++ b/content/node.024f2c81-68af-4eef-bea5-1b1d43bd1b39.json
@@ -0,0 +1,100 @@
+{
+ "uuid": [
+ {
+ "value": "024f2c81-68af-4eef-bea5-1b1d43bd1b39"
+ }
+ ],
+ "langcode": [
+ {
+ "value": "en"
+ }
+ ],
+ "type": [
+ {
+ "target_id": "daily_email",
+ "target_type": "node_type",
+ "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
+ }
+ ],
+ "revision_timestamp": [
+ {
+ "value": "2025-05-11T09:00:40+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": "Why is backward compatibility important?\n"
+ }
+ ],
+ "created": [
+ {
+ "value": "2023-05-18T00:00:00+00:00"
+ }
+ ],
+ "changed": [
+ {
+ "value": "2025-05-11T09:00:40+00:00"
+ }
+ ],
+ "promote": [
+ {
+ "value": false
+ }
+ ],
+ "sticky": [
+ {
+ "value": false
+ }
+ ],
+ "default_langcode": [
+ {
+ "value": true
+ }
+ ],
+ "revision_translation_affected": [
+ {
+ "value": true
+ }
+ ],
+ "path": [
+ {
+ "alias": "\/daily\/2023\/05\/18\/why-is-backward-compatibility-important",
+ "langcode": "en"
+ }
+ ],
+ "body": [
+ {
+ "value": "\n
In yesterday's email, I mentioned that deprecating code allows it to be backwards compatible - but what does that mean?<\/p>\n\n
If I were to remove a function like drupal_set_message()<\/code> that is used code elsewhere in an application, the code would no longer work and would break.<\/p>\n\nAs a module or library maintainer, I don't want to cause applications to break by making backward incompatible changes (a \"BC break\" or a \"breaking change\").<\/p>\n\n
Maintaining backward compatibility means that people who use the code can update to the latest version without breakages, and if they use any deprecated code, they know to update it to be compatible with future versions.<\/p>\n\n ",
+ "format": "full_html",
+ "processed": "\n
In yesterday's email, I mentioned that deprecating code allows it to be backwards compatible - but what does that mean?<\/p>\n\n
If I were to remove a function like drupal_set_message()<\/code> that is used code elsewhere in an application, the code would no longer work and would break.<\/p>\n\nAs a module or library maintainer, I don't want to cause applications to break by making backward incompatible changes (a \"BC break\" or a \"breaking change\").<\/p>\n\n
Maintaining backward compatibility means that people who use the code can update to the latest version without breakages, and if they use any deprecated code, they know to update it to be compatible with future versions.<\/p>\n\n ",
+ "summary": null
+ }
+ ],
+ "feeds_item": [
+ {
+ "imported": "2025-05-11T09:00:40+00:00",
+ "guid": null,
+ "hash": "18e7b8e123a0c299bb44600a75b56d9e",
+ "target_type": "feeds_feed",
+ "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
+ }
+ ]
+}
\ No newline at end of file
diff --git a/content/node.025f0dde-748b-44f4-93e2-4e0602d30104.json b/content/node.025f0dde-748b-44f4-93e2-4e0602d30104.json
new file mode 100644
index 000000000..c7d9b35b8
--- /dev/null
+++ b/content/node.025f0dde-748b-44f4-93e2-4e0602d30104.json
@@ -0,0 +1,100 @@
+{
+ "uuid": [
+ {
+ "value": "025f0dde-748b-44f4-93e2-4e0602d30104"
+ }
+ ],
+ "langcode": [
+ {
+ "value": "en"
+ }
+ ],
+ "type": [
+ {
+ "target_id": "daily_email",
+ "target_type": "node_type",
+ "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
+ }
+ ],
+ "revision_timestamp": [
+ {
+ "value": "2025-05-11T09:00:34+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": "8 years of dotfiles\n"
+ }
+ ],
+ "created": [
+ {
+ "value": "2023-08-08T00:00:00+00:00"
+ }
+ ],
+ "changed": [
+ {
+ "value": "2025-05-11T09:00:34+00:00"
+ }
+ ],
+ "promote": [
+ {
+ "value": false
+ }
+ ],
+ "sticky": [
+ {
+ "value": false
+ }
+ ],
+ "default_langcode": [
+ {
+ "value": true
+ }
+ ],
+ "revision_translation_affected": [
+ {
+ "value": true
+ }
+ ],
+ "path": [
+ {
+ "alias": "\/daily\/2023\/08\/08\/8-years-of-dotfiles",
+ "langcode": "en"
+ }
+ ],
+ "body": [
+ {
+ "value": "\n
Today, I was speaking with a colleague about configuring Git, which led to a conversation about dotfiles repositories - somewhere where you version the changes to your configuration files and, usually, create symlinks to their expected locations.<\/p>\n\n
Afterwards, I realised the first commit to my personal dotfiles repository<\/a> was over eight years ago, in July 2015.<\/p>\n\nWhat started as a repository to put my own Git configuration has undergone various changes since the tools I use changed, as well as the tools to manage the files themselves.<\/p>\n\n
In 2021, I switched my .vimrc<\/code> configuration file to an init.vim<\/code> and switched to Neovim full-time and, most recently, almost a year ago, I started to use the Nix package manager and later adopted NixOS as my primary Linux distribution.<\/p>\n\nMy complete NixOS and Home Manager configurations are within my dotfiles<\/code> repository, and the configuration for tools, including Neovim, tmux and Git.<\/p>\n\nI wonder what the repository will look like in another eight years...<\/p>\n\n ",
+ "format": "full_html",
+ "processed": "\n
Today, I was speaking with a colleague about configuring Git, which led to a conversation about dotfiles repositories - somewhere where you version the changes to your configuration files and, usually, create symlinks to their expected locations.<\/p>\n\n
Afterwards, I realised the first commit to my personal dotfiles repository<\/a> was over eight years ago, in July 2015.<\/p>\n\nWhat started as a repository to put my own Git configuration has undergone various changes since the tools I use changed, as well as the tools to manage the files themselves.<\/p>\n\n
In 2021, I switched my .vimrc<\/code> configuration file to an init.vim<\/code> and switched to Neovim full-time and, most recently, almost a year ago, I started to use the Nix package manager and later adopted NixOS as my primary Linux distribution.<\/p>\n\nMy complete NixOS and Home Manager configurations are within my dotfiles<\/code> repository, and the configuration for tools, including Neovim, tmux and Git.<\/p>\n\nI wonder what the repository will look like in another eight years...<\/p>\n\n ",
+ "summary": null
+ }
+ ],
+ "feeds_item": [
+ {
+ "imported": "2025-05-11T09:00:34+00:00",
+ "guid": null,
+ "hash": "b663fb9c5e0257d2fdece24454ad3bfd",
+ "target_type": "feeds_feed",
+ "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
+ }
+ ]
+}
\ No newline at end of file
diff --git a/content/node.02777730-3fe8-4eba-8a16-e847042b7351.json b/content/node.02777730-3fe8-4eba-8a16-e847042b7351.json
new file mode 100644
index 000000000..51abcf0de
--- /dev/null
+++ b/content/node.02777730-3fe8-4eba-8a16-e847042b7351.json
@@ -0,0 +1,100 @@
+{
+ "uuid": [
+ {
+ "value": "02777730-3fe8-4eba-8a16-e847042b7351"
+ }
+ ],
+ "langcode": [
+ {
+ "value": "en"
+ }
+ ],
+ "type": [
+ {
+ "target_id": "daily_email",
+ "target_type": "node_type",
+ "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
+ }
+ ],
+ "revision_timestamp": [
+ {
+ "value": "2025-05-11T09:00:57+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": "Giving back"
+ }
+ ],
+ "created": [
+ {
+ "value": "2022-08-27T00:00:00+00:00"
+ }
+ ],
+ "changed": [
+ {
+ "value": "2025-05-11T09:00:57+00:00"
+ }
+ ],
+ "promote": [
+ {
+ "value": false
+ }
+ ],
+ "sticky": [
+ {
+ "value": false
+ }
+ ],
+ "default_langcode": [
+ {
+ "value": true
+ }
+ ],
+ "revision_translation_affected": [
+ {
+ "value": true
+ }
+ ],
+ "path": [
+ {
+ "alias": "\/daily\/2022\/08\/27\/giving-back",
+ "langcode": "en"
+ }
+ ],
+ "body": [
+ {
+ "value": "\n
Today, I've been at an event run by a local animal rescue charity. It's one that we attend often as my children like to enter the dog show, but this year, I've also sponsored one of the categories.<\/p>\n\n
As well as organising the PHP South Wales user group, I'm also now a sponsor - donating books and elePHPant plushies for raffle prizes and paying the group's Meetup.com subscription costs.<\/p>\n\n
Giving back and supporting open-source maintainers and content creators is a big priority of mine. If I use some open-source software or find that someone's Twitch or YouTube channel is useful, if that person or organisation is on GitHub or Patron, then I'll sponsor them, or I'll subscribe to their channel.<\/p>\n\n
If I find a useful blog post or video, I'll add a comment or link to it on Twitter, thanking them and letting them know that it helped me.<\/p>\n\n
Especially if it's something that I've used within my projects, it makes sense to support it and it's maintainers, so that they keep working on and improving the software, continue streaming, and keep writing blog posts and recording videos for me to learn from.<\/p>\n\n ",
+ "format": "full_html",
+ "processed": "\n
Today, I've been at an event run by a local animal rescue charity. It's one that we attend often as my children like to enter the dog show, but this year, I've also sponsored one of the categories.<\/p>\n\n
As well as organising the PHP South Wales user group, I'm also now a sponsor - donating books and elePHPant plushies for raffle prizes and paying the group's Meetup.com subscription costs.<\/p>\n\n
Giving back and supporting open-source maintainers and content creators is a big priority of mine. If I use some open-source software or find that someone's Twitch or YouTube channel is useful, if that person or organisation is on GitHub or Patron, then I'll sponsor them, or I'll subscribe to their channel.<\/p>\n\n
If I find a useful blog post or video, I'll add a comment or link to it on Twitter, thanking them and letting them know that it helped me.<\/p>\n\n
Especially if it's something that I've used within my projects, it makes sense to support it and it's maintainers, so that they keep working on and improving the software, continue streaming, and keep writing blog posts and recording videos for me to learn from.<\/p>\n\n ",
+ "summary": null
+ }
+ ],
+ "feeds_item": [
+ {
+ "imported": "2025-05-11T09:00:57+00:00",
+ "guid": null,
+ "hash": "891d018e5d9b5fa68288878004365cce",
+ "target_type": "feeds_feed",
+ "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
+ }
+ ]
+}
\ No newline at end of file
diff --git a/content/node.027d3741-bf06-4348-9293-9993b2adb5e3.json b/content/node.027d3741-bf06-4348-9293-9993b2adb5e3.json
deleted file mode 100644
index f4581705d..000000000
--- a/content/node.027d3741-bf06-4348-9293-9993b2adb5e3.json
+++ /dev/null
@@ -1,100 +0,0 @@
-{
- "uuid": [
- {
- "value": "027d3741-bf06-4348-9293-9993b2adb5e3"
- }
- ],
- "langcode": [
- {
- "value": "en"
- }
- ],
- "type": [
- {
- "target_id": "daily_email",
- "target_type": "node_type",
- "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
- }
- ],
- "revision_timestamp": [
- {
- "value": "2025-05-11T06:09:49+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": "One more month of Drupal 7"
- }
- ],
- "created": [
- {
- "value": "2024-12-06T00:00:00+00:00"
- }
- ],
- "changed": [
- {
- "value": "2025-05-11T06:09:49+00:00"
- }
- ],
- "promote": [
- {
- "value": false
- }
- ],
- "sticky": [
- {
- "value": false
- }
- ],
- "default_langcode": [
- {
- "value": true
- }
- ],
- "revision_translation_affected": [
- {
- "value": true
- }
- ],
- "path": [
- {
- "alias": "\/daily\/2024\/12\/06\/one-more-month",
- "langcode": "en"
- }
- ],
- "body": [
- {
- "value": "\n
On the 5th of January, Drupal 7 will be end of life and have no further updates.<\/p>\n\n
Released in January 2011<\/a>, Drupal 7 will be 14 years old in January and will have outlived Drupal 8 and 9 which are already unsupported.<\/p>\n\nThere are a lot of Drupal 7 sites still in production, but it's been interesting to see usage numbers for the Override Node Options module decrease for Drupal 7 and increase for Drupal 8+<\/a> over the last year.<\/p>\n\nI'm excited to see Drupal usage continue to move towards the newer versions so everyone can benefit from the new features and improvements in Drupal 10 and 11 and the new Drupal CMS project.<\/p>\n\n ",
- "format": "full_html",
- "processed": "\n
On the 5th of January, Drupal 7 will be end of life and have no further updates.<\/p>\n\n
Released in January 2011<\/a>, Drupal 7 will be 14 years old in January and will have outlived Drupal 8 and 9 which are already unsupported.<\/p>\n\nThere are a lot of Drupal 7 sites still in production, but it's been interesting to see usage numbers for the Override Node Options module decrease for Drupal 7 and increase for Drupal 8+<\/a> over the last year.<\/p>\n\nI'm excited to see Drupal usage continue to move towards the newer versions so everyone can benefit from the new features and improvements in Drupal 10 and 11 and the new Drupal CMS project.<\/p>\n\n ",
- "summary": null
- }
- ],
- "feeds_item": [
- {
- "imported": "2025-05-11T06:09:49+00:00",
- "guid": null,
- "hash": "e93df0be19a187ce2cfa64f7e7f55371",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.027ebf68-13b3-4ae5-bd71-08e0f42f7898.json b/content/node.027ebf68-13b3-4ae5-bd71-08e0f42f7898.json
deleted file mode 100644
index 83f90451b..000000000
--- a/content/node.027ebf68-13b3-4ae5-bd71-08e0f42f7898.json
+++ /dev/null
@@ -1,100 +0,0 @@
-{
- "uuid": [
- {
- "value": "027ebf68-13b3-4ae5-bd71-08e0f42f7898"
- }
- ],
- "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:31+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": "Ask questions"
- }
- ],
- "created": [
- {
- "value": "2024-05-30T00:00:00+00:00"
- }
- ],
- "changed": [
- {
- "value": "2025-04-21T01:21:31+00:00"
- }
- ],
- "promote": [
- {
- "value": false
- }
- ],
- "sticky": [
- {
- "value": false
- }
- ],
- "default_langcode": [
- {
- "value": true
- }
- ],
- "revision_translation_affected": [
- {
- "value": true
- }
- ],
- "path": [
- {
- "alias": "\/daily\/2024\/05\/30\/ask-questions",
- "langcode": "en"
- }
- ],
- "body": [
- {
- "value": "\n
As a Software Developer, it's common to hear that you need to ask questions to progress or work efficiently.<\/p>\n\n
You shouldn't just ask technical questions, though.<\/p>\n\n
Also ask questions like:<\/p>\n\n
\n- What do we want to achieve by delivering this feature?<\/li>\n
- How do we know if it's a success (or not)?<\/li>\n
- What business value does this add and who will benefit?<\/li>\n
- Why do this now? Why not wait a few months or not do it at all?<\/li>\n
- Is there an existing solution for this?<\/li>\n
- Can we achieve the same or a similar result in a different way?<\/li>\n<\/ul>\n\n
As well as knowing how to do something, it's important to know why it needs to be done.<\/p>\n\n ",
- "format": "full_html",
- "processed": "\n
As a Software Developer, it's common to hear that you need to ask questions to progress or work efficiently.<\/p>\n\n
You shouldn't just ask technical questions, though.<\/p>\n\n
Also ask questions like:<\/p>\n\n
\n- What do we want to achieve by delivering this feature?<\/li>\n
- How do we know if it's a success (or not)?<\/li>\n
- What business value does this add and who will benefit?<\/li>\n
- Why do this now? Why not wait a few months or not do it at all?<\/li>\n
- Is there an existing solution for this?<\/li>\n
- Can we achieve the same or a similar result in a different way?<\/li>\n<\/ul>\n\n
As well as knowing how to do something, it's important to know why it needs to be done.<\/p>\n\n ",
- "summary": null
- }
- ],
- "feeds_item": [
- {
- "imported": "2025-04-21T01:21:31+00:00",
- "guid": null,
- "hash": "f0c3d6e951782cfb763d893c57d2dced",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.02bd7b93-43c7-453f-8af9-0be875b27f82.json b/content/node.02bd7b93-43c7-453f-8af9-0be875b27f82.json
new file mode 100644
index 000000000..3a6b0c106
--- /dev/null
+++ b/content/node.02bd7b93-43c7-453f-8af9-0be875b27f82.json
@@ -0,0 +1,100 @@
+{
+ "uuid": [
+ {
+ "value": "02bd7b93-43c7-453f-8af9-0be875b27f82"
+ }
+ ],
+ "langcode": [
+ {
+ "value": "en"
+ }
+ ],
+ "type": [
+ {
+ "target_id": "daily_email",
+ "target_type": "node_type",
+ "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
+ }
+ ],
+ "revision_timestamp": [
+ {
+ "value": "2025-05-11T09:00:10+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": "Proof of concept"
+ }
+ ],
+ "created": [
+ {
+ "value": "2024-06-20T00:00:00+00:00"
+ }
+ ],
+ "changed": [
+ {
+ "value": "2025-05-11T09:00:10+00:00"
+ }
+ ],
+ "promote": [
+ {
+ "value": false
+ }
+ ],
+ "sticky": [
+ {
+ "value": false
+ }
+ ],
+ "default_langcode": [
+ {
+ "value": true
+ }
+ ],
+ "revision_translation_affected": [
+ {
+ "value": true
+ }
+ ],
+ "path": [
+ {
+ "alias": "\/daily\/2024\/06\/20\/proof-of-concept",
+ "langcode": "en"
+ }
+ ],
+ "body": [
+ {
+ "value": "\n
How do you validate an idea from a client or stakeholder?<\/p>\n\n
Unlike a minimum viable product, which is the smallest amount of functionality for a feature to be released, a proof of concept is an initial investigation into whether the idea is viable.<\/p>\n\n
What's the least amount of development you can do to prove the concept?<\/p>\n\n
Can you create something using a smaller data set or with simplified functionality?<\/p>\n\n
What can you build within a minimal timeframe so, if the idea isn't used, too much time wasn't invested in it, but still verifies it?<\/p>\n\n
Do you need to write any code or do any development at all?<\/p>\n\n
All we need to do is find out if the concept could work.<\/p>\n\n ",
+ "format": "full_html",
+ "processed": "\n
How do you validate an idea from a client or stakeholder?<\/p>\n\n
Unlike a minimum viable product, which is the smallest amount of functionality for a feature to be released, a proof of concept is an initial investigation into whether the idea is viable.<\/p>\n\n
What's the least amount of development you can do to prove the concept?<\/p>\n\n
Can you create something using a smaller data set or with simplified functionality?<\/p>\n\n
What can you build within a minimal timeframe so, if the idea isn't used, too much time wasn't invested in it, but still verifies it?<\/p>\n\n
Do you need to write any code or do any development at all?<\/p>\n\n
All we need to do is find out if the concept could work.<\/p>\n\n ",
+ "summary": null
+ }
+ ],
+ "feeds_item": [
+ {
+ "imported": "2025-05-11T09:00:10+00:00",
+ "guid": null,
+ "hash": "f671ea961bdda4e275277b04dc159c79",
+ "target_type": "feeds_feed",
+ "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
+ }
+ ]
+}
\ No newline at end of file
diff --git a/content/node.02c9e148-b98f-42ae-80f1-d19a6d3fcfb2.json b/content/node.02c9e148-b98f-42ae-80f1-d19a6d3fcfb2.json
new file mode 100644
index 000000000..4cb71ab3d
--- /dev/null
+++ b/content/node.02c9e148-b98f-42ae-80f1-d19a6d3fcfb2.json
@@ -0,0 +1,100 @@
+{
+ "uuid": [
+ {
+ "value": "02c9e148-b98f-42ae-80f1-d19a6d3fcfb2"
+ }
+ ],
+ "langcode": [
+ {
+ "value": "en"
+ }
+ ],
+ "type": [
+ {
+ "target_id": "daily_email",
+ "target_type": "node_type",
+ "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
+ }
+ ],
+ "revision_timestamp": [
+ {
+ "value": "2025-05-11T09:00:18+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": "Types are optional"
+ }
+ ],
+ "created": [
+ {
+ "value": "2024-03-06T00:00:00+00:00"
+ }
+ ],
+ "changed": [
+ {
+ "value": "2025-05-11T09:00:18+00:00"
+ }
+ ],
+ "promote": [
+ {
+ "value": false
+ }
+ ],
+ "sticky": [
+ {
+ "value": false
+ }
+ ],
+ "default_langcode": [
+ {
+ "value": true
+ }
+ ],
+ "revision_translation_affected": [
+ {
+ "value": true
+ }
+ ],
+ "path": [
+ {
+ "alias": "\/daily\/2024\/03\/06\/types-are-optional",
+ "langcode": "en"
+ }
+ ],
+ "body": [
+ {
+ "value": "\n
The main programming languages I write are PHP and JavaScript.<\/p>\n\n
Both offer types where, as well as declaring a parameter or property, you can define what type it is - whether it's a string, array, boolean, etc.<\/p>\n\n
Adding types is optional.<\/p>\n\n
You don't need to add types to your PHP code, and you can choose to write plain JavaScript instead of TypeScript.<\/p>\n\n
Some people prefer simpler or cleaner code or less \"visual debt\".<\/p>\n\n
I like the extra clarity that types add.<\/p>\n\n
I like to be able to read some code and immediately know what types things should be.<\/p>\n\n
I like the clearer errors and messages if a different type is given than was expected.<\/p>\n\n
Tools like PHPStan know more about my code and give better recommendations than if I don't add types.<\/p>\n\n
I like the better autocompletion I get when writing code that has types.<\/p>\n\n
I like types, but I also like the flexibility of whether or not to add them and for Developers and development teams to make their own decisions based on their preferences.<\/p>\n\n ",
+ "format": "full_html",
+ "processed": "\n
The main programming languages I write are PHP and JavaScript.<\/p>\n\n
Both offer types where, as well as declaring a parameter or property, you can define what type it is - whether it's a string, array, boolean, etc.<\/p>\n\n
Adding types is optional.<\/p>\n\n
You don't need to add types to your PHP code, and you can choose to write plain JavaScript instead of TypeScript.<\/p>\n\n
Some people prefer simpler or cleaner code or less \"visual debt\".<\/p>\n\n
I like the extra clarity that types add.<\/p>\n\n
I like to be able to read some code and immediately know what types things should be.<\/p>\n\n
I like the clearer errors and messages if a different type is given than was expected.<\/p>\n\n
Tools like PHPStan know more about my code and give better recommendations than if I don't add types.<\/p>\n\n
I like the better autocompletion I get when writing code that has types.<\/p>\n\n
I like types, but I also like the flexibility of whether or not to add them and for Developers and development teams to make their own decisions based on their preferences.<\/p>\n\n ",
+ "summary": null
+ }
+ ],
+ "feeds_item": [
+ {
+ "imported": "2025-05-11T09:00:18+00:00",
+ "guid": null,
+ "hash": "c50e363614371738c421f8a32ee763f3",
+ "target_type": "feeds_feed",
+ "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
+ }
+ ]
+}
\ No newline at end of file
diff --git a/content/node.02db45dc-db1a-4d95-a449-6fe4c7884c3e.json b/content/node.02db45dc-db1a-4d95-a449-6fe4c7884c3e.json
deleted file mode 100644
index 262936aab..000000000
--- a/content/node.02db45dc-db1a-4d95-a449-6fe4c7884c3e.json
+++ /dev/null
@@ -1,100 +0,0 @@
-{
- "uuid": [
- {
- "value": "02db45dc-db1a-4d95-a449-6fe4c7884c3e"
- }
- ],
- "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:38+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": "Don't put business logic in templates"
- }
- ],
- "created": [
- {
- "value": "2024-01-10T00:00:00+00:00"
- }
- ],
- "changed": [
- {
- "value": "2025-04-21T01:21:38+00:00"
- }
- ],
- "promote": [
- {
- "value": false
- }
- ],
- "sticky": [
- {
- "value": false
- }
- ],
- "default_langcode": [
- {
- "value": true
- }
- ],
- "revision_translation_affected": [
- {
- "value": true
- }
- ],
- "path": [
- {
- "alias": "\/daily\/2024\/01\/10\/dont-put-business-logic-in-templates",
- "langcode": "en"
- }
- ],
- "body": [
- {
- "value": "\n
Here is some code from my website:<\/p>\n\n
![\"A](\"https:\/\/www.oliverdavies.uk\/assets\/images\/talk-count-code.png\")
<\/p>\n\n
If you want, you can also view it on GitHub<\/a>.<\/p>\n\nIt is business logic responsible for counting the number of talks I've given at different events so I can display it on my Talks page.<\/p>\n\n
It starts at zero, loops over each talk, and increments the talk count if the event is the current day or a past date.<\/p>\n\n
It's only used in a single place, so the same logic isn't duplicated elsewhere.<\/p>\n\n
But it's in the page's Twig template.<\/p>\n\n
It has no test coverage.<\/p>\n\n
If I need to change or refactor it, I'd need to test it again manually.<\/p>\n\n
Don't do this.<\/p>\n\n
So, what should I do?<\/h2>\n\n
It's OK to put simple presentational logic, such as looping over a list or whether to show or hide a value within a template, but not complex business logic.<\/p>\n\n
Business logic should be separated and executed elsewhere. The values should be passed to the template to be rendered.<\/p>\n\n
This makes the business logic easier to test as you can test the logic itself and determine the value passed to the template is correct without being concerned about the templating engine.<\/p>\n\n
In an application, you may need to output a value to a template and a terminal. You'd have one source of truth, such as a Service, Action or Command class that calculates the value before passing it to the appropriate output.<\/p>\n\n
Once the logic is separated, you only need to test it once.<\/p>\n\n
Here's the thing<\/h2>\n\n
In a previous version of my website, I did this by creating a custom Twig function.<\/p>\n\n
It was as simple as adding <\/code> to the template.<\/p>\n\nAll the logic was moved from the template to my custom extension.<\/p>\n\n
The logic was separated.<\/p>\n\n
It had tests.<\/p>\n\n
This is the approach I'd take to achieve the same result for a client application.<\/p>\n\n
For a client, I want to run a test suite and be confident my logic works as expected - now and in the future.<\/p>\n\n
For myself, and for calculating something simple, this is fine.<\/p>\n\n ",
- "format": "full_html",
- "processed": "\n
Here is some code from my website:<\/p>\n\n
<\/p>\n\n
If you want, you can also view it on GitHub<\/a>.<\/p>\n\nIt is business logic responsible for counting the number of talks I've given at different events so I can display it on my Talks page.<\/p>\n\n
It starts at zero, loops over each talk, and increments the talk count if the event is the current day or a past date.<\/p>\n\n
It's only used in a single place, so the same logic isn't duplicated elsewhere.<\/p>\n\n
But it's in the page's Twig template.<\/p>\n\n
It has no test coverage.<\/p>\n\n
If I need to change or refactor it, I'd need to test it again manually.<\/p>\n\n
Don't do this.<\/p>\n\n
So, what should I do?<\/h2>\n\n
It's OK to put simple presentational logic, such as looping over a list or whether to show or hide a value within a template, but not complex business logic.<\/p>\n\n
Business logic should be separated and executed elsewhere. The values should be passed to the template to be rendered.<\/p>\n\n
This makes the business logic easier to test as you can test the logic itself and determine the value passed to the template is correct without being concerned about the templating engine.<\/p>\n\n
In an application, you may need to output a value to a template and a terminal. You'd have one source of truth, such as a Service, Action or Command class that calculates the value before passing it to the appropriate output.<\/p>\n\n
Once the logic is separated, you only need to test it once.<\/p>\n\n
Here's the thing<\/h2>\n\n
In a previous version of my website, I did this by creating a custom Twig function.<\/p>\n\n
It was as simple as adding <\/code> to the template.<\/p>\n\nAll the logic was moved from the template to my custom extension.<\/p>\n\n
The logic was separated.<\/p>\n\n
It had tests.<\/p>\n\n
This is the approach I'd take to achieve the same result for a client application.<\/p>\n\n
For a client, I want to run a test suite and be confident my logic works as expected - now and in the future.<\/p>\n\n
For myself, and for calculating something simple, this is fine.<\/p>\n\n ",
- "summary": null
- }
- ],
- "feeds_item": [
- {
- "imported": "2025-04-21T01:21:38+00:00",
- "guid": null,
- "hash": "a75b22468e6abeb329819fa5a65c2bc1",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.02eee27f-311e-45da-b022-0deaf156a6f0.json b/content/node.02eee27f-311e-45da-b022-0deaf156a6f0.json
deleted file mode 100644
index 90c39c080..000000000
--- a/content/node.02eee27f-311e-45da-b022-0deaf156a6f0.json
+++ /dev/null
@@ -1,100 +0,0 @@
-{
- "uuid": [
- {
- "value": "02eee27f-311e-45da-b022-0deaf156a6f0"
- }
- ],
- "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:21+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": "Who's Travis?"
- }
- ],
- "created": [
- {
- "value": "2025-01-23T00:00:00+00:00"
- }
- ],
- "changed": [
- {
- "value": "2025-04-21T01:21:21+00:00"
- }
- ],
- "promote": [
- {
- "value": false
- }
- ],
- "sticky": [
- {
- "value": false
- }
- ],
- "default_langcode": [
- {
- "value": true
- }
- ],
- "revision_translation_affected": [
- {
- "value": true
- }
- ],
- "path": [
- {
- "alias": "\/daily\/2025\/01\/23\/travis",
- "langcode": "en"
- }
- ],
- "body": [
- {
- "value": "\n
I remember seeing a talk or listening to a podcast during which they mentioned Travis, as in the CI pipeline tool, and some of the things they were using it for.<\/p>\n\n
They also said that their client thought Travis was a person on their team.<\/p>\n\n
In some ways, having a CI pipeline performing automated checks and tests is like having another team member.<\/p>\n\n
Instead of waiting for a person to manually check code styles, run tests and spot potential bugs, why not automate them and run them in the CI pipeline every time code changes are pushed?<\/p>\n\n
You'll get results sooner than waiting for a person do check the code by hand and, arguably, more consistent results.<\/p>\n\n
Then, if you do peer code reviews, you know the basics are already done and the reviewer can focus on other things.<\/p>\n\n ",
- "format": "full_html",
- "processed": "\n
I remember seeing a talk or listening to a podcast during which they mentioned Travis, as in the CI pipeline tool, and some of the things they were using it for.<\/p>\n\n
They also said that their client thought Travis was a person on their team.<\/p>\n\n
In some ways, having a CI pipeline performing automated checks and tests is like having another team member.<\/p>\n\n
Instead of waiting for a person to manually check code styles, run tests and spot potential bugs, why not automate them and run them in the CI pipeline every time code changes are pushed?<\/p>\n\n
You'll get results sooner than waiting for a person do check the code by hand and, arguably, more consistent results.<\/p>\n\n
Then, if you do peer code reviews, you know the basics are already done and the reviewer can focus on other things.<\/p>\n\n ",
- "summary": null
- }
- ],
- "feeds_item": [
- {
- "imported": "2025-04-21T01:21:21+00:00",
- "guid": null,
- "hash": "58c9da441a16db434c006de482ddb439",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.0300b4ea-e71b-4f9c-b4f2-f04f98e92d6c.json b/content/node.0300b4ea-e71b-4f9c-b4f2-f04f98e92d6c.json
new file mode 100644
index 000000000..331f957be
--- /dev/null
+++ b/content/node.0300b4ea-e71b-4f9c-b4f2-f04f98e92d6c.json
@@ -0,0 +1,100 @@
+{
+ "uuid": [
+ {
+ "value": "0300b4ea-e71b-4f9c-b4f2-f04f98e92d6c"
+ }
+ ],
+ "langcode": [
+ {
+ "value": "en"
+ }
+ ],
+ "type": [
+ {
+ "target_id": "daily_email",
+ "target_type": "node_type",
+ "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
+ }
+ ],
+ "revision_timestamp": [
+ {
+ "value": "2025-05-11T09:00:28+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": "Why you should contribute to open-source software\n"
+ }
+ ],
+ "created": [
+ {
+ "value": "2023-11-04T00:00:00+00:00"
+ }
+ ],
+ "changed": [
+ {
+ "value": "2025-05-11T09:00:28+00:00"
+ }
+ ],
+ "promote": [
+ {
+ "value": false
+ }
+ ],
+ "sticky": [
+ {
+ "value": false
+ }
+ ],
+ "default_langcode": [
+ {
+ "value": true
+ }
+ ],
+ "revision_translation_affected": [
+ {
+ "value": true
+ }
+ ],
+ "path": [
+ {
+ "alias": "\/daily\/2023\/11\/04\/why-you-should-contribute-to-open-source-software",
+ "langcode": "en"
+ }
+ ],
+ "body": [
+ {
+ "value": "\n
Yesterday's email<\/a> explained why your company should contribute to open-source software, but why should you contribute as an individual?<\/p>\n\nMost of the same reasons apply, such as gaining experience and improved knowledge from contributing.<\/p>\n\n
As an individual, you can build your own reputation and personal brand.<\/p>\n\n
You'll get exposure from contributions and involvement with initiatives, such as the Drupal admin UI improvements and other core initiatives, which look great on your CV and LinkedIn profile.<\/p>\n\n
This could lead to better career opportunities and potential projects.<\/p>\n\n
I've had paid development work directly from my open-source code contributions, as well as public speaking and event organising, so I can vouch for this.<\/p>\n\n
Like companies, if you make money from open-source software - either a salary or from paid projects or courses - it's in your interest to contribute so the software you use is maintained and improved so it's the best it can be.<\/p>\n\n ",
+ "format": "full_html",
+ "processed": "\n
Yesterday's email<\/a> explained why your company should contribute to open-source software, but why should you contribute as an individual?<\/p>\n\nMost of the same reasons apply, such as gaining experience and improved knowledge from contributing.<\/p>\n\n
As an individual, you can build your own reputation and personal brand.<\/p>\n\n
You'll get exposure from contributions and involvement with initiatives, such as the Drupal admin UI improvements and other core initiatives, which look great on your CV and LinkedIn profile.<\/p>\n\n
This could lead to better career opportunities and potential projects.<\/p>\n\n
I've had paid development work directly from my open-source code contributions, as well as public speaking and event organising, so I can vouch for this.<\/p>\n\n
Like companies, if you make money from open-source software - either a salary or from paid projects or courses - it's in your interest to contribute so the software you use is maintained and improved so it's the best it can be.<\/p>\n\n ",
+ "summary": null
+ }
+ ],
+ "feeds_item": [
+ {
+ "imported": "2025-05-11T09:00:28+00:00",
+ "guid": null,
+ "hash": "0f37079942ad6ce63ae32e8ea7c57c79",
+ "target_type": "feeds_feed",
+ "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
+ }
+ ]
+}
\ No newline at end of file
diff --git a/content/node.0316dfcf-b709-47e1-9622-9355b5ece6d9.json b/content/node.0316dfcf-b709-47e1-9622-9355b5ece6d9.json
new file mode 100644
index 000000000..d79c7b879
--- /dev/null
+++ b/content/node.0316dfcf-b709-47e1-9622-9355b5ece6d9.json
@@ -0,0 +1,100 @@
+{
+ "uuid": [
+ {
+ "value": "0316dfcf-b709-47e1-9622-9355b5ece6d9"
+ }
+ ],
+ "langcode": [
+ {
+ "value": "en"
+ }
+ ],
+ "type": [
+ {
+ "target_id": "daily_email",
+ "target_type": "node_type",
+ "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
+ }
+ ],
+ "revision_timestamp": [
+ {
+ "value": "2025-05-11T09:00:00+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": "You can deploy on Fridays"
+ }
+ ],
+ "created": [
+ {
+ "value": "2025-03-11T00:00:00+00:00"
+ }
+ ],
+ "changed": [
+ {
+ "value": "2025-05-11T09:00:00+00:00"
+ }
+ ],
+ "promote": [
+ {
+ "value": false
+ }
+ ],
+ "sticky": [
+ {
+ "value": false
+ }
+ ],
+ "default_langcode": [
+ {
+ "value": true
+ }
+ ],
+ "revision_translation_affected": [
+ {
+ "value": true
+ }
+ ],
+ "path": [
+ {
+ "alias": "\/daily\/2025\/03\/11\/friday",
+ "langcode": "en"
+ }
+ ],
+ "body": [
+ {
+ "value": "\n
Does your team have a \"No deploy Friday\" policy?<\/p>\n\n
What about not deploying after a certain time in the afternoon?<\/p>\n\n
These approaches are attempts to minimise risk when deploying.<\/p>\n\n
If there is an issue, will someone be available during the evening or weekend to resolve it?<\/p>\n\n
To me, this indicates the deployment process is too complicated, possibly due to a lack of automation, or deployments aren't happening frequently enough.<\/p>\n\n
Having a robust and passing CI pipeline<\/a> that runs automated checks and tests is crucial to know the code is deployable.<\/p>\n\nFeature flags are a great way<\/a> to separate deploying code from releasing changes to users, which means you don't need to avoid pushing some code until the change is complete. It can be done incrementally and released over several deployments.<\/p>\n\nToo much time between deployments is a smell.<\/p>\n\n
The more time there is between a deployment and the larger the changeset, the riskier the deployment will be.<\/p>\n\n
There is more to go wrong and it'll be harder to diagnose and resolve any issues.<\/p>\n\n
I always advocate for many smaller releases than larger less frequent ones.<\/p>\n\n
Ideally, a production release every day - even if the changes are small or everything is hidden behind feature flags.<\/p>\n\n
Deploying on Friday is easy if you last deployed on Thursday.<\/p>\n\n ",
+ "format": "full_html",
+ "processed": "\n
Does your team have a \"No deploy Friday\" policy?<\/p>\n\n
What about not deploying after a certain time in the afternoon?<\/p>\n\n
These approaches are attempts to minimise risk when deploying.<\/p>\n\n
If there is an issue, will someone be available during the evening or weekend to resolve it?<\/p>\n\n
To me, this indicates the deployment process is too complicated, possibly due to a lack of automation, or deployments aren't happening frequently enough.<\/p>\n\n
Having a robust and passing CI pipeline<\/a> that runs automated checks and tests is crucial to know the code is deployable.<\/p>\n\nFeature flags are a great way<\/a> to separate deploying code from releasing changes to users, which means you don't need to avoid pushing some code until the change is complete. It can be done incrementally and released over several deployments.<\/p>\n\nToo much time between deployments is a smell.<\/p>\n\n
The more time there is between a deployment and the larger the changeset, the riskier the deployment will be.<\/p>\n\n
There is more to go wrong and it'll be harder to diagnose and resolve any issues.<\/p>\n\n
I always advocate for many smaller releases than larger less frequent ones.<\/p>\n\n
Ideally, a production release every day - even if the changes are small or everything is hidden behind feature flags.<\/p>\n\n
Deploying on Friday is easy if you last deployed on Thursday.<\/p>\n\n ",
+ "summary": null
+ }
+ ],
+ "feeds_item": [
+ {
+ "imported": "2025-05-11T09:00:00+00:00",
+ "guid": null,
+ "hash": "021827be7bf3f083020a0f2ff11066d8",
+ "target_type": "feeds_feed",
+ "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
+ }
+ ]
+}
\ No newline at end of file
diff --git a/content/node.0318e249-a9a8-476f-9bd4-432544369917.json b/content/node.0318e249-a9a8-476f-9bd4-432544369917.json
new file mode 100644
index 000000000..76df512ee
--- /dev/null
+++ b/content/node.0318e249-a9a8-476f-9bd4-432544369917.json
@@ -0,0 +1,100 @@
+{
+ "uuid": [
+ {
+ "value": "0318e249-a9a8-476f-9bd4-432544369917"
+ }
+ ],
+ "langcode": [
+ {
+ "value": "en"
+ }
+ ],
+ "type": [
+ {
+ "target_id": "daily_email",
+ "target_type": "node_type",
+ "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
+ }
+ ],
+ "revision_timestamp": [
+ {
+ "value": "2025-05-11T09:00:01+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": "To patch or not to patch"
+ }
+ ],
+ "created": [
+ {
+ "value": "2025-02-24T00:00:00+00:00"
+ }
+ ],
+ "changed": [
+ {
+ "value": "2025-05-11T09:00:01+00:00"
+ }
+ ],
+ "promote": [
+ {
+ "value": false
+ }
+ ],
+ "sticky": [
+ {
+ "value": false
+ }
+ ],
+ "default_langcode": [
+ {
+ "value": true
+ }
+ ],
+ "revision_translation_affected": [
+ {
+ "value": true
+ }
+ ],
+ "path": [
+ {
+ "alias": "\/daily\/2025\/02\/24\/patch",
+ "langcode": "en"
+ }
+ ],
+ "body": [
+ {
+ "value": "\n
Applying patch files<\/a> is a common way to customise and extend open source software, and how we used to submit changes to Drupal before issue forks and merge requests were added to Drupal.org.<\/p>\n\nSome software, such as dwm and st from suckless.org are released as minimal versions that you patch to add features to.<\/p>\n\n
If you find a line of code that you want to add, edit or delete, a patch file describes the changes so you can re-apply them whenever the source file changes.<\/p>\n\n
Patching offers unlimited customisation and flexibility.<\/p>\n\n
Whatever changes you want to make, you can.<\/p>\n\n
The downside is you need to maintain any patches you've written.<\/p>\n\n
If a change is made that causes your patch to no longer apply, you'll need to update the patch.<\/p>\n\n
There are some patches I commonly apply to Drupal projects, but I'll try to either contribute the changes back to the Drupal so I no longer need the patch or make the change in a custom module.<\/p>\n\n
Sometimes, though, patching is the only option<\/a>.<\/p>\n\n ",
+ "format": "full_html",
+ "processed": "\n Applying patch files<\/a> is a common way to customise and extend open source software, and how we used to submit changes to Drupal before issue forks and merge requests were added to Drupal.org.<\/p>\n\nSome software, such as dwm and st from suckless.org are released as minimal versions that you patch to add features to.<\/p>\n\n
If you find a line of code that you want to add, edit or delete, a patch file describes the changes so you can re-apply them whenever the source file changes.<\/p>\n\n
Patching offers unlimited customisation and flexibility.<\/p>\n\n
Whatever changes you want to make, you can.<\/p>\n\n
The downside is you need to maintain any patches you've written.<\/p>\n\n
If a change is made that causes your patch to no longer apply, you'll need to update the patch.<\/p>\n\n
There are some patches I commonly apply to Drupal projects, but I'll try to either contribute the changes back to the Drupal so I no longer need the patch or make the change in a custom module.<\/p>\n\n
Sometimes, though, patching is the only option<\/a>.<\/p>\n\n ",
+ "summary": null
+ }
+ ],
+ "feeds_item": [
+ {
+ "imported": "2025-05-11T09:00:01+00:00",
+ "guid": null,
+ "hash": "e1882c079f5b933697958ec2ac91a1b7",
+ "target_type": "feeds_feed",
+ "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
+ }
+ ]
+}
\ No newline at end of file
diff --git a/content/node.031b38e7-5589-4f0a-9eaf-18621a4b0ea3.json b/content/node.031b38e7-5589-4f0a-9eaf-18621a4b0ea3.json
deleted file mode 100644
index f821ea7ec..000000000
--- a/content/node.031b38e7-5589-4f0a-9eaf-18621a4b0ea3.json
+++ /dev/null
@@ -1,100 +0,0 @@
-{
- "uuid": [
- {
- "value": "031b38e7-5589-4f0a-9eaf-18621a4b0ea3"
- }
- ],
- "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:42+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": "PHPUnit does more than unit testing\n"
- }
- ],
- "created": [
- {
- "value": "2023-11-13T00:00:00+00:00"
- }
- ],
- "changed": [
- {
- "value": "2025-04-21T01:21:42+00:00"
- }
- ],
- "promote": [
- {
- "value": false
- }
- ],
- "sticky": [
- {
- "value": false
- }
- ],
- "default_langcode": [
- {
- "value": true
- }
- ],
- "revision_translation_affected": [
- {
- "value": true
- }
- ],
- "path": [
- {
- "alias": "\/daily\/2023\/11\/13\/phpunit-does-more-than-unit-testing",
- "langcode": "en"
- }
- ],
- "body": [
- {
- "value": "\n As the name suggests, PHPUnit<\/a> is a unit testing framework for PHP.<\/p>\n\nIt's the defacto PHP testing framework used by the major PHP projects, such as Drupal, Symfony, Laravel.<\/p>\n\n
But unit testing isn't all that PHPUnit can do.<\/p>\n\n
These frameworks extend PHPUnit to give it more functionality.<\/p>\n\n
Drupal allows you to run functional\/browser tests to make requests to pages, check the response codes and content, as well as integration\/kernel tests to test real services instead of relying on mocking within unit tests.<\/p>\n\n
Symfony does the same with its web and kernel test cases.<\/p>\n\n
Here's the thing<\/h2>\n\n
If you use a framework and want to more than unit testing, intsead of including another testing framework, try using some of the PHPUnit extensions that are provided by the framework.<\/p>\n\n ",
- "format": "full_html",
- "processed": "\n
As the name suggests, PHPUnit<\/a> is a unit testing framework for PHP.<\/p>\n\nIt's the defacto PHP testing framework used by the major PHP projects, such as Drupal, Symfony, Laravel.<\/p>\n\n
But unit testing isn't all that PHPUnit can do.<\/p>\n\n
These frameworks extend PHPUnit to give it more functionality.<\/p>\n\n
Drupal allows you to run functional\/browser tests to make requests to pages, check the response codes and content, as well as integration\/kernel tests to test real services instead of relying on mocking within unit tests.<\/p>\n\n
Symfony does the same with its web and kernel test cases.<\/p>\n\n
Here's the thing<\/h2>\n\n
If you use a framework and want to more than unit testing, intsead of including another testing framework, try using some of the PHPUnit extensions that are provided by the framework.<\/p>\n\n ",
- "summary": null
- }
- ],
- "feeds_item": [
- {
- "imported": "2025-04-21T01:21:42+00:00",
- "guid": null,
- "hash": "ebb678e6bfb989f0b14c1f494c92a1af",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.033f0b46-69f9-4ea0-9706-d930e67dd5d8.json b/content/node.033f0b46-69f9-4ea0-9706-d930e67dd5d8.json
new file mode 100644
index 000000000..4a42b64bb
--- /dev/null
+++ b/content/node.033f0b46-69f9-4ea0-9706-d930e67dd5d8.json
@@ -0,0 +1,100 @@
+{
+ "uuid": [
+ {
+ "value": "033f0b46-69f9-4ea0-9706-d930e67dd5d8"
+ }
+ ],
+ "langcode": [
+ {
+ "value": "en"
+ }
+ ],
+ "type": [
+ {
+ "target_id": "daily_email",
+ "target_type": "node_type",
+ "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
+ }
+ ],
+ "revision_timestamp": [
+ {
+ "value": "2025-05-11T09:00:08+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": "Merging unrelated histories"
+ }
+ ],
+ "created": [
+ {
+ "value": "2024-08-02T00:00:00+00:00"
+ }
+ ],
+ "changed": [
+ {
+ "value": "2025-05-11T09:00:08+00:00"
+ }
+ ],
+ "promote": [
+ {
+ "value": false
+ }
+ ],
+ "sticky": [
+ {
+ "value": false
+ }
+ ],
+ "default_langcode": [
+ {
+ "value": true
+ }
+ ],
+ "revision_translation_affected": [
+ {
+ "value": true
+ }
+ ],
+ "path": [
+ {
+ "alias": "\/daily\/2024\/08\/02\/merging-unrelated-histories",
+ "langcode": "en"
+ }
+ ],
+ "body": [
+ {
+ "value": "\n
My website is built with Sculpin - a static site generator written in PHP.<\/p>\n\n
It uses a some of the same Symfony components as Drupal, uses Twig for templating and YAML for configuration, and has similar features like content types and taxonomies for structuring content.<\/p>\n\n
When I first created my website it was on Drupal 6 and upgraded to Drupal 7 before I started to take an interest in static site generators and later using Jekyll, Sculpin and Astro (and Sculpin, again).<\/p>\n\n
I enjoyed learning Sculpin and took it as an opportunity to learn Twig before Drupal 8, which I spoke about in the first Sculpin talk I gave<\/a>, at DrupalCamp North in July 2015.<\/p>\n\nI had three Git repositories, the current Sculpin one, the Astro version, and the original Sculpin version with its first commit in March 2015 - a few months before DrupalCamp North.<\/p>\n\n
Static site generators keep the files in text files intead of a database, so I was wondering if it was possible to merge the repositories together and combine the information whilst keeping the same commit history so existing tags and contribtions would still apply to the original commits.<\/p>\n\n
In short, I was able to do it by adding the old repositories as additional remotes and using the --allow-unrelated-histories<\/code> option for git merge<\/a>.<\/p>\n\nAfter fixing some minor merge conflicts, everything was merged successfully and I have [one repository containing 5,272 all commits][2], going back to 2015.<\/p>\n\n
This makes it older than my dotfiles repository<\/a>, which I started in July 2015.<\/p>\n\nSimilar to