Move all files to tome/

tome/content/node.173ca277-8287-4122-a23d-ddd4b66b08b2.yml

@@ -0,0 +1,79 @@
+uuid:
+  - value: 173ca277-8287-4122-a23d-ddd4b66b08b2
+langcode:
+  - value: en
+type:
+  - target_id: daily_email
+    target_type: node_type
+    target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
+revision_timestamp:
+  - value: '2025-07-08T23:12:55+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: 'Dealing with icky code'
+created:
+  - value: '2025-07-05T23:10:51+00:00'
+changed:
+  - value: '2025-07-08T23:12:55+00:00'
+promote:
+  - value: false
+sticky:
+  - value: false
+default_langcode:
+  - value: true
+revision_translation_affected:
+  - value: true
+path:
+  - alias: /daily/2025/07/05/dealing-icky-code
+    langcode: en
+body:
+  - value: |-
+      Most, if not all, software projects have some code that is difficult to work on.
+
+      Maybe it was written a long time ago or it performs some difficult or complex logic.
+
+      It may not follow modern best practices and, most likely, isn't covered by automated tests.
+
+      No-one wants to work on it.
+
+      But, what happens when it needs to change?
+
+      How can you do it and be confident the change doesn't break the existing functionality?
+
+      Before you make any changes, identify the use cases of the current code and cover them by [writing automated tests][1].
+
+      Functional, web or browser tests allow you to make HTTP requests to an endpoint and make assertions on a response, and ensure it returns the correct status code and content, rather than focussing on the implementation details.
+
+      If you need to test an existing Drupal website, [use Drupal Test Traits][0].
+
+      Once you have tests in place, you can make the required changes and ensure the original functionality still works by running them and checking they still pass.
+
+      Hopefully, you'll have written tests for the new functionality, so the test suite will start to grow.
+
+      [0]: /daily/2025/06/18/exploring-drupal-test-traits
+      [1]: /presentations/tdd-test-driven-drupal
+    format: markdown
+    processed: |
+      <p>Most, if not all, software projects have some code that is difficult to work on.</p>
+      <p>Maybe it was written a long time ago or it performs some difficult or complex logic.</p>
+      <p>It may not follow modern best practices and, most likely, isn't covered by automated tests.</p>
+      <p>No-one wants to work on it.</p>
+      <p>But, what happens when it needs to change?</p>
+      <p>How can you do it and be confident the change doesn't break the existing functionality?</p>
+      <p>Before you make any changes, identify the use cases of the current code and cover them by <a href="/presentations/tdd-test-driven-drupal">writing automated tests</a>.</p>
+      <p>Functional, web or browser tests allow you to make HTTP requests to an endpoint and make assertions on a response, and ensure it returns the correct status code and content, rather than focussing on the implementation details.</p>
+      <p>If you need to test an existing Drupal website, <a href="/daily/2025/06/18/exploring-drupal-test-traits">use Drupal Test Traits</a>.</p>
+      <p>Once you have tests in place, you can make the required changes and ensure the original functionality still works by running them and checking they still pass.</p>
+      <p>Hopefully, you'll have written tests for the new functionality, so the test suite will start to grow.</p>
+    summary: ''
+field_daily_email_cta:
+  - target_type: node
+    target_uuid: e3f6c728-7855-4804-8614-e2a0c08c368f