diff --git a/content/meta/index.json b/content/meta/index.json index 631072b55..2ebc21079 100644 --- a/content/meta/index.json +++ b/content/meta/index.json @@ -6514,5 +6514,12 @@ ], "path_alias.dc2b1737-eeff-4834-b48e-03e8d9279074": [ "node.15089c84-d265-4024-981e-e3c1ca354659" + ], + "node.2743d645-0679-4862-91b6-1f77f218a5fd": [ + "user.b8966985-d4b2-42a7-a319-2e94ccfbb849", + "node.c74de3cf-5362-4d08-935a-a9d0d22fcb94" + ], + "path_alias.7bddd793-15e1-460a-903e-a1d1df57a0d1": [ + "node.2743d645-0679-4862-91b6-1f77f218a5fd" ] } \ No newline at end of file diff --git a/content/node.2743d645-0679-4862-91b6-1f77f218a5fd.json b/content/node.2743d645-0679-4862-91b6-1f77f218a5fd.json new file mode 100644 index 000000000..85ac563f1 --- /dev/null +++ b/content/node.2743d645-0679-4862-91b6-1f77f218a5fd.json @@ -0,0 +1,98 @@ +{ + "uuid": [ + { + "value": "2743d645-0679-4862-91b6-1f77f218a5fd" + } + ], + "langcode": [ + { + "value": "en" + } + ], + "type": [ + { + "target_id": "daily_email", + "target_type": "node_type", + "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7" + } + ], + "revision_timestamp": [ + { + "value": "2025-06-24T22:18: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": "Consistency is key" + } + ], + "created": [ + { + "value": "2025-06-21T22:12:37+00:00" + } + ], + "changed": [ + { + "value": "2025-06-24T22:18:48+00:00" + } + ], + "promote": [ + { + "value": false + } + ], + "sticky": [ + { + "value": false + } + ], + "default_langcode": [ + { + "value": true + } + ], + "revision_translation_affected": [ + { + "value": true + } + ], + "path": [ + { + "alias": "", + "pid": null, + "langcode": "en" + } + ], + "body": [ + { + "value": "Yesterday, I wrote about some of my [thoughts about the Action pattern](\/daily\/2025\/06\/20\/my-thoughts-action-pattern) that's become popular with PHP Developers.\r\n\r\nI showed an example based on the `AddRandomCtaToDailyEmail` action class from my website.\r\n\r\nBut, how should these classes be named?\r\n\r\nShould my example by `AddRandomCtaToDailyEmail` or `AddRandomCtaToDailyEmailAction`?\r\n\r\nShould my `Ctas` class - a collection of \"Call to Action\" nodes - be `Ctas` or `CtaCollection`?\r\n\r\nIn these examples, I think the class name is descriptive enough that it doesn't need to be suffixed.\r\n\r\nIn other cases, such as Controller classes, Interfaces, and classes that follow other design patterns such as Repositories, Factories and Builders, I will prefix to make it clearer which pattern they implement.\r\n\r\nSome projects have an existing coding standard and guidelines to follow, and some will have contribution documentation or a style guide to explain which patterns to follow and how to name things so changes are consistent with the rest of the project.\r\n\r\nConsider doing the same for your software.\r\n\r\nDocument your rules and conventions for your current and future team members.\r\n\r\nThe [Spatie Guidelines](https:\/\/spatie.be\/guidelines) are a great example to follow.\r\n\r\nThen, make sure they are followed when the code is being reviewed, either in a pull\/merge request or during a pair or mob programming session.\r\n\r\nHaving consistent approaches makes projects more robust and easier to work on.", + "format": "markdown", + "processed": "

Yesterday, I wrote about some of my thoughts about the Action pattern<\/a> that's become popular with PHP Developers.<\/p>\n

I showed an example based on the AddRandomCtaToDailyEmail<\/code> action class from my website.<\/p>\n

But, how should these classes be named?<\/p>\n

Should my example by AddRandomCtaToDailyEmail<\/code> or AddRandomCtaToDailyEmailAction<\/code>?<\/p>\n

Should my Ctas<\/code> class - a collection of \"Call to Action\" nodes - be Ctas<\/code> or CtaCollection<\/code>?<\/p>\n

In these examples, I think the class name is descriptive enough that it doesn't need to be suffixed.<\/p>\n

In other cases, such as Controller classes, Interfaces, and classes that follow other design patterns such as Repositories, Factories and Builders, I will prefix to make it clearer which pattern they implement.<\/p>\n

Some projects have an existing coding standard and guidelines to follow, and some will have contribution documentation or a style guide to explain which patterns to follow and how to name things so changes are consistent with the rest of the project.<\/p>\n

Consider doing the same for your software.<\/p>\n

Document your rules and conventions for your current and future team members.<\/p>\n

The Spatie Guidelines<\/a> are a great example to follow.<\/p>\n

Then, make sure they are followed when the code is being reviewed, either in a pull\/merge request or during a pair or mob programming session.<\/p>\n

Having consistent approaches makes projects more robust and easier to work on.<\/p>\n", + "summary": "" + } + ], + "field_daily_email_cta": [ + { + "target_type": "node", + "target_uuid": "c74de3cf-5362-4d08-935a-a9d0d22fcb94" + } + ] +} \ No newline at end of file diff --git a/content/path_alias.7bddd793-15e1-460a-903e-a1d1df57a0d1.json b/content/path_alias.7bddd793-15e1-460a-903e-a1d1df57a0d1.json new file mode 100644 index 000000000..cfd7c4562 --- /dev/null +++ b/content/path_alias.7bddd793-15e1-460a-903e-a1d1df57a0d1.json @@ -0,0 +1,27 @@ +{ + "uuid": [ + { + "value": "7bddd793-15e1-460a-903e-a1d1df57a0d1" + } + ], + "langcode": [ + { + "value": "en" + } + ], + "path": [ + { + "value": "\/node\/2743d645-0679-4862-91b6-1f77f218a5fd" + } + ], + "alias": [ + { + "value": "\/daily\/2025\/06\/21\/consistency-key" + } + ], + "status": [ + { + "value": true + } + ] +} \ No newline at end of file