Subscribe to my daily newsletter for software professionals on software development and delivery, Drupal, DevOps, community, and open-source.<\/p>\n", - "summary": "" - } - ] -} \ No newline at end of file diff --git a/content/block_content.262bcabc-61d8-4b67-b4ab-ba39d86db38d.yml b/content/block_content.262bcabc-61d8-4b67-b4ab-ba39d86db38d.yml new file mode 100644 index 000000000..fda9d3cf3 --- /dev/null +++ b/content/block_content.262bcabc-61d8-4b67-b4ab-ba39d86db38d.yml @@ -0,0 +1,30 @@ +uuid: + - value: 262bcabc-61d8-4b67-b4ab-ba39d86db38d +langcode: + - value: en +type: + - target_id: basic + target_type: block_content_type + target_uuid: 2646e684-c917-4dd0-b502-1a73b9c10131 +revision_created: + - value: '2025-07-03T15:10:16+00:00' +revision_user: { } +status: + - value: true +info: + - value: 'Introduction text' +changed: + - value: '2025-07-03T15:10:16+00:00' +reusable: + - value: false +default_langcode: + - value: true +revision_translation_affected: + - value: true +body: + - value: 'Subscribe to my daily newsletter for software professionals on software development and delivery, Drupal, DevOps, community, and open-source.' + format: markdown + processed: | +
Subscribe to my daily newsletter for software professionals on software development and delivery, Drupal, DevOps, community, and open-source.
+ summary: '' +field_text_alignment: { } diff --git a/content/block_content.f451cc6b-1555-4bb2-ad3c-6d1bb4ee6bf5.json b/content/block_content.f451cc6b-1555-4bb2-ad3c-6d1bb4ee6bf5.json deleted file mode 100644 index ad50ef975..000000000 --- a/content/block_content.f451cc6b-1555-4bb2-ad3c-6d1bb4ee6bf5.json +++ /dev/null @@ -1,68 +0,0 @@ -{ - "uuid": [ - { - "value": "f451cc6b-1555-4bb2-ad3c-6d1bb4ee6bf5" - } - ], - "langcode": [ - { - "value": "en" - } - ], - "type": [ - { - "target_id": "basic", - "target_type": "block_content_type", - "target_uuid": "2646e684-c917-4dd0-b502-1a73b9c10131" - } - ], - "revision_created": [ - { - "value": "2025-07-03T15:11:02+00:00" - } - ], - "revision_user": [], - "status": [ - { - "value": true - } - ], - "info": [ - { - "value": "Browse the archive" - } - ], - "changed": [ - { - "value": "2025-07-03T17:08:44+00:00" - } - ], - "reusable": [ - { - "value": false - } - ], - "default_langcode": [ - { - "value": true - } - ], - "revision_translation_affected": [ - { - "value": true - } - ], - "body": [ - { - "value": "Not sure? [Browse the archive \u2192](\/archive)", - "format": "markdown", - "processed": "Not sure? Browse the archive \u2192<\/a><\/p>\n",
- "summary": ""
- }
- ],
- "field_text_alignment": [
- {
- "value": "centre"
- }
- ]
-}
\ No newline at end of file
diff --git a/content/block_content.f451cc6b-1555-4bb2-ad3c-6d1bb4ee6bf5.yml b/content/block_content.f451cc6b-1555-4bb2-ad3c-6d1bb4ee6bf5.yml
new file mode 100644
index 000000000..7fbcf43c6
--- /dev/null
+++ b/content/block_content.f451cc6b-1555-4bb2-ad3c-6d1bb4ee6bf5.yml
@@ -0,0 +1,31 @@
+uuid:
+ - value: f451cc6b-1555-4bb2-ad3c-6d1bb4ee6bf5
+langcode:
+ - value: en
+type:
+ - target_id: basic
+ target_type: block_content_type
+ target_uuid: 2646e684-c917-4dd0-b502-1a73b9c10131
+revision_created:
+ - value: '2025-07-03T15:11:02+00:00'
+revision_user: { }
+status:
+ - value: true
+info:
+ - value: 'Browse the archive'
+changed:
+ - value: '2025-07-03T17:08:44+00:00'
+reusable:
+ - value: false
+default_langcode:
+ - value: true
+revision_translation_affected:
+ - value: true
+body:
+ - value: 'Not sure? [Browse the archive →](/archive)'
+ format: markdown
+ processed: |
+ Not sure? Browse the archive → A common mistake I see with new Developers and Development teams when starting with automated testing is to split development time and testing into separate tasks.<\/p>\n\n They'll say when quoting a client or in an estimation session that the development time will take x hours and writing tests will take y hours.<\/p>\n\n This is something I've always avoided.<\/p>\n\n When broken out this way, it implies the automated tests are optional when they should be an integral part of the development process.<\/p>\n\n They aren't a separate task that can be removed or skipped to save time or money.<\/p>\n\n If I take my car to a garage, I don't ask them how long it will take to repair and how long to test what they've done.<\/p>\n\n I want to know how much the whole task will cost and how long it will take.<\/p>\n\n I assume they automatically test and verify the work they do and follow their industry's standard and best practices.<\/p>\n\n I'm doing the same when developing software.<\/p>\n\n ",
- "format": "full_html",
- "processed": "\n A common mistake I see with new Developers and Development teams when starting with automated testing is to split development time and testing into separate tasks.<\/p>\n\n They'll say when quoting a client or in an estimation session that the development time will take x hours and writing tests will take y hours.<\/p>\n\n This is something I've always avoided.<\/p>\n\n When broken out this way, it implies the automated tests are optional when they should be an integral part of the development process.<\/p>\n\n They aren't a separate task that can be removed or skipped to save time or money.<\/p>\n\n If I take my car to a garage, I don't ask them how long it will take to repair and how long to test what they've done.<\/p>\n\n I want to know how much the whole task will cost and how long it will take.<\/p>\n\n I assume they automatically test and verify the work they do and follow their industry's standard and best practices.<\/p>\n\n I'm doing the same when developing software.<\/p>\n\n ",
- "summary": null
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.0001428e-621c-49ca-83d3-4323ea446f48.yml b/content/node.0001428e-621c-49ca-83d3-4323ea446f48.yml
new file mode 100644
index 000000000..23ae16a7f
--- /dev/null
+++ b/content/node.0001428e-621c-49ca-83d3-4323ea446f48.yml
@@ -0,0 +1,80 @@
+uuid:
+ - value: 0001428e-621c-49ca-83d3-4323ea446f48
+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: "Tests aren't a line item"
+created:
+ - value: '2025-02-23T00: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/23/line-item
+ langcode: en
+body:
+ - value: |
+ A common mistake I see with new Developers and Development teams when starting with automated testing is to split development time and testing into separate tasks. They'll say when quoting a client or in an estimation session that the development time will take x hours and writing tests will take y hours. This is something I've always avoided. When broken out this way, it implies the automated tests are optional when they should be an integral part of the development process. They aren't a separate task that can be removed or skipped to save time or money. If I take my car to a garage, I don't ask them how long it will take to repair and how long to test what they've done. I want to know how much the whole task will cost and how long it will take. I assume they automatically test and verify the work they do and follow their industry's standard and best practices. I'm doing the same when developing software. A common mistake I see with new Developers and Development teams when starting with automated testing is to split development time and testing into separate tasks. They'll say when quoting a client or in an estimation session that the development time will take x hours and writing tests will take y hours. This is something I've always avoided. When broken out this way, it implies the automated tests are optional when they should be an integral part of the development process. They aren't a separate task that can be removed or skipped to save time or money. If I take my car to a garage, I don't ask them how long it will take to repair and how long to test what they've done. I want to know how much the whole task will cost and how long it will take. I assume they automatically test and verify the work they do and follow their industry's standard and best practices. I'm doing the same when developing software. 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 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 This makes me think about the different stages and what each might need to contain.<\/p>\n\n Or I might write it out in the \"Given, When, Then\" format:<\/p>\n\n This 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 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 This makes me think about the different stages and what each might need to contain.<\/p>\n\n Or I might write it out in the \"Given, When, Then\" format:<\/p>\n\n This 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
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.001f3ebb-79dc-43ad-a363-6dc668d06a0c.yml b/content/node.001f3ebb-79dc-43ad-a363-6dc668d06a0c.yml
new file mode 100644
index 000000000..963560313
--- /dev/null
+++ b/content/node.001f3ebb-79dc-43ad-a363-6dc668d06a0c.yml
@@ -0,0 +1,133 @@
+uuid:
+ - value: 001f3ebb-79dc-43ad-a363-6dc668d06a0c
+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: |
+ Structure a new test by writing comments first
+created:
+ - value: '2023-04-26T00: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/26/tdd-structure-a-new-test-by-writing-comments-first
+ langcode: en
+body:
+ - value: |
+ Test cases are usually split into two or three sections - "Arrange, Act, Assert" or "Given, When, Then". 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. Then you perform an action on the subject under test and, finally, assert that the system is in the desired state. 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. To help me get started, I'll sometimes write a test like this with placeholders to separate the test into its separate stages: This makes me think about the different stages and what each might need to contain. Or I might write it out in the "Given, When, Then" format: This takes a little longer to write but feels more familiar if you're used to a behavioural testing framework like Behat. Either way, sometimes, I'll remove the comments once I've written the code around them or leave them to provide additional context. Test cases are usually split into two or three sections - "Arrange, Act, Assert" or "Given, When, Then". 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. Then you perform an action on the subject under test and, finally, assert that the system is in the desired state. 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. To help me get started, I'll sometimes write a test like this with placeholders to separate the test into its separate stages: This makes me think about the different stages and what each might need to contain. Or I might write it out in the "Given, When, Then" format: This takes a little longer to write but feels more familiar if you're used to a behavioural testing framework like Behat. Either way, sometimes, I'll remove the comments once I've written the code around them or leave them to provide additional context. A side effect of using a tool to generate build configuration files<\/a> with templates is the consistency that it introduces.<\/p>\n\n The majority of my projects use a PHP-FPM or PHP CLI container. In my Docker Compose file, the service was mostly named Some projects would use As 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\n The majority of my projects use a PHP-FPM or PHP CLI container. In my Docker Compose file, the service was mostly named Some projects would use As 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
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.00497277-4b40-4d36-a473-8d8e1a187c18.yml b/content/node.00497277-4b40-4d36-a473-8d8e1a187c18.yml
new file mode 100644
index 000000000..38c840cbf
--- /dev/null
+++ b/content/node.00497277-4b40-4d36-a473-8d8e1a187c18.yml
@@ -0,0 +1,69 @@
+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
+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: |
+ A side effect of using a tool to generate build configuration files with templates is the consistency that it introduces. The majority of my projects use a PHP-FPM or PHP CLI container. In my Docker Compose file, the service was mostly named Some projects would use As 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. 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. 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. A side effect of using a tool to generate build configuration files with templates is the consistency that it introduces. The majority of my projects use a PHP-FPM or PHP CLI container. In my Docker Compose file, the service was mostly named Some projects would use As 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. 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. 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. 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
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.00d62e94-80d1-4792-bdea-88a064f6bf65.yml b/content/node.00d62e94-80d1-4792-bdea-88a064f6bf65.yml
new file mode 100644
index 000000000..c9730ae14
--- /dev/null
+++ b/content/node.00d62e94-80d1-4792-bdea-88a064f6bf65.yml
@@ -0,0 +1,64 @@
+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: |
+ Something I see on many Developers' websites and CVs is percentages or levels of how well they know certain tools and frameworks. Things like "80% of PHP" or "Advanced in HTML and CSS". But how do you quantify that? Do people alter their percentages accordingly if a new feature is added to a language or framework? 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. Something I see on many Developers' websites and CVs is percentages or levels of how well they know certain tools and frameworks. Things like "80% of PHP" or "Advanced in HTML and CSS". But how do you quantify that? Do people alter their percentages accordingly if a new feature is added to a language or framework? 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. Here are links to example websites and code repositories I have created for talks, presentations and demonstrations:<\/p> Here are links to example websites and code repositories I have created for talks, presentations and demonstrations:<\/p> Here are links to example websites and code repositories I have created for talks, presentations and demonstrations: Here are links to example websites and code repositories I have created for talks, presentations and demonstrations: 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\n To 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\n I use tools like Nix and devenv<\/a> to create identical and reproducible environments.<\/p>\n\n The 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\n To 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\n I use tools like Nix and devenv<\/a> to create identical and reproducible environments.<\/p>\n\n The 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
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.0100be71-79ef-44ea-922e-e75fcc26ae16.yml b/content/node.0100be71-79ef-44ea-922e-e75fcc26ae16.yml
new file mode 100644
index 000000000..a8046c9d1
--- /dev/null
+++ b/content/node.0100be71-79ef-44ea-922e-e75fcc26ae16.yml
@@ -0,0 +1,88 @@
+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: |
+ A common reason why environments aren't updated and get out of sync is because it's a time-consuming or complex task. The process should be simple to run, quick, reliable and reproducible. It's the same as deploying a change to a staging or production environment. You want the same result on every time on every environment. You want every environment - including local development environments to be as consistent as possible to minimise bugs and errors. To do this, I automate things to make them as simple as possible. I use run files with commands to import databases, perform updates and run pre-update and post-update tasks. I use tools like Nix and devenv to create identical and reproducible environments. The simpler and quicker is it, the more it can and will be done. You can also use automation to perform long or complex tasks outside of working hours such as sanitising and importing large databases. The more you can automate, the better. A common reason why environments aren't updated and get out of sync is because it's a time-consuming or complex task. The process should be simple to run, quick, reliable and reproducible. It's the same as deploying a change to a staging or production environment. You want the same result on every time on every environment. You want every environment - including local development environments to be as consistent as possible to minimise bugs and errors. To do this, I automate things to make them as simple as possible. I use run files with commands to import databases, perform updates and run pre-update and post-update tasks. I use tools like Nix and devenv to create identical and reproducible environments. The simpler and quicker is it, the more it can and will be done. You can also use automation to perform long or complex tasks outside of working hours such as sanitising and importing large databases. The more you can automate, the better. 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
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.01230324-62b5-442b-80e4-09268a31819b.yml b/content/node.01230324-62b5-442b-80e4-09268a31819b.yml
new file mode 100644
index 000000000..4a4d2b200
--- /dev/null
+++ b/content/node.01230324-62b5-442b-80e4-09268a31819b.yml
@@ -0,0 +1,68 @@
+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: |
+ 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). A lot of Developers' first programming language was PHP and maybe used earlier versions of Drupal before moving to another CMS, framework or language. They still remember, though, how things were when they used it and aren't aware of the advancements and improvements that have been made. The PHP language itself has improved significantly in recent versions with new features and much better peformance. 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. 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. 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). A lot of Developers' first programming language was PHP and maybe used earlier versions of Drupal before moving to another CMS, framework or language. They still remember, though, how things were when they used it and aren't aware of the advancements and improvements that have been made. The PHP language itself has improved significantly in recent versions with new features and much better peformance. 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. 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. 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
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.01893784-8f45-4466-8586-17df23e7e4b5.yml b/content/node.01893784-8f45-4466-8586-17df23e7e4b5.yml
new file mode 100644
index 000000000..a064c4e4f
--- /dev/null
+++ b/content/node.01893784-8f45-4466-8586-17df23e7e4b5.yml
@@ -0,0 +1,116 @@
+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: |
+ PHPStan is a static analysis tool for PHP. It finds potential issues in PHP code without needing to run it, so Developers can find and resolve potential issues sooner. I use it on all my projects including existing ones I've inherited. But how can you add a static analysis tool to a codebase without getting a lot of errors from the existing code? PHPStan has different levels of strictness. Level 0 is the least strict and each level adds more rules and strictness, resulting in more errors. Most of the time, people will start by running PHPStan on level 0, fixing any errors and committing the changes. Then repeat the process as many times as needed until you reach the level you want to achieve. I don't think this is the right approach. This could mean that you need to edit the same files multiple times as you work through the levels. There's also a period of time where Developers can still write suboptimal code whilst you work your way up to your desired level. Another approach is to use a feature of PHPStan called the baseline. The baseline is a way of capturing and saving all the existing errors up to the selected level so they are no longer reported. If you did this for an existing project, it would return no errors as everything would be included in the baseline. 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. 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. This I think is a better approach and how I add PHPStan to existing codebases. To learn more about static analysis and PHPStan, listen to episode 22 of the Beyond Blocks podcast with Dave Liddament. PHPStan is a static analysis tool for PHP. It finds potential issues in PHP code without needing to run it, so Developers can find and resolve potential issues sooner. I use it on all my projects including existing ones I've inherited. But how can you add a static analysis tool to a codebase without getting a lot of errors from the existing code? PHPStan has different levels of strictness. Level 0 is the least strict and each level adds more rules and strictness, resulting in more errors. Most of the time, people will start by running PHPStan on level 0, fixing any errors and committing the changes. Then repeat the process as many times as needed until you reach the level you want to achieve. I don't think this is the right approach. This could mean that you need to edit the same files multiple times as you work through the levels. There's also a period of time where Developers can still write suboptimal code whilst you work your way up to your desired level. Another approach is to use a feature of PHPStan called the baseline. The baseline is a way of capturing and saving all the existing errors up to the selected level so they are no longer reported. If you did this for an existing project, it would return no errors as everything would be included in the baseline. 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. 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. This I think is a better approach and how I add PHPStan to existing codebases. To learn more about static analysis and PHPStan, listen to episode 22 of the Beyond Blocks podcast with Dave Liddament. 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 It 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 It 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
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.018bf894-2d3e-4130-b0bd-43450ef5753a.yml b/content/node.018bf894-2d3e-4130-b0bd-43450ef5753a.yml
new file mode 100644
index 000000000..bbf7a81fc
--- /dev/null
+++ b/content/node.018bf894-2d3e-4130-b0bd-43450ef5753a.yml
@@ -0,0 +1,108 @@
+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: |
+ 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. Stylesheets would be written in .scss, .sass or .less files and processed to create the stylesheets that would be used by browsers. But, with the recent improvements to CSS, do we still need these preprocessors? Here's a very small example of some CSS that just works: It looks like a Sass file, but it's native CSS. It has variables (a.k.a. custom properties) and nesting, which I think are the most used features from preprocessors. 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. If I'm not using Tailwind CSS or atomic styles, writing plain CSS files is the approach I'd use. No preprocessors needed. 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. Stylesheets would be written in .scss, .sass or .less files and processed to create the stylesheets that would be used by browsers. But, with the recent improvements to CSS, do we still need these preprocessors? Here's a very small example of some CSS that just works: It looks like a Sass file, but it's native CSS. It has variables (a.k.a. custom properties) and nesting, which I think are the most used features from preprocessors. 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. If I'm not using Tailwind CSS or atomic styles, writing plain CSS files is the approach I'd use. No preprocessors needed. If a module or library has been added to an application, it was done to serve a purpose.<\/p> It must add some required functionality that was asked for earlier in the application's lifecycle.<\/p> It was needed then.<\/p> But it is still needed now?<\/p> Are the original requirements still valid?<\/p> Have they changed or are no longer needed?<\/p> If the code is no longer serving a purpose, it should be removed.<\/p> Common culprits in Drupal projects are the Feeds and Migrate modules, which are used to import data from external sources, such as legacy applications when migrating to Drupal.<\/p> Once the data has been imported and the site is live, the modules are often so longer needed.<\/p> As I said yesterday<\/a>, having less code in your application will make it easier to maintain and upgrade in the future, so keep it as lean and minimal as possible - but this is an ongoing process as requirements change over time. If a module or library has been added to an application, it was done to serve a purpose.<\/p> It must add some required functionality that was asked for earlier in the application's lifecycle.<\/p> It was needed then.<\/p> But it is still needed now?<\/p> Are the original requirements still valid?<\/p> Have they changed or are no longer needed?<\/p> If the code is no longer serving a purpose, it should be removed.<\/p> Common culprits in Drupal projects are the Feeds and Migrate modules, which are used to import data from external sources, such as legacy applications when migrating to Drupal.<\/p> Once the data has been imported and the site is live, the modules are often so longer needed.<\/p> As I said yesterday<\/a>, having less code in your application will make it easier to maintain and upgrade in the future, so keep it as lean and minimal as possible - but this is an ongoing process as requirements change over time. If a module or library has been added to an application, it was done to serve a purpose. It must add some required functionality that was asked for earlier in the application''s lifecycle. It was needed then. But it is still needed now? Are the original requirements still valid? Have they changed or are no longer needed? If the code is no longer serving a purpose, it should be removed. Common culprits in Drupal projects are the Feeds and Migrate modules, which are used to import data from external sources, such as legacy applications when migrating to Drupal. Once the data has been imported and the site is live, the modules are often so longer needed. As I said yesterday, having less code in your application will make it easier to maintain and upgrade in the future, so keep it as lean and minimal as possible - but this is an ongoing process as requirements change over time. If a module or library has been added to an application, it was done to serve a purpose. It must add some required functionality that was asked for earlier in the application''s lifecycle. It was needed then. But it is still needed now? Are the original requirements still valid? Have they changed or are no longer needed? If the code is no longer serving a purpose, it should be removed. Common culprits in Drupal projects are the Feeds and Migrate modules, which are used to import data from external sources, such as legacy applications when migrating to Drupal. Once the data has been imported and the site is live, the modules are often so longer needed. As I said yesterday, having less code in your application will make it easier to maintain and upgrade in the future, so keep it as lean and minimal as possible - but this is an ongoing process as requirements change over time. 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 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 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
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.01f3b831-e981-471f-aef9-076b054e3495.yml b/content/node.01f3b831-e981-471f-aef9-076b054e3495.yml
new file mode 100644
index 000000000..44539bfbf
--- /dev/null
+++ b/content/node.01f3b831-e981-471f-aef9-076b054e3495.yml
@@ -0,0 +1,85 @@
+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
+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: |
+ Testing - manual or automated - is about building confidence. If we deploy this change or release this feature, are we confident it will work as expected and not cause regressions elsewhere? What if someone asked you on a scale between one and ten? From an automated perspective, have you written enough tests for the feature to be confident it works? 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? Do the tests have enough assertions, and have you covered enough use cases and scenarios? 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. For me, it's about the answer to the question: If we deploy this change, how confident are you that it will work as expected? Testing - manual or automated - is about building confidence. If we deploy this change or release this feature, are we confident it will work as expected and not cause regressions elsewhere? What if someone asked you on a scale between one and ten? From an automated perspective, have you written enough tests for the feature to be confident it works? 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? Do the tests have enough assertions, and have you covered enough use cases and scenarios? 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. For me, it's about the answer to the question: If we deploy this change, how confident are you that it will work as expected? There's nothing more frustrating for me than seeing an error I've seen before and not remembering how I fixed it last time.<\/p> I try to remember and search for the error message, just to find and read the same articles and posts again or watch the same videos.<\/p> I wrote my first blog post on my website in 2010 to document my learning for myself and to share with others.<\/p> I've also been a keen note taker, using tools like Evernote and others to take notes and write documentation for myself to refer to in the future.<\/p> These days, I just write plain text files<\/a> using Nick Janetakis' notes program<\/a>, which I've modified slightly by patching it<\/a> to create daily notes instead of monthly ones. <\/p> They're fast to write, easy to search and available offline if I'm traveling or away from my computer.<\/p> I much prefer being able to search my notes and find what I'm looking for or, if it's a post that I've written publicly, searching online and finding my own answer.<\/p> Whether you're a new or experienced Developer, you're always learning new things, so write them down for yourself and, if you want, write publicly and share your learnings with others.<\/p>",
- "format": "basic_html",
- "processed": " There's nothing more frustrating for me than seeing an error I've seen before and not remembering how I fixed it last time.<\/p> I try to remember and search for the error message, just to find and read the same articles and posts again or watch the same videos.<\/p> I wrote my first blog post on my website in 2010 to document my learning for myself and to share with others.<\/p> I've also been a keen note taker, using tools like Evernote and others to take notes and write documentation for myself to refer to in the future.<\/p> These days, I just write plain text files<\/a> using Nick Janetakis' notes program<\/a>, which I've modified slightly by patching it<\/a> to create daily notes instead of monthly ones. <\/p> They're fast to write, easy to search and available offline if I'm traveling or away from my computer.<\/p> I much prefer being able to search my notes and find what I'm looking for or, if it's a post that I've written publicly, searching online and finding my own answer.<\/p> Whether you're a new or experienced Developer, you're always learning new things, so write them down for yourself and, if you want, write publicly and share your learnings with others.<\/p>",
- "summary": ""
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.0209ee07-9e17-4c85-ae5e-d14ae42bb22a.yml b/content/node.0209ee07-9e17-4c85-ae5e-d14ae42bb22a.yml
new file mode 100644
index 000000000..c2a6571ff
--- /dev/null
+++ b/content/node.0209ee07-9e17-4c85-ae5e-d14ae42bb22a.yml
@@ -0,0 +1,42 @@
+uuid:
+ - value: 0209ee07-9e17-4c85-ae5e-d14ae42bb22a
+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:58:29+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: 'Write it down'
+created:
+ - value: '2025-05-10T09:45:52+00:00'
+changed:
+ - value: '2025-05-11T09:58:29+00:00'
+promote:
+ - value: false
+sticky:
+ - value: false
+default_langcode:
+ - value: true
+revision_translation_affected:
+ - value: true
+path:
+ - alias: /daily/2025/05/10/write
+ langcode: en
+body:
+ - value: " There's nothing more frustrating for me than seeing an error I've seen before and not remembering how I fixed it last time. I try to remember and search for the error message, just to find and read the same articles and posts again or watch the same videos. I wrote my first blog post on my website in 2010 to document my learning for myself and to share with others. I've also been a keen note taker, using tools like Evernote and others to take notes and write documentation for myself to refer to in the future. These days, I just write plain text files using Nick Janetakis' notes program, which I've modified slightly by patching it to create daily notes instead of monthly ones. They're fast to write, easy to search and available offline if I'm traveling or away from my computer. I much prefer being able to search my notes and find what I'm looking for or, if it's a post that I've written publicly, searching online and finding my own answer. Whether you're a new or experienced Developer, you're always learning new things, so write them down for yourself and, if you want, write publicly and share your learnings with others. There's nothing more frustrating for me than seeing an error I've seen before and not remembering how I fixed it last time. I try to remember and search for the error message, just to find and read the same articles and posts again or watch the same videos. I wrote my first blog post on my website in 2010 to document my learning for myself and to share with others. I've also been a keen note taker, using tools like Evernote and others to take notes and write documentation for myself to refer to in the future. These days, I just write plain text files using Nick Janetakis' notes program, which I've modified slightly by patching it to create daily notes instead of monthly ones. They're fast to write, easy to search and available offline if I'm traveling or away from my computer. I much prefer being able to search my notes and find what I'm looking for or, if it's a post that I've written publicly, searching online and finding my own answer. Whether you're a new or experienced Developer, you're always learning new things, so write them down for yourself and, if you want, write publicly and share your learnings with others. I recently saw this post on X<\/a>, talking about an open-source project.<\/p>\n\n This was the part that I want to highlight:<\/p>\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 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\n This was the part that I want to highlight:<\/p>\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 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
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.021e00c1-b813-4edd-8064-71285bc3647d.yml b/content/node.021e00c1-b813-4edd-8064-71285bc3647d.yml
new file mode 100644
index 000000000..efe165b36
--- /dev/null
+++ b/content/node.021e00c1-b813-4edd-8064-71285bc3647d.yml
@@ -0,0 +1,88 @@
+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: |
+ I recently saw this post on X, talking about an open-source project. This was the part that I want to highlight: I was also impressed by the decisions documents. More projects should implement this concept. Looking at the repository, it contains records of 36 decisions made on the project between May 2023 and April 2024. 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. The code and project will likely continue once you've finished working on it, so capturing decisions for future Developers is key. 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. I agree with the poster. More people should record the decisions made on their project, whether it's open-source or not. I recently saw this post on X, talking about an open-source project. This was the part that I want to highlight: I was also impressed by the decisions documents. More projects should implement this concept. Looking at the repository, it contains records of 36 decisions made on the project between May 2023 and April 2024. 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. The code and project will likely continue once you've finished working on it, so capturing decisions for future Developers is key. 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. I agree with the poster. More people should record the decisions made on their project, whether it's open-source or not. 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\n One 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\n I 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\n One 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\n I 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
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.0231b26c-ac28-44e8-a2bf-cc7c86984e7e.yml b/content/node.0231b26c-ac28-44e8-a2bf-cc7c86984e7e.yml
new file mode 100644
index 000000000..09137aa6d
--- /dev/null
+++ b/content/node.0231b26c-ac28-44e8-a2bf-cc7c86984e7e.yml
@@ -0,0 +1,77 @@
+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
+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: |
+ When reviewing a pull or merge request, tools like GitHub and GitHub offer the option to squash the commits before merging. If the request had twenty commits, they'd be combined into a single commit before being merged. But should you do it? The answer will be "it depends" based on the project or team, but I'm personally not a fan of squashing commits. Even though I commit small changes often, I put quite a bit of effort into crafting commits and writing detailed commit messages 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. One 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. 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 would no longer work and a single commit couldn't be simply reverted if it contained a bug. I 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. When reviewing a pull or merge request, tools like GitHub and GitHub offer the option to squash the commits before merging. If the request had twenty commits, they'd be combined into a single commit before being merged. But should you do it? The answer will be "it depends" based on the project or team, but I'm personally not a fan of squashing commits. Even though I commit small changes often, I put quite a bit of effort into crafting commits and writing detailed commit messages 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. One 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. 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 would no longer work and a single commit couldn't be simply reverted if it contained a bug. I 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. 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 As 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 As 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
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.024f2c81-68af-4eef-bea5-1b1d43bd1b39.yml b/content/node.024f2c81-68af-4eef-bea5-1b1d43bd1b39.yml
new file mode 100644
index 000000000..1c649b14b
--- /dev/null
+++ b/content/node.024f2c81-68af-4eef-bea5-1b1d43bd1b39.yml
@@ -0,0 +1,61 @@
+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?
+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: |
+ In yesterday's email, I mentioned that deprecating code allows it to be backwards compatible - but what does that mean? If I were to remove a function like As 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"). 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. In yesterday's email, I mentioned that deprecating code allows it to be backwards compatible - but what does that mean? If I were to remove a function like As 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"). 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. 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\n What 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 My complete NixOS and Home Manager configurations are within my I 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\n What 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 My complete NixOS and Home Manager configurations are within my I wonder what the repository will look like in another eight years...<\/p>\n\n ",
- "summary": null
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.025f0dde-748b-44f4-93e2-4e0602d30104.yml b/content/node.025f0dde-748b-44f4-93e2-4e0602d30104.yml
new file mode 100644
index 000000000..1733042a3
--- /dev/null
+++ b/content/node.025f0dde-748b-44f4-93e2-4e0602d30104.yml
@@ -0,0 +1,69 @@
+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
+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: |
+ 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. Afterwards, I realised the first commit to my personal dotfiles repository was over eight years ago, in July 2015. What 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. In 2021, I switched my My complete NixOS and Home Manager configurations are within my I wonder what the repository will look like in another eight years... 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. Afterwards, I realised the first commit to my personal dotfiles repository was over eight years ago, in July 2015. What 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. In 2021, I switched my My complete NixOS and Home Manager configurations are within my I wonder what the repository will look like in another eight years... 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
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.02777730-3fe8-4eba-8a16-e847042b7351.yml b/content/node.02777730-3fe8-4eba-8a16-e847042b7351.yml
new file mode 100644
index 000000000..5d0bd76af
--- /dev/null
+++ b/content/node.02777730-3fe8-4eba-8a16-e847042b7351.yml
@@ -0,0 +1,64 @@
+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: |
+ 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.02bd7b93-43c7-453f-8af9-0be875b27f82.yml b/content/node.02bd7b93-43c7-453f-8af9-0be875b27f82.yml
new file mode 100644
index 000000000..fb420ffe3
--- /dev/null
+++ b/content/node.02bd7b93-43c7-453f-8af9-0be875b27f82.yml
@@ -0,0 +1,72 @@
+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: |
+ How do you validate an idea from a client or stakeholder? 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. What's the least amount of development you can do to prove the concept? Can you create something using a smaller data set or with simplified functionality? 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? Do you need to write any code or do any development at all? All we need to do is find out if the concept could work. How do you validate an idea from a client or stakeholder? 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. What's the least amount of development you can do to prove the concept? Can you create something using a smaller data set or with simplified functionality? 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? Do you need to write any code or do any development at all? All we need to do is find out if the concept could work. 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
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.02c9e148-b98f-42ae-80f1-d19a6d3fcfb2.yml b/content/node.02c9e148-b98f-42ae-80f1-d19a6d3fcfb2.yml
new file mode 100644
index 000000000..f1b7de72a
--- /dev/null
+++ b/content/node.02c9e148-b98f-42ae-80f1-d19a6d3fcfb2.yml
@@ -0,0 +1,88 @@
+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: |
+ The main programming languages I write are PHP and JavaScript. 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. Adding types is optional. You don't need to add types to your PHP code, and you can choose to write plain JavaScript instead of TypeScript. Some people prefer simpler or cleaner code or less "visual debt". I like the extra clarity that types add. I like to be able to read some code and immediately know what types things should be. I like the clearer errors and messages if a different type is given than was expected. Tools like PHPStan know more about my code and give better recommendations than if I don't add types. I like the better autocompletion I get when writing code that has types. 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. The main programming languages I write are PHP and JavaScript. 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. Adding types is optional. You don't need to add types to your PHP code, and you can choose to write plain JavaScript instead of TypeScript. Some people prefer simpler or cleaner code or less "visual debt". I like the extra clarity that types add. I like to be able to read some code and immediately know what types things should be. I like the clearer errors and messages if a different type is given than was expected. Tools like PHPStan know more about my code and give better recommendations than if I don't add types. I like the better autocompletion I get when writing code that has types. 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. Yesterday's email<\/a> explained why your company should contribute to open-source software, but why should you contribute as an individual?<\/p>\n\n Most 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\n Most 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
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.0300b4ea-e71b-4f9c-b4f2-f04f98e92d6c.yml b/content/node.0300b4ea-e71b-4f9c-b4f2-f04f98e92d6c.yml
new file mode 100644
index 000000000..3d5c4d669
--- /dev/null
+++ b/content/node.0300b4ea-e71b-4f9c-b4f2-f04f98e92d6c.yml
@@ -0,0 +1,73 @@
+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
+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: |
+ Yesterday's email explained why your company should contribute to open-source software, but why should you contribute as an individual? Most of the same reasons apply, such as gaining experience and improved knowledge from contributing. As an individual, you can build your own reputation and personal brand. 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. This could lead to better career opportunities and potential projects. 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. 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. Yesterday's email explained why your company should contribute to open-source software, but why should you contribute as an individual? Most of the same reasons apply, such as gaining experience and improved knowledge from contributing. As an individual, you can build your own reputation and personal brand. 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. This could lead to better career opportunities and potential projects. 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. 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. 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\n Feature 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\n Too 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\n Feature 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\n Too 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
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.0316dfcf-b709-47e1-9622-9355b5ece6d9.yml b/content/node.0316dfcf-b709-47e1-9622-9355b5ece6d9.yml
new file mode 100644
index 000000000..a221e5be9
--- /dev/null
+++ b/content/node.0316dfcf-b709-47e1-9622-9355b5ece6d9.yml
@@ -0,0 +1,96 @@
+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: |
+ Does your team have a "No deploy Friday" policy? What about not deploying after a certain time in the afternoon? These approaches are attempts to minimise risk when deploying. If there is an issue, will someone be available during the evening or weekend to resolve it? To me, this indicates the deployment process is too complicated, possibly due to a lack of automation, or deployments aren't happening frequently enough. Having a robust and passing CI pipeline that runs automated checks and tests is crucial to know the code is deployable. Feature flags are a great way 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. Too much time between deployments is a smell. The more time there is between a deployment and the larger the changeset, the riskier the deployment will be. There is more to go wrong and it'll be harder to diagnose and resolve any issues. I always advocate for many smaller releases than larger less frequent ones. Ideally, a production release every day - even if the changes are small or everything is hidden behind feature flags. Deploying on Friday is easy if you last deployed on Thursday. Does your team have a "No deploy Friday" policy? What about not deploying after a certain time in the afternoon? These approaches are attempts to minimise risk when deploying. If there is an issue, will someone be available during the evening or weekend to resolve it? To me, this indicates the deployment process is too complicated, possibly due to a lack of automation, or deployments aren't happening frequently enough. Having a robust and passing CI pipeline that runs automated checks and tests is crucial to know the code is deployable. Feature flags are a great way 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. Too much time between deployments is a smell. The more time there is between a deployment and the larger the changeset, the riskier the deployment will be. There is more to go wrong and it'll be harder to diagnose and resolve any issues. I always advocate for many smaller releases than larger less frequent ones. Ideally, a production release every day - even if the changes are small or everything is hidden behind feature flags. Deploying on Friday is easy if you last deployed on Thursday. 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\n Some 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\n Some 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
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.0318e249-a9a8-476f-9bd4-432544369917.yml b/content/node.0318e249-a9a8-476f-9bd4-432544369917.yml
new file mode 100644
index 000000000..acd9ba8ce
--- /dev/null
+++ b/content/node.0318e249-a9a8-476f-9bd4-432544369917.yml
@@ -0,0 +1,80 @@
+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: |
+ Applying patch files 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. Some software, such as dwm and st from suckless.org are released as minimal versions that you patch to add features to. 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. Patching offers unlimited customisation and flexibility. Whatever changes you want to make, you can. The downside is you need to maintain any patches you've written. If a change is made that causes your patch to no longer apply, you'll need to update the patch. 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. Sometimes, though, patching is the only option. Applying patch files 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. Some software, such as dwm and st from suckless.org are released as minimal versions that you patch to add features to. 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. Patching offers unlimited customisation and flexibility. Whatever changes you want to make, you can. The downside is you need to maintain any patches you've written. If a change is made that causes your patch to no longer apply, you'll need to update the patch. 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. Sometimes, though, patching is the only option. 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\n I 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 After 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\n Similar to why I use Linux<\/a>, I believe in owning your own content rather than relying on third-party platforms, so having all my content and history in one repository is great.<\/p>\n\n And I learned something new about Git at the same time.<\/p>\n\n ",
- "format": "full_html",
- "processed": "\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\n I 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 After 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\n Similar to why I use Linux<\/a>, I believe in owning your own content rather than relying on third-party platforms, so having all my content and history in one repository is great.<\/p>\n\n And I learned something new about Git at the same time.<\/p>\n\n ",
- "summary": null
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.033f0b46-69f9-4ea0-9706-d930e67dd5d8.yml b/content/node.033f0b46-69f9-4ea0-9706-d930e67dd5d8.yml
new file mode 100644
index 000000000..ce18f6b93
--- /dev/null
+++ b/content/node.033f0b46-69f9-4ea0-9706-d930e67dd5d8.yml
@@ -0,0 +1,88 @@
+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: |
+ My website is built with Sculpin - a static site generator written in PHP. 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. 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). 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, at DrupalCamp North in July 2015. I 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. 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. In short, I was able to do it by adding the old repositories as additional remotes and using the After fixing some minor merge conflicts, everything was merged successfully and I have [one repository containing 5,272 all commits][2], going back to 2015. This makes it older than my dotfiles repository, which I started in July 2015. Similar to why I use Linux, I believe in owning your own content rather than relying on third-party platforms, so having all my content and history in one repository is great. And I learned something new about Git at the same time. My website is built with Sculpin - a static site generator written in PHP. 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. 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). 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, at DrupalCamp North in July 2015. I 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. 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. In short, I was able to do it by adding the old repositories as additional remotes and using the After fixing some minor merge conflicts, everything was merged successfully and I have [one repository containing 5,272 all commits][2], going back to 2015. This makes it older than my dotfiles repository, which I started in July 2015. Similar to why I use Linux, I believe in owning your own content rather than relying on third-party platforms, so having all my content and history in one repository is great. And I learned something new about Git at the same time. I've recently started as a Mentor for the School of Code, working with a student on their cohort that started last week. Whilst the Bootcamp is focussed on JavaScript and node, and is currently looking at front-end development and using APIs, we've already started talking about different back-end technologies and frameworks.<\/p>\n\n Something that I've believed for a while is that software development is about solving problems and different languages and frameworks are tools to use to solve the problem and achieve the desired result. The programming fundamentals that he's learning now can be applied to different languages and some may be better depending on the problem that needs to be solved.<\/p>\n\n I've also said when speaking with a client this week that development is about adding business value.<\/p>\n\n Whilst there is some value to doing security updates and maintenance to keep an application running and secure, I'd much rather be working on tasks that directly add value for the client like some of the tasks I've done for them recently like improving eCommerce conversions and adding new payment methods or revenue streams.<\/p>\n\n It's easier for the client to justify and see the results of the work, it improves the experience for their customers or users, and it's more interesting and fulfilling for me.<\/p>\n\n ",
- "format": "full_html",
- "processed": "\n I've recently started as a Mentor for the School of Code, working with a student on their cohort that started last week. Whilst the Bootcamp is focussed on JavaScript and node, and is currently looking at front-end development and using APIs, we've already started talking about different back-end technologies and frameworks.<\/p>\n\n Something that I've believed for a while is that software development is about solving problems and different languages and frameworks are tools to use to solve the problem and achieve the desired result. The programming fundamentals that he's learning now can be applied to different languages and some may be better depending on the problem that needs to be solved.<\/p>\n\n I've also said when speaking with a client this week that development is about adding business value.<\/p>\n\n Whilst there is some value to doing security updates and maintenance to keep an application running and secure, I'd much rather be working on tasks that directly add value for the client like some of the tasks I've done for them recently like improving eCommerce conversions and adding new payment methods or revenue streams.<\/p>\n\n It's easier for the client to justify and see the results of the work, it improves the experience for their customers or users, and it's more interesting and fulfilling for me.<\/p>\n\n ",
- "summary": null
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.036a8839-c5f9-4206-a979-201e9dac1557.yml b/content/node.036a8839-c5f9-4206-a979-201e9dac1557.yml
new file mode 100644
index 000000000..c9b3c9af3
--- /dev/null
+++ b/content/node.036a8839-c5f9-4206-a979-201e9dac1557.yml
@@ -0,0 +1,65 @@
+uuid:
+ - value: 036a8839-c5f9-4206-a979-201e9dac1557
+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:46+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: |
+ Software development is about solving problems and adding value
+created:
+ - value: '2023-03-27T00:00:00+00:00'
+changed:
+ - value: '2025-05-11T09:00:46+00:00'
+promote:
+ - value: false
+sticky:
+ - value: false
+default_langcode:
+ - value: true
+revision_translation_affected:
+ - value: true
+path:
+ - alias: /daily/2023/03/27/software-development-solving-problems-and-adding-value
+ langcode: en
+body:
+ - value: |
+ I've recently started as a Mentor for the School of Code, working with a student on their cohort that started last week. Whilst the Bootcamp is focussed on JavaScript and node, and is currently looking at front-end development and using APIs, we've already started talking about different back-end technologies and frameworks. Something that I've believed for a while is that software development is about solving problems and different languages and frameworks are tools to use to solve the problem and achieve the desired result. The programming fundamentals that he's learning now can be applied to different languages and some may be better depending on the problem that needs to be solved. I've also said when speaking with a client this week that development is about adding business value. Whilst there is some value to doing security updates and maintenance to keep an application running and secure, I'd much rather be working on tasks that directly add value for the client like some of the tasks I've done for them recently like improving eCommerce conversions and adding new payment methods or revenue streams. It's easier for the client to justify and see the results of the work, it improves the experience for their customers or users, and it's more interesting and fulfilling for me. I've recently started as a Mentor for the School of Code, working with a student on their cohort that started last week. Whilst the Bootcamp is focussed on JavaScript and node, and is currently looking at front-end development and using APIs, we've already started talking about different back-end technologies and frameworks. Something that I've believed for a while is that software development is about solving problems and different languages and frameworks are tools to use to solve the problem and achieve the desired result. The programming fundamentals that he's learning now can be applied to different languages and some may be better depending on the problem that needs to be solved. I've also said when speaking with a client this week that development is about adding business value. Whilst there is some value to doing security updates and maintenance to keep an application running and secure, I'd much rather be working on tasks that directly add value for the client like some of the tasks I've done for them recently like improving eCommerce conversions and adding new payment methods or revenue streams. It's easier for the client to justify and see the results of the work, it improves the experience for their customers or users, and it's more interesting and fulfilling for me. This week's episode<\/a> of the Beyond Blocks podcast is live, where I speak with Panagiotis Moutsopoulos (vensires on Drupal.org) - Drupal Backend Developer at E-Sepia.<\/p>\n\n We discuss his first time DrupalCon and, more specifically, his session \"Drupal's Alternate Realities\" - a \"Birds of a Feather\" (BoF) session presenting some history, but mainly the different ways to tackle a problem in Drupal using different methodologies.<\/p>\n\n ",
- "format": "full_html",
- "processed": "\n This week's episode<\/a> of the Beyond Blocks podcast is live, where I speak with Panagiotis Moutsopoulos (vensires on Drupal.org) - Drupal Backend Developer at E-Sepia.<\/p>\n\n We discuss his first time DrupalCon and, more specifically, his session \"Drupal's Alternate Realities\" - a \"Birds of a Feather\" (BoF) session presenting some history, but mainly the different ways to tackle a problem in Drupal using different methodologies.<\/p>\n\n ",
- "summary": null
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.037796b8-42d8-4ea4-abec-f8c8de0d97e8.yml b/content/node.037796b8-42d8-4ea4-abec-f8c8de0d97e8.yml
new file mode 100644
index 000000000..3c426ac66
--- /dev/null
+++ b/content/node.037796b8-42d8-4ea4-abec-f8c8de0d97e8.yml
@@ -0,0 +1,53 @@
+uuid:
+ - value: 037796b8-42d8-4ea4-abec-f8c8de0d97e8
+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: |
+ Drupal's Alternate Realities
+created:
+ - value: '2023-11-17T00: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/17/drupal-s-alternate-realities
+ langcode: en
+body:
+ - value: |
+ This week's episode of the Beyond Blocks podcast is live, where I speak with Panagiotis Moutsopoulos (vensires on Drupal.org) - Drupal Backend Developer at E-Sepia. We discuss his first time DrupalCon and, more specifically, his session "Drupal's Alternate Realities" - a "Birds of a Feather" (BoF) session presenting some history, but mainly the different ways to tackle a problem in Drupal using different methodologies. This week's episode of the Beyond Blocks podcast is live, where I speak with Panagiotis Moutsopoulos (vensires on Drupal.org) - Drupal Backend Developer at E-Sepia. We discuss his first time DrupalCon and, more specifically, his session "Drupal's Alternate Realities" - a "Birds of a Feather" (BoF) session presenting some history, but mainly the different ways to tackle a problem in Drupal using different methodologies. There are three things you can do with legacy code.<\/p>\n\n Refactor it, remove it or replace it.<\/p>\n\n You can refactor it to make it easier to maintain and change in the future.<\/p>\n\n If it's not needed, you can remove it.<\/p>\n\n If it's not used, there's no need to keep it.<\/p>\n\n Or you can replace it with something else.<\/p>\n\n There isn't one right answer and the correct approach will depend on the situation and objective.<\/p>\n\n In a future email, I'll give some examples of how I refactor legacy code.<\/p>\n\n ",
- "format": "full_html",
- "processed": "\n There are three things you can do with legacy code.<\/p>\n\n Refactor it, remove it or replace it.<\/p>\n\n You can refactor it to make it easier to maintain and change in the future.<\/p>\n\n If it's not needed, you can remove it.<\/p>\n\n If it's not used, there's no need to keep it.<\/p>\n\n Or you can replace it with something else.<\/p>\n\n There isn't one right answer and the correct approach will depend on the situation and objective.<\/p>\n\n In a future email, I'll give some examples of how I refactor legacy code.<\/p>\n\n ",
- "summary": null
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.03bbb03d-5963-477a-a904-19e2c1f1a581.yml b/content/node.03bbb03d-5963-477a-a904-19e2c1f1a581.yml
new file mode 100644
index 000000000..95e9904c7
--- /dev/null
+++ b/content/node.03bbb03d-5963-477a-a904-19e2c1f1a581.yml
@@ -0,0 +1,76 @@
+uuid:
+ - value: 03bbb03d-5963-477a-a904-19e2c1f1a581
+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:02+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: 'Refactor, remove or replace'
+created:
+ - value: '2025-01-09T00:00:00+00:00'
+changed:
+ - value: '2025-05-11T09:00:02+00:00'
+promote:
+ - value: false
+sticky:
+ - value: false
+default_langcode:
+ - value: true
+revision_translation_affected:
+ - value: true
+path:
+ - alias: /daily/2025/01/09/rrr
+ langcode: en
+body:
+ - value: |
+ There are three things you can do with legacy code. Refactor it, remove it or replace it. You can refactor it to make it easier to maintain and change in the future. If it's not needed, you can remove it. If it's not used, there's no need to keep it. Or you can replace it with something else. There isn't one right answer and the correct approach will depend on the situation and objective. In a future email, I'll give some examples of how I refactor legacy code. There are three things you can do with legacy code. Refactor it, remove it or replace it. You can refactor it to make it easier to maintain and change in the future. If it's not needed, you can remove it. If it's not used, there's no need to keep it. Or you can replace it with something else. There isn't one right answer and the correct approach will depend on the situation and objective. In a future email, I'll give some examples of how I refactor legacy code. As well as my laptop configuration<\/a>, local development environments<\/a> and production server<\/a>, I've also been using Nix for something else recently.<\/p>\n\n Setting up and configuring a Homelab on an old laptop.<\/p>\n\n I've been able to install and configure services like Jellyfin for playing video files, Immich for photo hosting and management, Gitea as my own Git server, Vaultwarden for securely storing my passwords and Traefik as a reverse proxy.<\/p>\n\n Each of these was very easy to configure with only a few lines of the Nix language and avoided a heavy use of Docker which seems common in most Homelab setups.<\/p>\n\n Next, I'd like to add home automation with Home Assistant and explore running a local DNS server within my network.<\/p>\n\n I'm looking forward to these, and seeing what else I can add to this setup using Nix and NixOS.<\/p>\n\n ",
- "format": "full_html",
- "processed": "\n As well as my laptop configuration<\/a>, local development environments<\/a> and production server<\/a>, I've also been using Nix for something else recently.<\/p>\n\n Setting up and configuring a Homelab on an old laptop.<\/p>\n\n I've been able to install and configure services like Jellyfin for playing video files, Immich for photo hosting and management, Gitea as my own Git server, Vaultwarden for securely storing my passwords and Traefik as a reverse proxy.<\/p>\n\n Each of these was very easy to configure with only a few lines of the Nix language and avoided a heavy use of Docker which seems common in most Homelab setups.<\/p>\n\n Next, I'd like to add home automation with Home Assistant and explore running a local DNS server within my network.<\/p>\n\n I'm looking forward to these, and seeing what else I can add to this setup using Nix and NixOS.<\/p>\n\n ",
- "summary": null
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.03c0a713-f32d-445b-9397-add68fbf2fe5.yml b/content/node.03c0a713-f32d-445b-9397-add68fbf2fe5.yml
new file mode 100644
index 000000000..77300187e
--- /dev/null
+++ b/content/node.03c0a713-f32d-445b-9397-add68fbf2fe5.yml
@@ -0,0 +1,68 @@
+uuid:
+ - value: 03c0a713-f32d-445b-9397-add68fbf2fe5
+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:04+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: 'Homelabbing with NixOS'
+created:
+ - value: '2024-12-01T00:00:00+00:00'
+changed:
+ - value: '2025-05-11T09:00:04+00:00'
+promote:
+ - value: false
+sticky:
+ - value: false
+default_langcode:
+ - value: true
+revision_translation_affected:
+ - value: true
+path:
+ - alias: /daily/2024/12/01/homelabbing-with-nixos
+ langcode: en
+body:
+ - value: |
+ As well as my laptop configuration, local development environments and production server, I've also been using Nix for something else recently. Setting up and configuring a Homelab on an old laptop. I've been able to install and configure services like Jellyfin for playing video files, Immich for photo hosting and management, Gitea as my own Git server, Vaultwarden for securely storing my passwords and Traefik as a reverse proxy. Each of these was very easy to configure with only a few lines of the Nix language and avoided a heavy use of Docker which seems common in most Homelab setups. Next, I'd like to add home automation with Home Assistant and explore running a local DNS server within my network. I'm looking forward to these, and seeing what else I can add to this setup using Nix and NixOS. As well as my laptop configuration, local development environments and production server, I've also been using Nix for something else recently. Setting up and configuring a Homelab on an old laptop. I've been able to install and configure services like Jellyfin for playing video files, Immich for photo hosting and management, Gitea as my own Git server, Vaultwarden for securely storing my passwords and Traefik as a reverse proxy. Each of these was very easy to configure with only a few lines of the Nix language and avoided a heavy use of Docker which seems common in most Homelab setups. Next, I'd like to add home automation with Home Assistant and explore running a local DNS server within my network. I'm looking forward to these, and seeing what else I can add to this setup using Nix and NixOS. After yesterday's post on why I prefer using Git on the command line rather than using a GUI tool, today I thought that I'd post about how I've configured Git.<\/p>\n\n First, I rarely ever run the Rather than being an simple alias, it's a shell function that will run The main part of my configuration is within Git's For example, I like to avoid merge conflicts, so I always want to use fast-forward merges whilst pulling and also to rebase by default. I can do this by adding I can do this manually, or running Some of the tweaks that I've made are to only allow fast-forward merges by adding Another way that I configure Git is using aliases, which are also within the For example, if I ran I have similar one- or two letter \"short\" aliases for pushing and pulling code, and some that also set some additional arguments such as Aliases can be more complex if needed by prefixing it with a This means that I can have I also have Finally, if an alias is getting too long or complex, then it can extracted to it's own file.<\/p>\n\n Any executable file within your Option 1<\/h2>\n\n
\/** @test *\/\nfunction should_activate_a_pending_user(): void {\n \/\/ Arrange.\n\n \/\/ Act.\n\n \/\/ Assert.\n}\n<\/code><\/pre>\n\nOption 2<\/h2>\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\nOption 1<\/h2>\n\n
\/** @test *\/\nfunction should_activate_a_pending_user(): void {\n \/\/ Arrange.\n\n \/\/ Act.\n\n \/\/ Assert.\n}\n<\/code><\/pre>\n\nOption 2<\/h2>\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\nOption 1
+
+
+
+ /** @test */
+ function should_activate_a_pending_user(): void {
+ // Arrange.
+
+ // Act.
+
+ // Assert.
+ }
+ Option 2
+
+
+
+ /** @test */
+ function should_activate_a_pending_user(): void {
+ // Given I have a user.
+ // And the user is pending.
+
+ // When I run the user update command.
+
+ // Then the user should no longer be 'pending'.
+ // And the user status should be 'active'.
+ }
+ Option 1
+
+
+
+ /** @test */
+ function should_activate_a_pending_user(): void {
+ // Arrange.
+
+ // Act.
+
+ // Assert.
+ }
+ Option 2
+
+
+
+ /** @test */
+ function should_activate_a_pending_user(): void {
+ // Given I have a user.
+ // And the user is pending.
+
+ // When I run the user update command.
+
+ // Then the user should no longer be 'pending'.
+ // And the user status should be 'active'.
+ }
+ php<\/code> but sometimes it was php-fpm<\/code>. In the templated file, it's always named php<\/code>.<\/p>\n\nmysql<\/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\nphp<\/code> but sometimes it was php-fpm<\/code>. In the templated file, it's always named php<\/code>.<\/p>\n\nmysql<\/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\nphp but sometimes it was php-fpm. In the templated file, it's always named php.mysql or mariadb for the database service and nginx or caddy depending on which server was being used. These are now always database and web respectively.php but sometimes it was php-fpm. In the templated file, it's always named php.mysql or mariadb for the database service and nginx or caddy depending on which server was being used. These are now always database and web respectively.
'
+ format: basic_html
+ processed: '
'
+ summary: ''
+field_seo_analysis:
+ - status: '0'
+ focus_keyword: ''
+ title: null
+ description: null
+field_seo_description: { }
+field_seo_image: { }
+field_seo_title: { }
diff --git a/content/node.0100be71-79ef-44ea-922e-e75fcc26ae16.json b/content/node.0100be71-79ef-44ea-922e-e75fcc26ae16.json
deleted file mode 100644
index 9a3089855..000000000
--- a/content/node.0100be71-79ef-44ea-922e-e75fcc26ae16.json
+++ /dev/null
@@ -1,91 +0,0 @@
-{
- "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 :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\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\n
+
+ :root {
+ --color-primary: red;
+ --color-secondary: green;
+ }
+
+ a {
+ color: var(--color-primary);
+
+ &:hover, &:focus {
+ color: var(--color-secondary);
+ }
+ }
+
+
+ :root {
+ --color-primary: red;
+ --color-secondary: green;
+ }
+
+ a {
+ color: var(--color-primary);
+
+ &:hover, &:focus {
+ color: var(--color-secondary);
+ }
+ }
+
<\/p>",
- "format": "basic_html",
- "processed": "
<\/p>",
- "summary": ""
- }
- ]
-}
\ No newline at end of file
diff --git a/content/node.01d84025-8b37-4456-b7f0-bf659c3f5a2b.yml b/content/node.01d84025-8b37-4456-b7f0-bf659c3f5a2b.yml
new file mode 100644
index 000000000..470797ad6
--- /dev/null
+++ b/content/node.01d84025-8b37-4456-b7f0-bf659c3f5a2b.yml
@@ -0,0 +1,42 @@
+uuid:
+ - value: 01d84025-8b37-4456-b7f0-bf659c3f5a2b
+langcode:
+ - value: en
+type:
+ - target_id: daily_email
+ target_type: node_type
+ target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
+revision_timestamp:
+ - value: '2025-05-31T23:12: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: 'Do you still need that module?'
+created:
+ - value: '2025-05-31T23:09:56+00:00'
+changed:
+ - value: '2025-05-31T23:12:38+00:00'
+promote:
+ - value: false
+sticky:
+ - value: false
+default_langcode:
+ - value: true
+revision_translation_affected:
+ - value: true
+path:
+ - alias: /daily/2025/05/31/do-you-still-need-module
+ langcode: en
+body:
+ - value: '
Here's the thing<\/h2>\n\n
Here's the thing<\/h2>\n\n
Here's the thing
+
+ Here's the thing
+
+ \n
Here's the thing<\/h2>\n\n
\n
Here's the thing<\/h2>\n\n
+
+
+ Here's the thing
+
+
+
+
+ Here's the thing
+
+ drupal_set_message()<\/code> that is used code elsewhere in an application, the code would no longer work and would break.<\/p>\n\ndrupal_set_message()<\/code> that is used code elsewhere in an application, the code would no longer work and would break.<\/p>\n\ndrupal_set_message() that is used code elsewhere in an application, the code would no longer work and would break.drupal_set_message() that is used code elsewhere in an application, the code would no longer work and would break..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\ndotfiles<\/code> repository, and the configuration for tools, including Neovim, tmux and Git.<\/p>\n\n.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\ndotfiles<\/code> repository, and the configuration for tools, including Neovim, tmux and Git.<\/p>\n\n.vimrc configuration file to an init.vim 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.dotfiles repository, and the configuration for tools, including Neovim, tmux and Git..vimrc configuration file to an init.vim 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.dotfiles repository, and the configuration for tools, including Neovim, tmux and Git.--allow-unrelated-histories<\/code> option for git merge<\/a>.<\/p>\n\n--allow-unrelated-histories<\/code> option for git merge<\/a>.<\/p>\n\n--allow-unrelated-histories option for git merge.--allow-unrelated-histories option for git merge.git<\/code> command - I usually run a g<\/code> function that I've created within my zsh configuration.<\/p>\n\ngit status -sb<\/code> to show the current status of the repository if there are no additional arguments. If there are, such as when running g add<\/code>, then this is executed as a normal Git command. (This is something that I first saw from Thoughtbot, if I remember correctly).<\/p>\n\nUsing .gitconfig<\/h2>\n\n
~\/.gitconfig<\/code> file, where I can configure Git to work how I want.<\/p>\n\nff = only<\/code> and rebase = true<\/code> to the [pull]<\/code> section of my ~\/.gitconfig<\/code> file.<\/p>\n\ngit config --global pull.rebase true<\/code> will set the option but also update the file automatically.<\/p>\n\nmerge.ff = only<\/code>, automatically squash commits when rebasing by setting rebase.autosquash = true<\/code>, and automatically pruning branches by adding fetch.prune = true<\/code>.<\/p>\n\nSimple aliases<\/h3>\n\n
~\/.gitconfig<\/code> file.<\/p>\n\ngit config --global alias.b \"branch\"<\/code>, then running git b<\/code> would just run git branch<\/code> which shortens the command and saves some time and keystrokes.<\/p>\n\naa<\/code> for add --all<\/code> and worktrees<\/code> for worktree list<\/code>.<\/p>\n\nMore complicated aliases<\/h3>\n\n
!<\/code>, meaning that it executes it as a shell command.<\/p>\n\nrepush = !git pull --rebase && git push<\/code> to chain two separate Git commands and combine them into one, and ureset = !git reset --hard $(git upstream)<\/code> which executes the full command, including another alias as part of it.<\/p>\n\nissues = !gh issue list --web<\/code> and pulls = !gh pr list --web<\/code> to open the current repository's GitHub issues or pull requests respectively, which can be done as it's not limited to just running git<\/code> commands.<\/p>\n\nCustom functions<\/h3>\n\n
$PATH<\/code> that starts with git-<\/code> will automatically become a Git command.<\/p>\n\n