tome export
This commit is contained in:
parent
52278c3a53
commit
7a52afab5f
960 changed files with 3670 additions and 2229 deletions
|
|
@ -20,8 +20,8 @@ content:
|
|||
type: image
|
||||
label: hidden
|
||||
settings:
|
||||
image_style: medium
|
||||
image_link: ''
|
||||
image_style: medium
|
||||
image_loading:
|
||||
attribute: lazy
|
||||
third_party_settings: { }
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@
|
|||
],
|
||||
"item_count": [
|
||||
{
|
||||
"value": 820
|
||||
"value": 0
|
||||
}
|
||||
]
|
||||
}
|
||||
|
|
@ -43,8 +43,8 @@
|
|||
{
|
||||
"alt": "",
|
||||
"title": null,
|
||||
"width": 180,
|
||||
"height": 180,
|
||||
"width": null,
|
||||
"height": null,
|
||||
"target_type": "file",
|
||||
"target_uuid": "565ea6d1-39f8-4179-979e-f012fcb264af"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@
|
|||
{
|
||||
"alt": "",
|
||||
"title": null,
|
||||
"width": 180,
|
||||
"height": 180,
|
||||
"width": null,
|
||||
"height": null,
|
||||
"target_type": "file",
|
||||
"target_uuid": "565ea6d1-39f8-4179-979e-f012fcb264af"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@
|
|||
{
|
||||
"alt": "",
|
||||
"title": null,
|
||||
"width": 180,
|
||||
"height": 180,
|
||||
"width": null,
|
||||
"height": null,
|
||||
"target_type": "file",
|
||||
"target_uuid": "565ea6d1-39f8-4179-979e-f012fcb264af"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@
|
|||
{
|
||||
"alt": "",
|
||||
"title": null,
|
||||
"width": 180,
|
||||
"height": 180,
|
||||
"width": null,
|
||||
"height": null,
|
||||
"target_type": "file",
|
||||
"target_uuid": "565ea6d1-39f8-4179-979e-f012fcb264af"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@
|
|||
{
|
||||
"alt": "",
|
||||
"title": null,
|
||||
"width": 180,
|
||||
"height": 180,
|
||||
"width": null,
|
||||
"height": null,
|
||||
"target_type": "file",
|
||||
"target_uuid": "565ea6d1-39f8-4179-979e-f012fcb264af"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@
|
|||
{
|
||||
"alt": "",
|
||||
"title": null,
|
||||
"width": 180,
|
||||
"height": 180,
|
||||
"width": null,
|
||||
"height": null,
|
||||
"target_type": "file",
|
||||
"target_uuid": "565ea6d1-39f8-4179-979e-f012fcb264af"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@
|
|||
{
|
||||
"alt": "",
|
||||
"title": null,
|
||||
"width": 180,
|
||||
"height": 180,
|
||||
"width": null,
|
||||
"height": null,
|
||||
"target_type": "file",
|
||||
"target_uuid": "565ea6d1-39f8-4179-979e-f012fcb264af"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@
|
|||
{
|
||||
"alt": "",
|
||||
"title": null,
|
||||
"width": 180,
|
||||
"height": 180,
|
||||
"width": null,
|
||||
"height": null,
|
||||
"target_type": "file",
|
||||
"target_uuid": "565ea6d1-39f8-4179-979e-f012fcb264af"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@
|
|||
{
|
||||
"alt": "",
|
||||
"title": null,
|
||||
"width": 180,
|
||||
"height": 180,
|
||||
"width": null,
|
||||
"height": null,
|
||||
"target_type": "file",
|
||||
"target_uuid": "565ea6d1-39f8-4179-979e-f012fcb264af"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@
|
|||
{
|
||||
"alt": "",
|
||||
"title": null,
|
||||
"width": 180,
|
||||
"height": 180,
|
||||
"width": null,
|
||||
"height": null,
|
||||
"target_type": "file",
|
||||
"target_uuid": "565ea6d1-39f8-4179-979e-f012fcb264af"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@
|
|||
{
|
||||
"alt": "",
|
||||
"title": null,
|
||||
"width": 180,
|
||||
"height": 180,
|
||||
"width": null,
|
||||
"height": null,
|
||||
"target_type": "file",
|
||||
"target_uuid": "565ea6d1-39f8-4179-979e-f012fcb264af"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@
|
|||
{
|
||||
"alt": "",
|
||||
"title": null,
|
||||
"width": 180,
|
||||
"height": 180,
|
||||
"width": null,
|
||||
"height": null,
|
||||
"target_type": "file",
|
||||
"target_uuid": "565ea6d1-39f8-4179-979e-f012fcb264af"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@
|
|||
{
|
||||
"alt": "",
|
||||
"title": null,
|
||||
"width": 180,
|
||||
"height": 180,
|
||||
"width": null,
|
||||
"height": null,
|
||||
"target_type": "file",
|
||||
"target_uuid": "565ea6d1-39f8-4179-979e-f012fcb264af"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@
|
|||
{
|
||||
"alt": "",
|
||||
"title": null,
|
||||
"width": 180,
|
||||
"height": 180,
|
||||
"width": null,
|
||||
"height": null,
|
||||
"target_type": "file",
|
||||
"target_uuid": "565ea6d1-39f8-4179-979e-f012fcb264af"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@
|
|||
{
|
||||
"alt": "",
|
||||
"title": null,
|
||||
"width": 180,
|
||||
"height": 180,
|
||||
"width": null,
|
||||
"height": null,
|
||||
"target_type": "file",
|
||||
"target_uuid": "565ea6d1-39f8-4179-979e-f012fcb264af"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@
|
|||
{
|
||||
"alt": "",
|
||||
"title": null,
|
||||
"width": 180,
|
||||
"height": 180,
|
||||
"width": null,
|
||||
"height": null,
|
||||
"target_type": "file",
|
||||
"target_uuid": "565ea6d1-39f8-4179-979e-f012fcb264af"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@
|
|||
{
|
||||
"alt": "",
|
||||
"title": null,
|
||||
"width": 180,
|
||||
"height": 180,
|
||||
"width": null,
|
||||
"height": null,
|
||||
"target_type": "file",
|
||||
"target_uuid": "565ea6d1-39f8-4179-979e-f012fcb264af"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@
|
|||
{
|
||||
"alt": "",
|
||||
"title": null,
|
||||
"width": 180,
|
||||
"height": 180,
|
||||
"width": null,
|
||||
"height": null,
|
||||
"target_type": "file",
|
||||
"target_uuid": "565ea6d1-39f8-4179-979e-f012fcb264af"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@
|
|||
{
|
||||
"alt": "",
|
||||
"title": null,
|
||||
"width": 180,
|
||||
"height": 180,
|
||||
"width": null,
|
||||
"height": null,
|
||||
"target_type": "file",
|
||||
"target_uuid": "565ea6d1-39f8-4179-979e-f012fcb264af"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@
|
|||
{
|
||||
"alt": "",
|
||||
"title": null,
|
||||
"width": 180,
|
||||
"height": 180,
|
||||
"width": null,
|
||||
"height": null,
|
||||
"target_type": "file",
|
||||
"target_uuid": "565ea6d1-39f8-4179-979e-f012fcb264af"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@
|
|||
{
|
||||
"alt": "",
|
||||
"title": null,
|
||||
"width": 180,
|
||||
"height": 180,
|
||||
"width": null,
|
||||
"height": null,
|
||||
"target_type": "file",
|
||||
"target_uuid": "565ea6d1-39f8-4179-979e-f012fcb264af"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@
|
|||
{
|
||||
"alt": "",
|
||||
"title": null,
|
||||
"width": 180,
|
||||
"height": 180,
|
||||
"width": null,
|
||||
"height": null,
|
||||
"target_type": "file",
|
||||
"target_uuid": "565ea6d1-39f8-4179-979e-f012fcb264af"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@
|
|||
{
|
||||
"alt": "",
|
||||
"title": null,
|
||||
"width": 180,
|
||||
"height": 180,
|
||||
"width": null,
|
||||
"height": null,
|
||||
"target_type": "file",
|
||||
"target_uuid": "565ea6d1-39f8-4179-979e-f012fcb264af"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@
|
|||
{
|
||||
"alt": "",
|
||||
"title": null,
|
||||
"width": 180,
|
||||
"height": 180,
|
||||
"width": null,
|
||||
"height": null,
|
||||
"target_type": "file",
|
||||
"target_uuid": "565ea6d1-39f8-4179-979e-f012fcb264af"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@
|
|||
{
|
||||
"alt": "",
|
||||
"title": null,
|
||||
"width": 180,
|
||||
"height": 180,
|
||||
"width": null,
|
||||
"height": null,
|
||||
"target_type": "file",
|
||||
"target_uuid": "565ea6d1-39f8-4179-979e-f012fcb264af"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@
|
|||
{
|
||||
"alt": "",
|
||||
"title": null,
|
||||
"width": 180,
|
||||
"height": 180,
|
||||
"width": null,
|
||||
"height": null,
|
||||
"target_type": "file",
|
||||
"target_uuid": "565ea6d1-39f8-4179-979e-f012fcb264af"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@
|
|||
{
|
||||
"alt": "",
|
||||
"title": null,
|
||||
"width": 180,
|
||||
"height": 180,
|
||||
"width": null,
|
||||
"height": null,
|
||||
"target_type": "file",
|
||||
"target_uuid": "565ea6d1-39f8-4179-979e-f012fcb264af"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@
|
|||
{
|
||||
"alt": "",
|
||||
"title": null,
|
||||
"width": 180,
|
||||
"height": 180,
|
||||
"width": null,
|
||||
"height": null,
|
||||
"target_type": "file",
|
||||
"target_uuid": "565ea6d1-39f8-4179-979e-f012fcb264af"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@
|
|||
{
|
||||
"alt": "",
|
||||
"title": null,
|
||||
"width": 180,
|
||||
"height": 180,
|
||||
"width": null,
|
||||
"height": null,
|
||||
"target_type": "file",
|
||||
"target_uuid": "565ea6d1-39f8-4179-979e-f012fcb264af"
|
||||
}
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load diff
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "71938847a402f6b5af7c2e34bca063d3",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "a1a228d3231ffab8895ec0cbd78f0b1d",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -82,15 +82,15 @@
|
|||
],
|
||||
"body": [
|
||||
{
|
||||
"value": "\n <p>A side effect of <a href=\"/daily\/2023\/03\/04\/why-i-built-a-tool-to-generate-configuration-files\">using a tool to generate build configuration files<\/a> with templates is the consistency that it introduces.<\/p>\n\n<p>The majority of my projects use a PHP-FPM or PHP CLI container. In my Docker Compose file, the service was mostly named <code>php<\/code> but sometimes it was <code>php-fpm<\/code>. In the templated file, it's always named <code>php<\/code>.<\/p>\n\n<p>Some projects would use <code>mysql<\/code> or <code>mariadb<\/code> for the database service and <code>nginx<\/code> or <code>caddy<\/code> depending on which server was being used. These are now always <code>database<\/code> and <code>web<\/code> respectively.<\/p>\n\n<p>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<p>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<p>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 ",
|
||||
"value": "\n <p>A side effect of <a href=\"\/daily\/2023\/03\/04\/why-i-built-a-tool-to-generate-configuration-files\">using a tool to generate build configuration files<\/a> with templates is the consistency that it introduces.<\/p>\n\n<p>The majority of my projects use a PHP-FPM or PHP CLI container. In my Docker Compose file, the service was mostly named <code>php<\/code> but sometimes it was <code>php-fpm<\/code>. In the templated file, it's always named <code>php<\/code>.<\/p>\n\n<p>Some projects would use <code>mysql<\/code> or <code>mariadb<\/code> for the database service and <code>nginx<\/code> or <code>caddy<\/code> depending on which server was being used. These are now always <code>database<\/code> and <code>web<\/code> respectively.<\/p>\n\n<p>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<p>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<p>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 <p>A side effect of <a href=\"/daily\/2023\/03\/04\/why-i-built-a-tool-to-generate-configuration-files\">using a tool to generate build configuration files<\/a> with templates is the consistency that it introduces.<\/p>\n\n<p>The majority of my projects use a PHP-FPM or PHP CLI container. In my Docker Compose file, the service was mostly named <code>php<\/code> but sometimes it was <code>php-fpm<\/code>. In the templated file, it's always named <code>php<\/code>.<\/p>\n\n<p>Some projects would use <code>mysql<\/code> or <code>mariadb<\/code> for the database service and <code>nginx<\/code> or <code>caddy<\/code> depending on which server was being used. These are now always <code>database<\/code> and <code>web<\/code> respectively.<\/p>\n\n<p>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<p>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<p>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 ",
|
||||
"processed": "\n <p>A side effect of <a href=\"http:\/\/default\/daily\/2023\/03\/04\/why-i-built-a-tool-to-generate-configuration-files\">using a tool to generate build configuration files<\/a> with templates is the consistency that it introduces.<\/p>\n\n<p>The majority of my projects use a PHP-FPM or PHP CLI container. In my Docker Compose file, the service was mostly named <code>php<\/code> but sometimes it was <code>php-fpm<\/code>. In the templated file, it's always named <code>php<\/code>.<\/p>\n\n<p>Some projects would use <code>mysql<\/code> or <code>mariadb<\/code> for the database service and <code>nginx<\/code> or <code>caddy<\/code> depending on which server was being used. These are now always <code>database<\/code> and <code>web<\/code> respectively.<\/p>\n\n<p>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<p>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<p>Now the command is the same for all projects, and I can automate it by writing a script that works on any project meaning I no longer need to write the long command at all.<\/p>\n\n ",
|
||||
"summary": null
|
||||
}
|
||||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "aacb745c094cf5a9f668c64b15000f49",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "3bf8b7e44f82bf7d6ad5ce1fda692ae6",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -82,15 +82,15 @@
|
|||
],
|
||||
"body": [
|
||||
{
|
||||
"value": "\n <p>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<p>The process should be simple to run, quick, reliable and reproducible.<\/p>\n\n<p>It's the same as deploying a change to a staging or production environment.<\/p>\n\n<p>You want the same result on every time on every environment.<\/p>\n\n<p>You want every environment - including <a href=\"/daily\/2024\/12\/25\/localhost\">local development environments<\/a> to be as consistent as possible to minimise bugs and errors.<\/p>\n\n<p>To do this, I automate things to make them as simple as possible.<\/p>\n\n<p>I use <a href=\"/daily\/2022\/08\/15\/using-run-file-simplify-project-tasks\">run files<\/a> with commands to import databases, perform updates and run pre-update and post-update tasks.<\/p>\n\n<p>I use tools like Nix and <a href=\"/daily\/2024\/11\/11\/could-nix-and-devenv-replace-docker-compose\">devenv<\/a> to create identical and reproducible environments.<\/p>\n\n<p>The simpler and quicker is it, the more it can and will be done.<\/p>\n\n<p>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<p>The more you can automate, the better.<\/p>\n\n ",
|
||||
"value": "\n <p>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<p>The process should be simple to run, quick, reliable and reproducible.<\/p>\n\n<p>It's the same as deploying a change to a staging or production environment.<\/p>\n\n<p>You want the same result on every time on every environment.<\/p>\n\n<p>You want every environment - including <a href=\"\/daily\/2024\/12\/25\/localhost\">local development environments<\/a> to be as consistent as possible to minimise bugs and errors.<\/p>\n\n<p>To do this, I automate things to make them as simple as possible.<\/p>\n\n<p>I use <a href=\"\/daily\/2022\/08\/15\/using-run-file-simplify-project-tasks\">run files<\/a> with commands to import databases, perform updates and run pre-update and post-update tasks.<\/p>\n\n<p>I use tools like Nix and <a href=\"\/daily\/2024\/11\/11\/could-nix-and-devenv-replace-docker-compose\">devenv<\/a> to create identical and reproducible environments.<\/p>\n\n<p>The simpler and quicker is it, the more it can and will be done.<\/p>\n\n<p>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<p>The more you can automate, the better.<\/p>\n\n ",
|
||||
"format": "full_html",
|
||||
"processed": "\n <p>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<p>The process should be simple to run, quick, reliable and reproducible.<\/p>\n\n<p>It's the same as deploying a change to a staging or production environment.<\/p>\n\n<p>You want the same result on every time on every environment.<\/p>\n\n<p>You want every environment - including <a href=\"/daily\/2024\/12\/25\/localhost\">local development environments<\/a> to be as consistent as possible to minimise bugs and errors.<\/p>\n\n<p>To do this, I automate things to make them as simple as possible.<\/p>\n\n<p>I use <a href=\"/daily\/2022\/08\/15\/using-run-file-simplify-project-tasks\">run files<\/a> with commands to import databases, perform updates and run pre-update and post-update tasks.<\/p>\n\n<p>I use tools like Nix and <a href=\"/daily\/2024\/11\/11\/could-nix-and-devenv-replace-docker-compose\">devenv<\/a> to create identical and reproducible environments.<\/p>\n\n<p>The simpler and quicker is it, the more it can and will be done.<\/p>\n\n<p>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<p>The more you can automate, the better.<\/p>\n\n ",
|
||||
"processed": "\n <p>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<p>The process should be simple to run, quick, reliable and reproducible.<\/p>\n\n<p>It's the same as deploying a change to a staging or production environment.<\/p>\n\n<p>You want the same result on every time on every environment.<\/p>\n\n<p>You want every environment - including <a href=\"http:\/\/default\/daily\/2024\/12\/25\/localhost\">local development environments<\/a> to be as consistent as possible to minimise bugs and errors.<\/p>\n\n<p>To do this, I automate things to make them as simple as possible.<\/p>\n\n<p>I use <a href=\"http:\/\/default\/daily\/2022\/08\/15\/using-run-file-simplify-project-tasks\">run files<\/a> with commands to import databases, perform updates and run pre-update and post-update tasks.<\/p>\n\n<p>I use tools like Nix and <a href=\"http:\/\/default\/daily\/2024\/11\/11\/could-nix-and-devenv-replace-docker-compose\">devenv<\/a> to create identical and reproducible environments.<\/p>\n\n<p>The simpler and quicker is it, the more it can and will be done.<\/p>\n\n<p>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<p>The more you can automate, the better.<\/p>\n\n ",
|
||||
"summary": null
|
||||
}
|
||||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "957251b7baf05530d91b2a9731016317",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "3baa147faae6a26ac886bb26940c8f43",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -82,15 +82,15 @@
|
|||
],
|
||||
"body": [
|
||||
{
|
||||
"value": "\n <p>PHPStan is a static analysis tool for PHP.<\/p>\n\n<p>It finds potential issues in PHP code without needing to run it, so Developers can find and resolve potential issues sooner.<\/p>\n\n<p>I use it on all my projects including existing ones I've inherited.<\/p>\n\n<p>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<p>PHPStan has different levels of strictness.<\/p>\n\n<p>Level 0 is the least strict and each level adds more rules and strictness, resulting in more errors.<\/p>\n\n<p>Most of the time, people will start by running PHPStan on level 0, fixing any errors and committing the changes.<\/p>\n\n<p>Then repeat the process as many times as needed until you reach the level you want to achieve.<\/p>\n\n<p>I don't think this is the right approach.<\/p>\n\n<p>This could mean that you need to edit the same files multiple times as you work through the levels.<\/p>\n\n<p>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<p>Another approach is to use a feature of PHPStan called the baseline.<\/p>\n\n<p>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<p>If you did this for an existing project, it would return no errors as everything would be included in the baseline.<\/p>\n\n<p>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<p>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<p>This I think is a better approach and how I add PHPStan to existing codebases.<\/p>\n\n<p>To learn more about static analysis and PHPStan, listen to <a href=\"/podcast\/22-dave-liddament\">episode 22 of the Beyond Blocks podcast<\/a> with Dave Liddament.<\/p>\n\n ",
|
||||
"value": "\n <p>PHPStan is a static analysis tool for PHP.<\/p>\n\n<p>It finds potential issues in PHP code without needing to run it, so Developers can find and resolve potential issues sooner.<\/p>\n\n<p>I use it on all my projects including existing ones I've inherited.<\/p>\n\n<p>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<p>PHPStan has different levels of strictness.<\/p>\n\n<p>Level 0 is the least strict and each level adds more rules and strictness, resulting in more errors.<\/p>\n\n<p>Most of the time, people will start by running PHPStan on level 0, fixing any errors and committing the changes.<\/p>\n\n<p>Then repeat the process as many times as needed until you reach the level you want to achieve.<\/p>\n\n<p>I don't think this is the right approach.<\/p>\n\n<p>This could mean that you need to edit the same files multiple times as you work through the levels.<\/p>\n\n<p>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<p>Another approach is to use a feature of PHPStan called the baseline.<\/p>\n\n<p>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<p>If you did this for an existing project, it would return no errors as everything would be included in the baseline.<\/p>\n\n<p>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<p>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<p>This I think is a better approach and how I add PHPStan to existing codebases.<\/p>\n\n<p>To learn more about static analysis and PHPStan, listen to <a href=\"\/podcast\/22-dave-liddament\">episode 22 of the Beyond Blocks podcast<\/a> with Dave Liddament.<\/p>\n\n ",
|
||||
"format": "full_html",
|
||||
"processed": "\n <p>PHPStan is a static analysis tool for PHP.<\/p>\n\n<p>It finds potential issues in PHP code without needing to run it, so Developers can find and resolve potential issues sooner.<\/p>\n\n<p>I use it on all my projects including existing ones I've inherited.<\/p>\n\n<p>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<p>PHPStan has different levels of strictness.<\/p>\n\n<p>Level 0 is the least strict and each level adds more rules and strictness, resulting in more errors.<\/p>\n\n<p>Most of the time, people will start by running PHPStan on level 0, fixing any errors and committing the changes.<\/p>\n\n<p>Then repeat the process as many times as needed until you reach the level you want to achieve.<\/p>\n\n<p>I don't think this is the right approach.<\/p>\n\n<p>This could mean that you need to edit the same files multiple times as you work through the levels.<\/p>\n\n<p>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<p>Another approach is to use a feature of PHPStan called the baseline.<\/p>\n\n<p>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<p>If you did this for an existing project, it would return no errors as everything would be included in the baseline.<\/p>\n\n<p>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<p>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<p>This I think is a better approach and how I add PHPStan to existing codebases.<\/p>\n\n<p>To learn more about static analysis and PHPStan, listen to <a href=\"/podcast\/22-dave-liddament\">episode 22 of the Beyond Blocks podcast<\/a> with Dave Liddament.<\/p>\n\n ",
|
||||
"processed": "\n <p>PHPStan is a static analysis tool for PHP.<\/p>\n\n<p>It finds potential issues in PHP code without needing to run it, so Developers can find and resolve potential issues sooner.<\/p>\n\n<p>I use it on all my projects including existing ones I've inherited.<\/p>\n\n<p>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<p>PHPStan has different levels of strictness.<\/p>\n\n<p>Level 0 is the least strict and each level adds more rules and strictness, resulting in more errors.<\/p>\n\n<p>Most of the time, people will start by running PHPStan on level 0, fixing any errors and committing the changes.<\/p>\n\n<p>Then repeat the process as many times as needed until you reach the level you want to achieve.<\/p>\n\n<p>I don't think this is the right approach.<\/p>\n\n<p>This could mean that you need to edit the same files multiple times as you work through the levels.<\/p>\n\n<p>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<p>Another approach is to use a feature of PHPStan called the baseline.<\/p>\n\n<p>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<p>If you did this for an existing project, it would return no errors as everything would be included in the baseline.<\/p>\n\n<p>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<p>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<p>This I think is a better approach and how I add PHPStan to existing codebases.<\/p>\n\n<p>To learn more about static analysis and PHPStan, listen to <a href=\"http:\/\/default\/podcast\/22-dave-liddament\">episode 22 of the Beyond Blocks podcast<\/a> with Dave Liddament.<\/p>\n\n ",
|
||||
"summary": null
|
||||
}
|
||||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "9a7b258b69b97c51304c0aa8d6b87263",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "cdd9ab25b0351a9082e1580898e5ecbc",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "60c550711c51c2b739051e4640eba954",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@
|
|||
{
|
||||
"value": "<p>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><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><p>I wrote my first blog post on my website in 2010 to document my learning for myself and to share with others.<\/p><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><p>These days, I just <a href=\"\/daily\/2024\/11\/10\/write-plain-text-files\">write plain text files<\/a> using <a href=\"https:\/\/github.com\/nickjj\/notes\">Nick Janetakis' notes program<\/a>, which I've modified slightly <a href=\"\/daily\/2025\/04\/21\/patch\">by patching it<\/a> to create daily notes instead of monthly ones. <\/p><p>They're fast to write, easy to search and available offline if I'm traveling or away from my computer.<\/p><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><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": "<p>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><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><p>I wrote my first blog post on my website in 2010 to document my learning for myself and to share with others.<\/p><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><p>These days, I just <a href=\"\/daily\/2024\/11\/10\/write-plain-text-files\">write plain text files<\/a> using <a href=\"https:\/\/github.com\/nickjj\/notes\">Nick Janetakis' notes program<\/a>, which I've modified slightly <a href=\"\/daily\/2025\/04\/21\/patch\">by patching it<\/a> to create daily notes instead of monthly ones. <\/p><p>They're fast to write, easy to search and available offline if I'm traveling or away from my computer.<\/p><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><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>",
|
||||
"processed": "<p>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><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><p>I wrote my first blog post on my website in 2010 to document my learning for myself and to share with others.<\/p><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><p>These days, I just <a href=\"http:\/\/default\/daily\/2024\/11\/10\/write-plain-text-files\">write plain text files<\/a> using <a href=\"https:\/\/github.com\/nickjj\/notes\">Nick Janetakis' notes program<\/a>, which I've modified slightly <a href=\"http:\/\/default\/daily\/2025\/04\/21\/patch\">by patching it<\/a> to create daily notes instead of monthly ones. <\/p><p>They're fast to write, easy to search and available offline if I'm traveling or away from my computer.<\/p><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><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": ""
|
||||
}
|
||||
],
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "bc11c3125e2e228f16b76f91b749c764",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -82,15 +82,15 @@
|
|||
],
|
||||
"body": [
|
||||
{
|
||||
"value": "\n <p>When reviewing a pull or merge request, tools like GitHub and GitHub offer the option to squash the commits before merging.<\/p>\n\n<p>If the request had twenty commits, they'd be combined into a single commit before being merged.<\/p>\n\n<p>But should you do it?<\/p>\n\n<p>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<p>Even though I commit small changes often, I put quite a bit of effort into <a href=\"/daily\/2023\/01\/24\/small-commits-and-good-commit-messges\">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<p>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<p>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 <a href=\"/daily\/2023\/01\/23\/debugging-with-git-bisect\">git bisect<\/a> would no longer work and a single commit couldn't be simply reverted if it contained a bug.<\/p>\n\n<p>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 ",
|
||||
"value": "\n <p>When reviewing a pull or merge request, tools like GitHub and GitHub offer the option to squash the commits before merging.<\/p>\n\n<p>If the request had twenty commits, they'd be combined into a single commit before being merged.<\/p>\n\n<p>But should you do it?<\/p>\n\n<p>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<p>Even though I commit small changes often, I put quite a bit of effort into <a href=\"\/daily\/2023\/01\/24\/small-commits-and-good-commit-messges\">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<p>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<p>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 <a href=\"\/daily\/2023\/01\/23\/debugging-with-git-bisect\">git bisect<\/a> would no longer work and a single commit couldn't be simply reverted if it contained a bug.<\/p>\n\n<p>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 <p>When reviewing a pull or merge request, tools like GitHub and GitHub offer the option to squash the commits before merging.<\/p>\n\n<p>If the request had twenty commits, they'd be combined into a single commit before being merged.<\/p>\n\n<p>But should you do it?<\/p>\n\n<p>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<p>Even though I commit small changes often, I put quite a bit of effort into <a href=\"/daily\/2023\/01\/24\/small-commits-and-good-commit-messges\">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<p>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<p>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 <a href=\"/daily\/2023\/01\/23\/debugging-with-git-bisect\">git bisect<\/a> would no longer work and a single commit couldn't be simply reverted if it contained a bug.<\/p>\n\n<p>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 ",
|
||||
"processed": "\n <p>When reviewing a pull or merge request, tools like GitHub and GitHub offer the option to squash the commits before merging.<\/p>\n\n<p>If the request had twenty commits, they'd be combined into a single commit before being merged.<\/p>\n\n<p>But should you do it?<\/p>\n\n<p>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<p>Even though I commit small changes often, I put quite a bit of effort into <a href=\"http:\/\/default\/daily\/2023\/01\/24\/small-commits-and-good-commit-messges\">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<p>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<p>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 <a href=\"http:\/\/default\/daily\/2023\/01\/23\/debugging-with-git-bisect\">git bisect<\/a> would no longer work and a single commit couldn't be simply reverted if it contained a bug.<\/p>\n\n<p>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
|
||||
}
|
||||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "54447bfd288cd6e71d4b06bd0646502d",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "18e7b8e123a0c299bb44600a75b56d9e",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "b663fb9c5e0257d2fdece24454ad3bfd",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "891d018e5d9b5fa68288878004365cce",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "f671ea961bdda4e275277b04dc159c79",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "c50e363614371738c421f8a32ee763f3",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -82,15 +82,15 @@
|
|||
],
|
||||
"body": [
|
||||
{
|
||||
"value": "\n <p><a href=\"/daily\/2023\/11\/03\/why-your-company-should-contribute-to-open-source-software\">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<p>Most of the same reasons apply, such as gaining experience and improved knowledge from contributing.<\/p>\n\n<p>As an individual, you can build your own reputation and personal brand.<\/p>\n\n<p>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<p>This could lead to better career opportunities and potential projects.<\/p>\n\n<p>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<p>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 ",
|
||||
"value": "\n <p><a href=\"\/daily\/2023\/11\/03\/why-your-company-should-contribute-to-open-source-software\">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<p>Most of the same reasons apply, such as gaining experience and improved knowledge from contributing.<\/p>\n\n<p>As an individual, you can build your own reputation and personal brand.<\/p>\n\n<p>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<p>This could lead to better career opportunities and potential projects.<\/p>\n\n<p>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<p>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 <p><a href=\"/daily\/2023\/11\/03\/why-your-company-should-contribute-to-open-source-software\">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<p>Most of the same reasons apply, such as gaining experience and improved knowledge from contributing.<\/p>\n\n<p>As an individual, you can build your own reputation and personal brand.<\/p>\n\n<p>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<p>This could lead to better career opportunities and potential projects.<\/p>\n\n<p>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<p>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 ",
|
||||
"processed": "\n <p><a href=\"http:\/\/default\/daily\/2023\/11\/03\/why-your-company-should-contribute-to-open-source-software\">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<p>Most of the same reasons apply, such as gaining experience and improved knowledge from contributing.<\/p>\n\n<p>As an individual, you can build your own reputation and personal brand.<\/p>\n\n<p>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<p>This could lead to better career opportunities and potential projects.<\/p>\n\n<p>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<p>Like companies, if you make money from open-source software - either a salary or from paid projects or courses - it's in your interest to contribute so the software you use is maintained and improved so it's the best it can be.<\/p>\n\n ",
|
||||
"summary": null
|
||||
}
|
||||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "0f37079942ad6ce63ae32e8ea7c57c79",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -82,15 +82,15 @@
|
|||
],
|
||||
"body": [
|
||||
{
|
||||
"value": "\n <p>Does your team have a \"No deploy Friday\" policy?<\/p>\n\n<p>What about not deploying after a certain time in the afternoon?<\/p>\n\n<p>These approaches are attempts to minimise risk when deploying.<\/p>\n\n<p>If there is an issue, will someone be available during the evening or weekend to resolve it?<\/p>\n\n<p>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<p>Having a <a href=\"/daily\/2025\/01\/30\/gatekeeper\">robust and passing CI pipeline<\/a> that runs automated checks and tests is crucial to know the code is deployable.<\/p>\n\n<p><a href=\"/daily\/2023\/09\/28\/feature-flags-enable-continuous-integration\">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<p>Too much time between deployments is a smell.<\/p>\n\n<p>The more time there is between a deployment and the larger the changeset, the riskier the deployment will be.<\/p>\n\n<p>There is more to go wrong and it'll be harder to diagnose and resolve any issues.<\/p>\n\n<p>I always advocate for many smaller releases than larger less frequent ones.<\/p>\n\n<p>Ideally, a production release every day - even if the changes are small or everything is hidden behind feature flags.<\/p>\n\n<p>Deploying on Friday is easy if you last deployed on Thursday.<\/p>\n\n ",
|
||||
"value": "\n <p>Does your team have a \"No deploy Friday\" policy?<\/p>\n\n<p>What about not deploying after a certain time in the afternoon?<\/p>\n\n<p>These approaches are attempts to minimise risk when deploying.<\/p>\n\n<p>If there is an issue, will someone be available during the evening or weekend to resolve it?<\/p>\n\n<p>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<p>Having a <a href=\"\/daily\/2025\/01\/30\/gatekeeper\">robust and passing CI pipeline<\/a> that runs automated checks and tests is crucial to know the code is deployable.<\/p>\n\n<p><a href=\"\/daily\/2023\/09\/28\/feature-flags-enable-continuous-integration\">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<p>Too much time between deployments is a smell.<\/p>\n\n<p>The more time there is between a deployment and the larger the changeset, the riskier the deployment will be.<\/p>\n\n<p>There is more to go wrong and it'll be harder to diagnose and resolve any issues.<\/p>\n\n<p>I always advocate for many smaller releases than larger less frequent ones.<\/p>\n\n<p>Ideally, a production release every day - even if the changes are small or everything is hidden behind feature flags.<\/p>\n\n<p>Deploying on Friday is easy if you last deployed on Thursday.<\/p>\n\n ",
|
||||
"format": "full_html",
|
||||
"processed": "\n <p>Does your team have a \"No deploy Friday\" policy?<\/p>\n\n<p>What about not deploying after a certain time in the afternoon?<\/p>\n\n<p>These approaches are attempts to minimise risk when deploying.<\/p>\n\n<p>If there is an issue, will someone be available during the evening or weekend to resolve it?<\/p>\n\n<p>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<p>Having a <a href=\"/daily\/2025\/01\/30\/gatekeeper\">robust and passing CI pipeline<\/a> that runs automated checks and tests is crucial to know the code is deployable.<\/p>\n\n<p><a href=\"/daily\/2023\/09\/28\/feature-flags-enable-continuous-integration\">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<p>Too much time between deployments is a smell.<\/p>\n\n<p>The more time there is between a deployment and the larger the changeset, the riskier the deployment will be.<\/p>\n\n<p>There is more to go wrong and it'll be harder to diagnose and resolve any issues.<\/p>\n\n<p>I always advocate for many smaller releases than larger less frequent ones.<\/p>\n\n<p>Ideally, a production release every day - even if the changes are small or everything is hidden behind feature flags.<\/p>\n\n<p>Deploying on Friday is easy if you last deployed on Thursday.<\/p>\n\n ",
|
||||
"processed": "\n <p>Does your team have a \"No deploy Friday\" policy?<\/p>\n\n<p>What about not deploying after a certain time in the afternoon?<\/p>\n\n<p>These approaches are attempts to minimise risk when deploying.<\/p>\n\n<p>If there is an issue, will someone be available during the evening or weekend to resolve it?<\/p>\n\n<p>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<p>Having a <a href=\"http:\/\/default\/daily\/2025\/01\/30\/gatekeeper\">robust and passing CI pipeline<\/a> that runs automated checks and tests is crucial to know the code is deployable.<\/p>\n\n<p><a href=\"http:\/\/default\/daily\/2023\/09\/28\/feature-flags-enable-continuous-integration\">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<p>Too much time between deployments is a smell.<\/p>\n\n<p>The more time there is between a deployment and the larger the changeset, the riskier the deployment will be.<\/p>\n\n<p>There is more to go wrong and it'll be harder to diagnose and resolve any issues.<\/p>\n\n<p>I always advocate for many smaller releases than larger less frequent ones.<\/p>\n\n<p>Ideally, a production release every day - even if the changes are small or everything is hidden behind feature flags.<\/p>\n\n<p>Deploying on Friday is easy if you last deployed on Thursday.<\/p>\n\n ",
|
||||
"summary": null
|
||||
}
|
||||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "021827be7bf3f083020a0f2ff11066d8",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -82,15 +82,15 @@
|
|||
],
|
||||
"body": [
|
||||
{
|
||||
"value": "\n <p><a href=\"/daily\/2025\/01\/13\/patches\">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<p>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<p>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<p>Patching offers unlimited customisation and flexibility.<\/p>\n\n<p>Whatever changes you want to make, you can.<\/p>\n\n<p>The downside is you need to maintain any patches you've written.<\/p>\n\n<p>If a change is made that causes your patch to no longer apply, you'll need to update the patch.<\/p>\n\n<p>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<p>Sometimes, though, <a href=\"/daily\/2025\/01\/14\/patching-drupal\">patching is the only option<\/a>.<\/p>\n\n ",
|
||||
"value": "\n <p><a href=\"\/daily\/2025\/01\/13\/patches\">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<p>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<p>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<p>Patching offers unlimited customisation and flexibility.<\/p>\n\n<p>Whatever changes you want to make, you can.<\/p>\n\n<p>The downside is you need to maintain any patches you've written.<\/p>\n\n<p>If a change is made that causes your patch to no longer apply, you'll need to update the patch.<\/p>\n\n<p>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<p>Sometimes, though, <a href=\"\/daily\/2025\/01\/14\/patching-drupal\">patching is the only option<\/a>.<\/p>\n\n ",
|
||||
"format": "full_html",
|
||||
"processed": "\n <p><a href=\"/daily\/2025\/01\/13\/patches\">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<p>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<p>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<p>Patching offers unlimited customisation and flexibility.<\/p>\n\n<p>Whatever changes you want to make, you can.<\/p>\n\n<p>The downside is you need to maintain any patches you've written.<\/p>\n\n<p>If a change is made that causes your patch to no longer apply, you'll need to update the patch.<\/p>\n\n<p>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<p>Sometimes, though, <a href=\"/daily\/2025\/01\/14\/patching-drupal\">patching is the only option<\/a>.<\/p>\n\n ",
|
||||
"processed": "\n <p><a href=\"http:\/\/default\/daily\/2025\/01\/13\/patches\">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<p>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<p>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<p>Patching offers unlimited customisation and flexibility.<\/p>\n\n<p>Whatever changes you want to make, you can.<\/p>\n\n<p>The downside is you need to maintain any patches you've written.<\/p>\n\n<p>If a change is made that causes your patch to no longer apply, you'll need to update the patch.<\/p>\n\n<p>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<p>Sometimes, though, <a href=\"http:\/\/default\/daily\/2025\/01\/14\/patching-drupal\">patching is the only option<\/a>.<\/p>\n\n ",
|
||||
"summary": null
|
||||
}
|
||||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "e1882c079f5b933697958ec2ac91a1b7",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -82,15 +82,15 @@
|
|||
],
|
||||
"body": [
|
||||
{
|
||||
"value": "\n <p>My website is built with Sculpin - a static site generator written in PHP.<\/p>\n\n<p>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<p>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<p>I enjoyed learning Sculpin and took it as an opportunity to learn Twig before Drupal 8, which I spoke about in <a href=\"/presentations\/test-drive-twig-with-sculpin\">the first Sculpin talk I gave<\/a>, at DrupalCamp North in July 2015.<\/p>\n\n<p>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<p>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<p>In short, I was able to do it by adding the old repositories as additional remotes and using the <code>--allow-unrelated-histories<\/code> <a href=\"https:\/\/git-scm.com\/docs\/git-merge#Documentation\/git-merge.txt---allow-unrelated-histories\">option for git merge<\/a>.<\/p>\n\n<p>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<p>This makes it older than <a href=\"/daily\/2023\/08\/08\/8-years-of-dotfiles\">my dotfiles repository<\/a>, which I started in July 2015.<\/p>\n\n<p>Similar to <a href=\"/daily\/2024\/07\/31\/why-i-use-linux\">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<p>And I learned something new about Git at the same time.<\/p>\n\n ",
|
||||
"value": "\n <p>My website is built with Sculpin - a static site generator written in PHP.<\/p>\n\n<p>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<p>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<p>I enjoyed learning Sculpin and took it as an opportunity to learn Twig before Drupal 8, which I spoke about in <a href=\"\/presentations\/test-drive-twig-with-sculpin\">the first Sculpin talk I gave<\/a>, at DrupalCamp North in July 2015.<\/p>\n\n<p>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<p>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<p>In short, I was able to do it by adding the old repositories as additional remotes and using the <code>--allow-unrelated-histories<\/code> <a href=\"https:\/\/git-scm.com\/docs\/git-merge#Documentation\/git-merge.txt---allow-unrelated-histories\">option for git merge<\/a>.<\/p>\n\n<p>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<p>This makes it older than <a href=\"\/daily\/2023\/08\/08\/8-years-of-dotfiles\">my dotfiles repository<\/a>, which I started in July 2015.<\/p>\n\n<p>Similar to <a href=\"\/daily\/2024\/07\/31\/why-i-use-linux\">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<p>And I learned something new about Git at the same time.<\/p>\n\n ",
|
||||
"format": "full_html",
|
||||
"processed": "\n <p>My website is built with Sculpin - a static site generator written in PHP.<\/p>\n\n<p>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<p>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<p>I enjoyed learning Sculpin and took it as an opportunity to learn Twig before Drupal 8, which I spoke about in <a href=\"/presentations\/test-drive-twig-with-sculpin\">the first Sculpin talk I gave<\/a>, at DrupalCamp North in July 2015.<\/p>\n\n<p>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<p>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<p>In short, I was able to do it by adding the old repositories as additional remotes and using the <code>--allow-unrelated-histories<\/code> <a href=\"https:\/\/git-scm.com\/docs\/git-merge#Documentation\/git-merge.txt---allow-unrelated-histories\">option for git merge<\/a>.<\/p>\n\n<p>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<p>This makes it older than <a href=\"/daily\/2023\/08\/08\/8-years-of-dotfiles\">my dotfiles repository<\/a>, which I started in July 2015.<\/p>\n\n<p>Similar to <a href=\"/daily\/2024\/07\/31\/why-i-use-linux\">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<p>And I learned something new about Git at the same time.<\/p>\n\n ",
|
||||
"processed": "\n <p>My website is built with Sculpin - a static site generator written in PHP.<\/p>\n\n<p>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<p>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<p>I enjoyed learning Sculpin and took it as an opportunity to learn Twig before Drupal 8, which I spoke about in <a href=\"http:\/\/default\/presentations\/test-drive-twig-with-sculpin\">the first Sculpin talk I gave<\/a>, at DrupalCamp North in July 2015.<\/p>\n\n<p>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<p>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<p>In short, I was able to do it by adding the old repositories as additional remotes and using the <code>--allow-unrelated-histories<\/code> <a href=\"https:\/\/git-scm.com\/docs\/git-merge#Documentation\/git-merge.txt---allow-unrelated-histories\">option for git merge<\/a>.<\/p>\n\n<p>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<p>This makes it older than <a href=\"http:\/\/default\/daily\/2023\/08\/08\/8-years-of-dotfiles\">my dotfiles repository<\/a>, which I started in July 2015.<\/p>\n\n<p>Similar to <a href=\"http:\/\/default\/daily\/2024\/07\/31\/why-i-use-linux\">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<p>And I learned something new about Git at the same time.<\/p>\n\n ",
|
||||
"summary": null
|
||||
}
|
||||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "cc353a3343b4a9ed6dc01850a09c8f76",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "7256a5bb0e6800a548d88e2979344646",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -82,15 +82,15 @@
|
|||
],
|
||||
"body": [
|
||||
{
|
||||
"value": "\n <p><a href=\"/podcast\/2-alternate-realities\">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<p>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 ",
|
||||
"value": "\n <p><a href=\"\/podcast\/2-alternate-realities\">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<p>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 <p><a href=\"/podcast\/2-alternate-realities\">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<p>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 ",
|
||||
"processed": "\n <p><a href=\"http:\/\/default\/podcast\/2-alternate-realities\">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<p>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
|
||||
}
|
||||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "4ddf140ca0555c2028d2bb2db394282f",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "a3ea19c23705f4574c9b1455cc2169bc",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -82,15 +82,15 @@
|
|||
],
|
||||
"body": [
|
||||
{
|
||||
"value": "\n <p>As well as <a href=\"/daily\/2024\/11\/27\/nix-as-an-operating-system\">my laptop configuration<\/a>, <a href=\"/daily\/2024\/11\/30\/using-nix-for-local-application-development\">local development environments<\/a> and <a href=\"/daily\/2024\/11\/28\/running-nixos-in-the-cloud\">production server<\/a>, I've also been using Nix for something else recently.<\/p>\n\n<p>Setting up and configuring a Homelab on an old laptop.<\/p>\n\n<p>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<p>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<p>Next, I'd like to add home automation with Home Assistant and explore running a local DNS server within my network.<\/p>\n\n<p>I'm looking forward to these, and seeing what else I can add to this setup using Nix and NixOS.<\/p>\n\n ",
|
||||
"value": "\n <p>As well as <a href=\"\/daily\/2024\/11\/27\/nix-as-an-operating-system\">my laptop configuration<\/a>, <a href=\"\/daily\/2024\/11\/30\/using-nix-for-local-application-development\">local development environments<\/a> and <a href=\"\/daily\/2024\/11\/28\/running-nixos-in-the-cloud\">production server<\/a>, I've also been using Nix for something else recently.<\/p>\n\n<p>Setting up and configuring a Homelab on an old laptop.<\/p>\n\n<p>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<p>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<p>Next, I'd like to add home automation with Home Assistant and explore running a local DNS server within my network.<\/p>\n\n<p>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 <p>As well as <a href=\"/daily\/2024\/11\/27\/nix-as-an-operating-system\">my laptop configuration<\/a>, <a href=\"/daily\/2024\/11\/30\/using-nix-for-local-application-development\">local development environments<\/a> and <a href=\"/daily\/2024\/11\/28\/running-nixos-in-the-cloud\">production server<\/a>, I've also been using Nix for something else recently.<\/p>\n\n<p>Setting up and configuring a Homelab on an old laptop.<\/p>\n\n<p>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<p>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<p>Next, I'd like to add home automation with Home Assistant and explore running a local DNS server within my network.<\/p>\n\n<p>I'm looking forward to these, and seeing what else I can add to this setup using Nix and NixOS.<\/p>\n\n ",
|
||||
"processed": "\n <p>As well as <a href=\"http:\/\/default\/daily\/2024\/11\/27\/nix-as-an-operating-system\">my laptop configuration<\/a>, <a href=\"http:\/\/default\/daily\/2024\/11\/30\/using-nix-for-local-application-development\">local development environments<\/a> and <a href=\"http:\/\/default\/daily\/2024\/11\/28\/running-nixos-in-the-cloud\">production server<\/a>, I've also been using Nix for something else recently.<\/p>\n\n<p>Setting up and configuring a Homelab on an old laptop.<\/p>\n\n<p>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<p>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<p>Next, I'd like to add home automation with Home Assistant and explore running a local DNS server within my network.<\/p>\n\n<p>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
|
||||
}
|
||||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "ddffb71cbb4982c0c4d9ca78fecdcd4c",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "4d3892ad51836bdd33e47e7043615d75",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "137f467c7894dcf4d534ab6c7572567a",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "54fdebe3f9556a6d18a8f24c72f72652",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -82,15 +82,15 @@
|
|||
],
|
||||
"body": [
|
||||
{
|
||||
"value": "\n <p>This week on the <a href=\"/podcast\">Beyond Blocks podcast<\/a>, I'm joined by Dan Leech - a PHP Developer and open-source project creator.<\/p>\n\n<p>He and I recently gave talks at the PHP South West meetup, where Dan introduced a new project - PHP-TUI - for building terminal user interfaces (TUIs) with PHP.<\/p>\n\n<p>I use one of Dan's other open-source projects - Phpactor - within Neovim, and he also presented at PHP South Wales about PHPBench, so it was great to discuss and learn more about these in this episode.<\/p>\n\n<p><a href=\"/podcast\/6-dan-leech-php-tui\">Listen to the episode now<\/a>, and I'll be back with more in the New Year.<\/p>\n\n ",
|
||||
"value": "\n <p>This week on the <a href=\"\/podcast\">Beyond Blocks podcast<\/a>, I'm joined by Dan Leech - a PHP Developer and open-source project creator.<\/p>\n\n<p>He and I recently gave talks at the PHP South West meetup, where Dan introduced a new project - PHP-TUI - for building terminal user interfaces (TUIs) with PHP.<\/p>\n\n<p>I use one of Dan's other open-source projects - Phpactor - within Neovim, and he also presented at PHP South Wales about PHPBench, so it was great to discuss and learn more about these in this episode.<\/p>\n\n<p><a href=\"\/podcast\/6-dan-leech-php-tui\">Listen to the episode now<\/a>, and I'll be back with more in the New Year.<\/p>\n\n ",
|
||||
"format": "full_html",
|
||||
"processed": "\n <p>This week on the <a href=\"/podcast\">Beyond Blocks podcast<\/a>, I'm joined by Dan Leech - a PHP Developer and open-source project creator.<\/p>\n\n<p>He and I recently gave talks at the PHP South West meetup, where Dan introduced a new project - PHP-TUI - for building terminal user interfaces (TUIs) with PHP.<\/p>\n\n<p>I use one of Dan's other open-source projects - Phpactor - within Neovim, and he also presented at PHP South Wales about PHPBench, so it was great to discuss and learn more about these in this episode.<\/p>\n\n<p><a href=\"/podcast\/6-dan-leech-php-tui\">Listen to the episode now<\/a>, and I'll be back with more in the New Year.<\/p>\n\n ",
|
||||
"processed": "\n <p>This week on the <a href=\"http:\/\/default\/podcast\">Beyond Blocks podcast<\/a>, I'm joined by Dan Leech - a PHP Developer and open-source project creator.<\/p>\n\n<p>He and I recently gave talks at the PHP South West meetup, where Dan introduced a new project - PHP-TUI - for building terminal user interfaces (TUIs) with PHP.<\/p>\n\n<p>I use one of Dan's other open-source projects - Phpactor - within Neovim, and he also presented at PHP South Wales about PHPBench, so it was great to discuss and learn more about these in this episode.<\/p>\n\n<p><a href=\"http:\/\/default\/podcast\/6-dan-leech-php-tui\">Listen to the episode now<\/a>, and I'll be back with more in the New Year.<\/p>\n\n ",
|
||||
"summary": null
|
||||
}
|
||||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "3cc8c054a1675b2ab1a1ec63dd5f49ad",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -82,15 +82,15 @@
|
|||
],
|
||||
"body": [
|
||||
{
|
||||
"value": "\n <p>I've noticed a lot of Developers recently adopting SQLite for their database and I wonder why this is.<\/p>\n\n<p>Laravel changed their default database to SQLite for local development.<\/p>\n\n<p>It simplifies the development environment as there's no need for a separate database like MySQL or MariaDB but, if you'll be using one of those in production, won't that cause more issues when you migrate your local application?<\/p>\n\n<p>Drupal supports using SQLite, but, other than for <a href=\"/atdc\">my automated testing course<\/a>, or when running automated tests, I've always used a MySQL or MariaDB database.<\/p>\n\n<p>Maybe this is something to keep an eye on and potentially use more for some scenarios in the future.<\/p>\n\n ",
|
||||
"value": "\n <p>I've noticed a lot of Developers recently adopting SQLite for their database and I wonder why this is.<\/p>\n\n<p>Laravel changed their default database to SQLite for local development.<\/p>\n\n<p>It simplifies the development environment as there's no need for a separate database like MySQL or MariaDB but, if you'll be using one of those in production, won't that cause more issues when you migrate your local application?<\/p>\n\n<p>Drupal supports using SQLite, but, other than for <a href=\"\/atdc\">my automated testing course<\/a>, or when running automated tests, I've always used a MySQL or MariaDB database.<\/p>\n\n<p>Maybe this is something to keep an eye on and potentially use more for some scenarios in the future.<\/p>\n\n ",
|
||||
"format": "full_html",
|
||||
"processed": "\n <p>I've noticed a lot of Developers recently adopting SQLite for their database and I wonder why this is.<\/p>\n\n<p>Laravel changed their default database to SQLite for local development.<\/p>\n\n<p>It simplifies the development environment as there's no need for a separate database like MySQL or MariaDB but, if you'll be using one of those in production, won't that cause more issues when you migrate your local application?<\/p>\n\n<p>Drupal supports using SQLite, but, other than for <a href=\"/atdc\">my automated testing course<\/a>, or when running automated tests, I've always used a MySQL or MariaDB database.<\/p>\n\n<p>Maybe this is something to keep an eye on and potentially use more for some scenarios in the future.<\/p>\n\n ",
|
||||
"processed": "\n <p>I've noticed a lot of Developers recently adopting SQLite for their database and I wonder why this is.<\/p>\n\n<p>Laravel changed their default database to SQLite for local development.<\/p>\n\n<p>It simplifies the development environment as there's no need for a separate database like MySQL or MariaDB but, if you'll be using one of those in production, won't that cause more issues when you migrate your local application?<\/p>\n\n<p>Drupal supports using SQLite, but, other than for <a href=\"http:\/\/default\/atdc\">my automated testing course<\/a>, or when running automated tests, I've always used a MySQL or MariaDB database.<\/p>\n\n<p>Maybe this is something to keep an eye on and potentially use more for some scenarios in the future.<\/p>\n\n ",
|
||||
"summary": null
|
||||
}
|
||||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "91a7ebf19cb056c110911fc721129f1a",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -104,5 +104,6 @@
|
|||
"target_type": "taxonomy_term",
|
||||
"target_uuid": "f9b1ec5f-2fdb-438c-a266-082a86a6d94f"
|
||||
}
|
||||
]
|
||||
],
|
||||
"field_topic": []
|
||||
}
|
||||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "838a5e92a344c70d064478815bc8dd16",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "957b36c5f9d9b70a87a9a60d1f31f9ab",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -82,15 +82,15 @@
|
|||
],
|
||||
"body": [
|
||||
{
|
||||
"value": "\n <p>As well as <a href=\"/daily\/2024\/06\/03\/writing-comments-first\">writing comments first<\/a>, when writing tests, I sometimes like to write my tests backwards and start by writing the assertions first.<\/p>\n\n<p>I know what I want to assert in the test, so it's an easy place to start.<\/p>\n\n<p>I'll run it, see the error, fix it and continue working backwards.<\/p>\n\n<p>For example, I could start with this:<\/p>\n\n<pre><code class=\"php\">public function testOnlyPostNodesAreShown(): void {\n $assert = $this->assertSession();\n $assert->pageTextContains('Post one');\n $assert->pageTextContains('Post two');\n $assert->pageTextNotContains('This is not a post');\n}\n<\/code><\/pre>\n\n<p>This test will fail when I run it, but it makes me think about what I need to do to fix the error and how to do so in the best way.<\/p>\n\n<p>In this case, I need to make a request to the page that should render the text:<\/p>\n\n<pre><code class=\"php\">public function testOnlyPostNodesAreShown(): void {\n $this->drupalGet('\/blog');\n\n $assert = $this->assertSession();\n $assert->pageTextContains('Post one');\n $assert->pageTextContains('Post two');\n $assert->pageTextNotContains('This is not a post');\n}\n<\/code><\/pre>\n\n<p>This will still fail, as I also need to create the required posts:<\/p>\n\n<pre><code class=\"php\">public function testOnlyPostNodesAreShown(): void {\n PostBuilder::create()->setTitle('Post one')->getPost();\n PostBuilder::create()->setTitle('Post two')->getPost();\n\n $this->createNode([\n 'title' => 'This is not a post',\n 'type' => 'page',\n ]);\n\n $this->drupalGet('\/blog');\n\n $assert = $this->assertSession();\n $assert->pageTextContains('Post one');\n $assert->pageTextContains('Post two');\n $assert->pageTextNotContains('This is not a post');\n}\n<\/code><\/pre>\n\n<p>Now the test passes.<\/p>\n\n<p>Doing test-driven development keeps my code clean and minimal, and I find this approach keeps my test clean, too.<\/p>\n\n ",
|
||||
"value": "\n <p>As well as <a href=\"\/daily\/2024\/06\/03\/writing-comments-first\">writing comments first<\/a>, when writing tests, I sometimes like to write my tests backwards and start by writing the assertions first.<\/p>\n\n<p>I know what I want to assert in the test, so it's an easy place to start.<\/p>\n\n<p>I'll run it, see the error, fix it and continue working backwards.<\/p>\n\n<p>For example, I could start with this:<\/p>\n\n<pre><code class=\"php\">public function testOnlyPostNodesAreShown(): void {\n $assert = $this->assertSession();\n $assert->pageTextContains('Post one');\n $assert->pageTextContains('Post two');\n $assert->pageTextNotContains('This is not a post');\n}\n<\/code><\/pre>\n\n<p>This test will fail when I run it, but it makes me think about what I need to do to fix the error and how to do so in the best way.<\/p>\n\n<p>In this case, I need to make a request to the page that should render the text:<\/p>\n\n<pre><code class=\"php\">public function testOnlyPostNodesAreShown(): void {\n $this->drupalGet('\/blog');\n\n $assert = $this->assertSession();\n $assert->pageTextContains('Post one');\n $assert->pageTextContains('Post two');\n $assert->pageTextNotContains('This is not a post');\n}\n<\/code><\/pre>\n\n<p>This will still fail, as I also need to create the required posts:<\/p>\n\n<pre><code class=\"php\">public function testOnlyPostNodesAreShown(): void {\n PostBuilder::create()->setTitle('Post one')->getPost();\n PostBuilder::create()->setTitle('Post two')->getPost();\n\n $this->createNode([\n 'title' => 'This is not a post',\n 'type' => 'page',\n ]);\n\n $this->drupalGet('\/blog');\n\n $assert = $this->assertSession();\n $assert->pageTextContains('Post one');\n $assert->pageTextContains('Post two');\n $assert->pageTextNotContains('This is not a post');\n}\n<\/code><\/pre>\n\n<p>Now the test passes.<\/p>\n\n<p>Doing test-driven development keeps my code clean and minimal, and I find this approach keeps my test clean, too.<\/p>\n\n ",
|
||||
"format": "full_html",
|
||||
"processed": "\n <p>As well as <a href=\"/daily\/2024\/06\/03\/writing-comments-first\">writing comments first<\/a>, when writing tests, I sometimes like to write my tests backwards and start by writing the assertions first.<\/p>\n\n<p>I know what I want to assert in the test, so it's an easy place to start.<\/p>\n\n<p>I'll run it, see the error, fix it and continue working backwards.<\/p>\n\n<p>For example, I could start with this:<\/p>\n\n<pre><code class=\"php\">public function testOnlyPostNodesAreShown(): void {\n $assert = $this->assertSession();\n $assert->pageTextContains('Post one');\n $assert->pageTextContains('Post two');\n $assert->pageTextNotContains('This is not a post');\n}\n<\/code><\/pre>\n\n<p>This test will fail when I run it, but it makes me think about what I need to do to fix the error and how to do so in the best way.<\/p>\n\n<p>In this case, I need to make a request to the page that should render the text:<\/p>\n\n<pre><code class=\"php\">public function testOnlyPostNodesAreShown(): void {\n $this->drupalGet('\/blog');\n\n $assert = $this->assertSession();\n $assert->pageTextContains('Post one');\n $assert->pageTextContains('Post two');\n $assert->pageTextNotContains('This is not a post');\n}\n<\/code><\/pre>\n\n<p>This will still fail, as I also need to create the required posts:<\/p>\n\n<pre><code class=\"php\">public function testOnlyPostNodesAreShown(): void {\n PostBuilder::create()->setTitle('Post one')->getPost();\n PostBuilder::create()->setTitle('Post two')->getPost();\n\n $this->createNode([\n 'title' => 'This is not a post',\n 'type' => 'page',\n ]);\n\n $this->drupalGet('\/blog');\n\n $assert = $this->assertSession();\n $assert->pageTextContains('Post one');\n $assert->pageTextContains('Post two');\n $assert->pageTextNotContains('This is not a post');\n}\n<\/code><\/pre>\n\n<p>Now the test passes.<\/p>\n\n<p>Doing test-driven development keeps my code clean and minimal, and I find this approach keeps my test clean, too.<\/p>\n\n ",
|
||||
"processed": "\n <p>As well as <a href=\"http:\/\/default\/daily\/2024\/06\/03\/writing-comments-first\">writing comments first<\/a>, when writing tests, I sometimes like to write my tests backwards and start by writing the assertions first.<\/p>\n\n<p>I know what I want to assert in the test, so it's an easy place to start.<\/p>\n\n<p>I'll run it, see the error, fix it and continue working backwards.<\/p>\n\n<p>For example, I could start with this:<\/p>\n\n<pre><code class=\"php\">public function testOnlyPostNodesAreShown(): void {\n $assert = $this->assertSession();\n $assert->pageTextContains('Post one');\n $assert->pageTextContains('Post two');\n $assert->pageTextNotContains('This is not a post');\n}\n<\/code><\/pre>\n\n<p>This test will fail when I run it, but it makes me think about what I need to do to fix the error and how to do so in the best way.<\/p>\n\n<p>In this case, I need to make a request to the page that should render the text:<\/p>\n\n<pre><code class=\"php\">public function testOnlyPostNodesAreShown(): void {\n $this->drupalGet('\/blog');\n\n $assert = $this->assertSession();\n $assert->pageTextContains('Post one');\n $assert->pageTextContains('Post two');\n $assert->pageTextNotContains('This is not a post');\n}\n<\/code><\/pre>\n\n<p>This will still fail, as I also need to create the required posts:<\/p>\n\n<pre><code class=\"php\">public function testOnlyPostNodesAreShown(): void {\n PostBuilder::create()->setTitle('Post one')->getPost();\n PostBuilder::create()->setTitle('Post two')->getPost();\n\n $this->createNode([\n 'title' => 'This is not a post',\n 'type' => 'page',\n ]);\n\n $this->drupalGet('\/blog');\n\n $assert = $this->assertSession();\n $assert->pageTextContains('Post one');\n $assert->pageTextContains('Post two');\n $assert->pageTextNotContains('This is not a post');\n}\n<\/code><\/pre>\n\n<p>Now the test passes.<\/p>\n\n<p>Doing test-driven development keeps my code clean and minimal, and I find this approach keeps my test clean, too.<\/p>\n\n ",
|
||||
"summary": null
|
||||
}
|
||||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "3bdc81d1ff8f05f8b1beb3069dfdd370",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "2955d4cb562bc0a9ba0456bc040c629b",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -82,15 +82,15 @@
|
|||
],
|
||||
"body": [
|
||||
{
|
||||
"value": "\n <p>It's shown in the examples of the <a href=\"/daily\/2023\/11\/24\/are-conventional-commits-worth-it\">conventional commits specification<\/a> as part of the optional footer data.<\/p>\n\n<p>But is it useful?<\/p>\n\n<p>It can be if your issue tracker is linked to your Git repository and you can click the issue ID in a commit message and see the issue.<\/p>\n\n<p>But, how often do teams change issue-tracking software or the project is passed to a different company that uses a different issue tracker?<\/p>\n\n<p>That makes the issue IDs that reference the old IDs useless as no one has access to the issues it references.<\/p>\n\n<p>I'd recommend putting as much information in the commit message itself and not relying on it being in an external source, like an issue tracker.<\/p>\n\n<p>The Git log and commit messages will remain even if a different issue tracker is used, or a different team starts working on the project, and that additional information isn't lost.<\/p>\n\n<p>I'm not against putting the issue ID in the commit message but don't do it instead of writing a descriptive commit message.<\/p>\n\n ",
|
||||
"value": "\n <p>It's shown in the examples of the <a href=\"\/daily\/2023\/11\/24\/are-conventional-commits-worth-it\">conventional commits specification<\/a> as part of the optional footer data.<\/p>\n\n<p>But is it useful?<\/p>\n\n<p>It can be if your issue tracker is linked to your Git repository and you can click the issue ID in a commit message and see the issue.<\/p>\n\n<p>But, how often do teams change issue-tracking software or the project is passed to a different company that uses a different issue tracker?<\/p>\n\n<p>That makes the issue IDs that reference the old IDs useless as no one has access to the issues it references.<\/p>\n\n<p>I'd recommend putting as much information in the commit message itself and not relying on it being in an external source, like an issue tracker.<\/p>\n\n<p>The Git log and commit messages will remain even if a different issue tracker is used, or a different team starts working on the project, and that additional information isn't lost.<\/p>\n\n<p>I'm not against putting the issue ID in the commit message but don't do it instead of writing a descriptive commit message.<\/p>\n\n ",
|
||||
"format": "full_html",
|
||||
"processed": "\n <p>It's shown in the examples of the <a href=\"/daily\/2023\/11\/24\/are-conventional-commits-worth-it\">conventional commits specification<\/a> as part of the optional footer data.<\/p>\n\n<p>But is it useful?<\/p>\n\n<p>It can be if your issue tracker is linked to your Git repository and you can click the issue ID in a commit message and see the issue.<\/p>\n\n<p>But, how often do teams change issue-tracking software or the project is passed to a different company that uses a different issue tracker?<\/p>\n\n<p>That makes the issue IDs that reference the old IDs useless as no one has access to the issues it references.<\/p>\n\n<p>I'd recommend putting as much information in the commit message itself and not relying on it being in an external source, like an issue tracker.<\/p>\n\n<p>The Git log and commit messages will remain even if a different issue tracker is used, or a different team starts working on the project, and that additional information isn't lost.<\/p>\n\n<p>I'm not against putting the issue ID in the commit message but don't do it instead of writing a descriptive commit message.<\/p>\n\n ",
|
||||
"processed": "\n <p>It's shown in the examples of the <a href=\"http:\/\/default\/daily\/2023\/11\/24\/are-conventional-commits-worth-it\">conventional commits specification<\/a> as part of the optional footer data.<\/p>\n\n<p>But is it useful?<\/p>\n\n<p>It can be if your issue tracker is linked to your Git repository and you can click the issue ID in a commit message and see the issue.<\/p>\n\n<p>But, how often do teams change issue-tracking software or the project is passed to a different company that uses a different issue tracker?<\/p>\n\n<p>That makes the issue IDs that reference the old IDs useless as no one has access to the issues it references.<\/p>\n\n<p>I'd recommend putting as much information in the commit message itself and not relying on it being in an external source, like an issue tracker.<\/p>\n\n<p>The Git log and commit messages will remain even if a different issue tracker is used, or a different team starts working on the project, and that additional information isn't lost.<\/p>\n\n<p>I'm not against putting the issue ID in the commit message but don't do it instead of writing a descriptive commit message.<\/p>\n\n ",
|
||||
"summary": null
|
||||
}
|
||||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "1029a860138fe970164e891ad1617d01",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "f40826212e5c798e718edd8ad155d3c0",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -82,15 +82,15 @@
|
|||
],
|
||||
"body": [
|
||||
{
|
||||
"value": "\n <p>I took a bit of time off from these emails whilst I was preparing for the first PHP Stoke event which happened last week in Stoke-on-Trent.<\/p>\n\n<p>It was a great event with around 35 attendees and two other speakers as well as myself.<\/p>\n\n<p>The <a href=\"/presentations\/things-you-should-know-about-php\">latest version of my slides are online<\/a> as well <a href=\"/things-about-php\">some updated resources<\/a>.<\/p>\n\n<p>My next talk will be at the Norfolk Developers conference next month where I'll be presenting an updated version of <a href=\"/presentations\/taking-flight-with-tailwind-css\">Taking Flight with Tailwind CSS<\/a>.<\/p>\n\n<p>If you have a topic idea for a talk or would like me to speak at your meetup or conference, please get in touch.<\/p>\n\n ",
|
||||
"value": "\n <p>I took a bit of time off from these emails whilst I was preparing for the first PHP Stoke event which happened last week in Stoke-on-Trent.<\/p>\n\n<p>It was a great event with around 35 attendees and two other speakers as well as myself.<\/p>\n\n<p>The <a href=\"\/presentations\/things-you-should-know-about-php\">latest version of my slides are online<\/a> as well <a href=\"\/things-about-php\">some updated resources<\/a>.<\/p>\n\n<p>My next talk will be at the Norfolk Developers conference next month where I'll be presenting an updated version of <a href=\"\/presentations\/taking-flight-with-tailwind-css\">Taking Flight with Tailwind CSS<\/a>.<\/p>\n\n<p>If you have a topic idea for a talk or would like me to speak at your meetup or conference, please get in touch.<\/p>\n\n ",
|
||||
"format": "full_html",
|
||||
"processed": "\n <p>I took a bit of time off from these emails whilst I was preparing for the first PHP Stoke event which happened last week in Stoke-on-Trent.<\/p>\n\n<p>It was a great event with around 35 attendees and two other speakers as well as myself.<\/p>\n\n<p>The <a href=\"/presentations\/things-you-should-know-about-php\">latest version of my slides are online<\/a> as well <a href=\"/things-about-php\">some updated resources<\/a>.<\/p>\n\n<p>My next talk will be at the Norfolk Developers conference next month where I'll be presenting an updated version of <a href=\"/presentations\/taking-flight-with-tailwind-css\">Taking Flight with Tailwind CSS<\/a>.<\/p>\n\n<p>If you have a topic idea for a talk or would like me to speak at your meetup or conference, please get in touch.<\/p>\n\n ",
|
||||
"processed": "\n <p>I took a bit of time off from these emails whilst I was preparing for the first PHP Stoke event which happened last week in Stoke-on-Trent.<\/p>\n\n<p>It was a great event with around 35 attendees and two other speakers as well as myself.<\/p>\n\n<p>The <a href=\"http:\/\/default\/presentations\/things-you-should-know-about-php\">latest version of my slides are online<\/a> as well <a href=\"http:\/\/default\/things-about-php\">some updated resources<\/a>.<\/p>\n\n<p>My next talk will be at the Norfolk Developers conference next month where I'll be presenting an updated version of <a href=\"http:\/\/default\/presentations\/taking-flight-with-tailwind-css\">Taking Flight with Tailwind CSS<\/a>.<\/p>\n\n<p>If you have a topic idea for a talk or would like me to speak at your meetup or conference, please get in touch.<\/p>\n\n ",
|
||||
"summary": null
|
||||
}
|
||||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "c6186e7dbf6c19f8512dc083f70d7840",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "48855aeeae21e4c8f58c4898ddd9fea4",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "1c6afa84bf0230b6fc71cdc42239c6e2",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "6e7b86e1b92a964e048c10b4a1bb65da",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -82,15 +82,15 @@
|
|||
],
|
||||
"body": [
|
||||
{
|
||||
"value": "\n <p>I've been using Drupal since 2008 and built the first version of my website with Drupal 6 before updating it to Drupal 7.<\/p>\n\n<p>Around that time, I discovered static site generators and built the next version of my website with Jekyll.<\/p>\n\n<p>I liked how I could write content in simple plain files, export them to HTML and upload them to a server.<\/p>\n\n<p>Static websites are fast and secure.<\/p>\n\n<p>There was no need for PHP or a database. Just a simple web server like Apache or Nginx that can serve static files.<\/p>\n\n<p>I later switched to Sculpin, a static site generator written with PHP, which has a lot of similarities with Drupal.<\/p>\n\n<p>But what if you want the power of Drupal with the benefits of a static website?<\/p>\n\n<p><a href=\"https:\/\/www.drupal.org\/project\/tome\">Tome<\/a> is a module that turns Drupal into a static site generator.<\/p>\n\n<p>Drupal works the same locally with access to all the usual core functionality and contrib modules and themes from Drupal.org, but you export everything to static files - the same as using Jekyll or Sculpin.<\/p>\n\n<p>Sam Mortenson, the creator of the Tome module discussed it on <a href=\"/podcast\/19-sam-mortenson\">our episode of the Beyond Blocks podcast<\/a> where we also talked about single file components.<\/p>\n\n<p>If you want the power of a flexible content management system and the performance and security benefits of a static website, Tome gives you the best of both worlds.<\/p>\n\n ",
|
||||
"value": "\n <p>I've been using Drupal since 2008 and built the first version of my website with Drupal 6 before updating it to Drupal 7.<\/p>\n\n<p>Around that time, I discovered static site generators and built the next version of my website with Jekyll.<\/p>\n\n<p>I liked how I could write content in simple plain files, export them to HTML and upload them to a server.<\/p>\n\n<p>Static websites are fast and secure.<\/p>\n\n<p>There was no need for PHP or a database. Just a simple web server like Apache or Nginx that can serve static files.<\/p>\n\n<p>I later switched to Sculpin, a static site generator written with PHP, which has a lot of similarities with Drupal.<\/p>\n\n<p>But what if you want the power of Drupal with the benefits of a static website?<\/p>\n\n<p><a href=\"https:\/\/www.drupal.org\/project\/tome\">Tome<\/a> is a module that turns Drupal into a static site generator.<\/p>\n\n<p>Drupal works the same locally with access to all the usual core functionality and contrib modules and themes from Drupal.org, but you export everything to static files - the same as using Jekyll or Sculpin.<\/p>\n\n<p>Sam Mortenson, the creator of the Tome module discussed it on <a href=\"\/podcast\/19-sam-mortenson\">our episode of the Beyond Blocks podcast<\/a> where we also talked about single file components.<\/p>\n\n<p>If you want the power of a flexible content management system and the performance and security benefits of a static website, Tome gives you the best of both worlds.<\/p>\n\n ",
|
||||
"format": "full_html",
|
||||
"processed": "\n <p>I've been using Drupal since 2008 and built the first version of my website with Drupal 6 before updating it to Drupal 7.<\/p>\n\n<p>Around that time, I discovered static site generators and built the next version of my website with Jekyll.<\/p>\n\n<p>I liked how I could write content in simple plain files, export them to HTML and upload them to a server.<\/p>\n\n<p>Static websites are fast and secure.<\/p>\n\n<p>There was no need for PHP or a database. Just a simple web server like Apache or Nginx that can serve static files.<\/p>\n\n<p>I later switched to Sculpin, a static site generator written with PHP, which has a lot of similarities with Drupal.<\/p>\n\n<p>But what if you want the power of Drupal with the benefits of a static website?<\/p>\n\n<p><a href=\"https:\/\/www.drupal.org\/project\/tome\">Tome<\/a> is a module that turns Drupal into a static site generator.<\/p>\n\n<p>Drupal works the same locally with access to all the usual core functionality and contrib modules and themes from Drupal.org, but you export everything to static files - the same as using Jekyll or Sculpin.<\/p>\n\n<p>Sam Mortenson, the creator of the Tome module discussed it on <a href=\"/podcast\/19-sam-mortenson\">our episode of the Beyond Blocks podcast<\/a> where we also talked about single file components.<\/p>\n\n<p>If you want the power of a flexible content management system and the performance and security benefits of a static website, Tome gives you the best of both worlds.<\/p>\n\n ",
|
||||
"processed": "\n <p>I've been using Drupal since 2008 and built the first version of my website with Drupal 6 before updating it to Drupal 7.<\/p>\n\n<p>Around that time, I discovered static site generators and built the next version of my website with Jekyll.<\/p>\n\n<p>I liked how I could write content in simple plain files, export them to HTML and upload them to a server.<\/p>\n\n<p>Static websites are fast and secure.<\/p>\n\n<p>There was no need for PHP or a database. Just a simple web server like Apache or Nginx that can serve static files.<\/p>\n\n<p>I later switched to Sculpin, a static site generator written with PHP, which has a lot of similarities with Drupal.<\/p>\n\n<p>But what if you want the power of Drupal with the benefits of a static website?<\/p>\n\n<p><a href=\"https:\/\/www.drupal.org\/project\/tome\">Tome<\/a> is a module that turns Drupal into a static site generator.<\/p>\n\n<p>Drupal works the same locally with access to all the usual core functionality and contrib modules and themes from Drupal.org, but you export everything to static files - the same as using Jekyll or Sculpin.<\/p>\n\n<p>Sam Mortenson, the creator of the Tome module discussed it on <a href=\"http:\/\/default\/podcast\/19-sam-mortenson\">our episode of the Beyond Blocks podcast<\/a> where we also talked about single file components.<\/p>\n\n<p>If you want the power of a flexible content management system and the performance and security benefits of a static website, Tome gives you the best of both worlds.<\/p>\n\n ",
|
||||
"summary": null
|
||||
}
|
||||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "2b68ef78311dde7624d8a9f3bf2aecd5",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "6878d25dc442270921c029ddd00724c8",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "2a66b63393fa72ffccd1e378ef840bca",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -82,15 +82,15 @@
|
|||
],
|
||||
"body": [
|
||||
{
|
||||
"value": "\n <p>Yesterday I replied to <a href=\"https:\/\/x.com\/ianmiell\/status\/1304103008242991111\">a post on X<\/a>:<\/p>\n\n<blockquote>\n <p>I have worked on many teams that use CI tooling and call their process CI, but I have never seen CI actually done as defined on Wikipedia:<\/p>\n \n <p>\"CI is the practice of merging all developers' working copies to a shared mainline several times a day\"<\/p>\n<\/blockquote>\n\n<p><a href=\"/blog\/continuous-integration-vs-continuous-integration\">I've written about this before<\/a> and I think the term CI or CI\/CD is one of the most misused or misleading in software development.<\/p>\n\n<p>CI, or continuous integration, is, as the post days, the process of everyone merging their changes at least once, or usually several, times a day.<\/p>\n\n<p>It isn't something that is configured or created - it's a process.<\/p>\n\n<h2 id=\"here%27s-the-thing\">Here's the thing<\/h2>\n\n<p>You can do CI without a CI pipeline and vice versa.<\/p>\n\n<p>You can have a CI pipeline but not do continuous delivery or deployment.<\/p>\n\n<p>What most people think of as CI or CI\/CD is a set of automated checks that run when code is updated - usually on a feature or topic branch.<\/p>\n\n<p>Whilst important, it's not \"CI\".<\/p>\n\n ",
|
||||
"value": "\n <p>Yesterday I replied to <a href=\"https:\/\/x.com\/ianmiell\/status\/1304103008242991111\">a post on X<\/a>:<\/p>\n\n<blockquote>\n <p>I have worked on many teams that use CI tooling and call their process CI, but I have never seen CI actually done as defined on Wikipedia:<\/p>\n \n <p>\"CI is the practice of merging all developers' working copies to a shared mainline several times a day\"<\/p>\n<\/blockquote>\n\n<p><a href=\"\/blog\/continuous-integration-vs-continuous-integration\">I've written about this before<\/a> and I think the term CI or CI\/CD is one of the most misused or misleading in software development.<\/p>\n\n<p>CI, or continuous integration, is, as the post days, the process of everyone merging their changes at least once, or usually several, times a day.<\/p>\n\n<p>It isn't something that is configured or created - it's a process.<\/p>\n\n<h2 id=\"here%27s-the-thing\">Here's the thing<\/h2>\n\n<p>You can do CI without a CI pipeline and vice versa.<\/p>\n\n<p>You can have a CI pipeline but not do continuous delivery or deployment.<\/p>\n\n<p>What most people think of as CI or CI\/CD is a set of automated checks that run when code is updated - usually on a feature or topic branch.<\/p>\n\n<p>Whilst important, it's not \"CI\".<\/p>\n\n ",
|
||||
"format": "full_html",
|
||||
"processed": "\n <p>Yesterday I replied to <a href=\"https:\/\/x.com\/ianmiell\/status\/1304103008242991111\">a post on X<\/a>:<\/p>\n\n<blockquote>\n <p>I have worked on many teams that use CI tooling and call their process CI, but I have never seen CI actually done as defined on Wikipedia:<\/p>\n \n <p>\"CI is the practice of merging all developers' working copies to a shared mainline several times a day\"<\/p>\n<\/blockquote>\n\n<p><a href=\"/blog\/continuous-integration-vs-continuous-integration\">I've written about this before<\/a> and I think the term CI or CI\/CD is one of the most misused or misleading in software development.<\/p>\n\n<p>CI, or continuous integration, is, as the post days, the process of everyone merging their changes at least once, or usually several, times a day.<\/p>\n\n<p>It isn't something that is configured or created - it's a process.<\/p>\n\n<h2 id=\"here%27s-the-thing\">Here's the thing<\/h2>\n\n<p>You can do CI without a CI pipeline and vice versa.<\/p>\n\n<p>You can have a CI pipeline but not do continuous delivery or deployment.<\/p>\n\n<p>What most people think of as CI or CI\/CD is a set of automated checks that run when code is updated - usually on a feature or topic branch.<\/p>\n\n<p>Whilst important, it's not \"CI\".<\/p>\n\n ",
|
||||
"processed": "\n <p>Yesterday I replied to <a href=\"https:\/\/x.com\/ianmiell\/status\/1304103008242991111\">a post on X<\/a>:<\/p>\n\n<blockquote>\n <p>I have worked on many teams that use CI tooling and call their process CI, but I have never seen CI actually done as defined on Wikipedia:<\/p>\n \n <p>\"CI is the practice of merging all developers' working copies to a shared mainline several times a day\"<\/p>\n<\/blockquote>\n\n<p><a href=\"http:\/\/default\/blog\/continuous-integration-vs-continuous-integration\">I've written about this before<\/a> and I think the term CI or CI\/CD is one of the most misused or misleading in software development.<\/p>\n\n<p>CI, or continuous integration, is, as the post days, the process of everyone merging their changes at least once, or usually several, times a day.<\/p>\n\n<p>It isn't something that is configured or created - it's a process.<\/p>\n\n<h2 id=\"here%27s-the-thing\">Here's the thing<\/h2>\n\n<p>You can do CI without a CI pipeline and vice versa.<\/p>\n\n<p>You can have a CI pipeline but not do continuous delivery or deployment.<\/p>\n\n<p>What most people think of as CI or CI\/CD is a set of automated checks that run when code is updated - usually on a feature or topic branch.<\/p>\n\n<p>Whilst important, it's not \"CI\".<\/p>\n\n ",
|
||||
"summary": null
|
||||
}
|
||||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "44876b1c656f7fa3e4611f4f47e7c361",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -82,15 +82,15 @@
|
|||
],
|
||||
"body": [
|
||||
{
|
||||
"value": "\n <p>Last Friday and Saturday, I was happy to attend and present two sessions at DrupalCamp Ghent in Belgium.<\/p>\n\n<p>I was able to present talks on automated testing and Tailwind CSS, which were my 99th and 100th talks, respectively!<\/p>\n\n<p>The sessions were streamed live, or the slides and previous recordings <a href=\"/dcg\">are on my website<\/a>.<\/p>\n\n<p>It was a great event and it's always nice to see and meet new people within the Drupal community, to see new places and share knowledge by giving presentations.<\/p>\n\n<p>Reply and let me know if you have any feedback on the sessions or if you'd like me to present a talk or workshop at your event.<\/p>\n\n ",
|
||||
"value": "\n <p>Last Friday and Saturday, I was happy to attend and present two sessions at DrupalCamp Ghent in Belgium.<\/p>\n\n<p>I was able to present talks on automated testing and Tailwind CSS, which were my 99th and 100th talks, respectively!<\/p>\n\n<p>The sessions were streamed live, or the slides and previous recordings <a href=\"\/dcg\">are on my website<\/a>.<\/p>\n\n<p>It was a great event and it's always nice to see and meet new people within the Drupal community, to see new places and share knowledge by giving presentations.<\/p>\n\n<p>Reply and let me know if you have any feedback on the sessions or if you'd like me to present a talk or workshop at your event.<\/p>\n\n ",
|
||||
"format": "full_html",
|
||||
"processed": "\n <p>Last Friday and Saturday, I was happy to attend and present two sessions at DrupalCamp Ghent in Belgium.<\/p>\n\n<p>I was able to present talks on automated testing and Tailwind CSS, which were my 99th and 100th talks, respectively!<\/p>\n\n<p>The sessions were streamed live, or the slides and previous recordings <a href=\"/dcg\">are on my website<\/a>.<\/p>\n\n<p>It was a great event and it's always nice to see and meet new people within the Drupal community, to see new places and share knowledge by giving presentations.<\/p>\n\n<p>Reply and let me know if you have any feedback on the sessions or if you'd like me to present a talk or workshop at your event.<\/p>\n\n ",
|
||||
"processed": "\n <p>Last Friday and Saturday, I was happy to attend and present two sessions at DrupalCamp Ghent in Belgium.<\/p>\n\n<p>I was able to present talks on automated testing and Tailwind CSS, which were my 99th and 100th talks, respectively!<\/p>\n\n<p>The sessions were streamed live, or the slides and previous recordings <a href=\"http:\/\/default\/dcg\">are on my website<\/a>.<\/p>\n\n<p>It was a great event and it's always nice to see and meet new people within the Drupal community, to see new places and share knowledge by giving presentations.<\/p>\n\n<p>Reply and let me know if you have any feedback on the sessions or if you'd like me to present a talk or workshop at your event.<\/p>\n\n ",
|
||||
"summary": null
|
||||
}
|
||||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "666722719a2759d76794a08b3c2837fa",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "af41a18ab3e2e252ab86e7243333ad9f",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "aa56bdd02fef215659f339a51ad72312",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -82,15 +82,15 @@
|
|||
],
|
||||
"body": [
|
||||
{
|
||||
"value": "\n <p>If <a href=\"/daily\/2025\/02\/18\/conflicts\">feature branches cause conflicts<\/a>, what is the alternative?<\/p>\n\n<p>Don't branch.<\/p>\n\n<p>Keep all changes on a single branch and avoid merge conflicts between branches by not having branches.<\/p>\n\n<p>But how can you avoid releasing changes before they are ready?<\/p>\n\n<p>You can have a local branch with your changes that you don't push and rebase locally, but then <a href=\"/daily\/2025\/02\/17\/ci-cd\">you're not doing continuous integration<\/a> and you're just as likely to get conflicts and have incompatible code.<\/p>\n\n<p>One of the main benefits of trunk-based development, where everything is on a single branch, is that everyone's work always works together.<\/p>\n\n<p>The better option is to use feature toggles (aka feature flags).<\/p>\n\n<p>Wrapping code in feature toggles separates deploying the code from releasing the feature.<\/p>\n\n<p>The code can be released, but the feature isn't active until the toggle is enabled.<\/p>\n\n<p>This means everyone can work on the same branch and continuously deploy changes whilst being selective about the features that are visible to the end users.<\/p>\n\n<p>If you have multiple environments, the same code can be used with different toggles enabled to allow for testing different features.<\/p>\n\n<p>Then, once the feature is ready to be enabled, there is no deployment needed.<\/p>\n\n<p>The code is already there - it just needs to be enabled.<\/p>\n\n<p>For Drupal, there is a <a href=\"https:\/\/www.drupal.org\/project\/feature_toggle\">Feature Toggle module<\/a> and <a href=\"https:\/\/www.drupal.org\/project\/feature_toggle_twig\">an extension that I wrote<\/a> that make it easy to use and manage feature toggles by just logging into the admin UI and selecting the active toggles you want.<\/p>\n\n<p>And, if an issue is discovered, it can also be easily disabled <a href=\"/daily\/2025\/02\/19\/back-or-forward\">without needing to roll back to the previous version<\/a>.<\/p>\n\n ",
|
||||
"value": "\n <p>If <a href=\"\/daily\/2025\/02\/18\/conflicts\">feature branches cause conflicts<\/a>, what is the alternative?<\/p>\n\n<p>Don't branch.<\/p>\n\n<p>Keep all changes on a single branch and avoid merge conflicts between branches by not having branches.<\/p>\n\n<p>But how can you avoid releasing changes before they are ready?<\/p>\n\n<p>You can have a local branch with your changes that you don't push and rebase locally, but then <a href=\"\/daily\/2025\/02\/17\/ci-cd\">you're not doing continuous integration<\/a> and you're just as likely to get conflicts and have incompatible code.<\/p>\n\n<p>One of the main benefits of trunk-based development, where everything is on a single branch, is that everyone's work always works together.<\/p>\n\n<p>The better option is to use feature toggles (aka feature flags).<\/p>\n\n<p>Wrapping code in feature toggles separates deploying the code from releasing the feature.<\/p>\n\n<p>The code can be released, but the feature isn't active until the toggle is enabled.<\/p>\n\n<p>This means everyone can work on the same branch and continuously deploy changes whilst being selective about the features that are visible to the end users.<\/p>\n\n<p>If you have multiple environments, the same code can be used with different toggles enabled to allow for testing different features.<\/p>\n\n<p>Then, once the feature is ready to be enabled, there is no deployment needed.<\/p>\n\n<p>The code is already there - it just needs to be enabled.<\/p>\n\n<p>For Drupal, there is a <a href=\"https:\/\/www.drupal.org\/project\/feature_toggle\">Feature Toggle module<\/a> and <a href=\"https:\/\/www.drupal.org\/project\/feature_toggle_twig\">an extension that I wrote<\/a> that make it easy to use and manage feature toggles by just logging into the admin UI and selecting the active toggles you want.<\/p>\n\n<p>And, if an issue is discovered, it can also be easily disabled <a href=\"\/daily\/2025\/02\/19\/back-or-forward\">without needing to roll back to the previous version<\/a>.<\/p>\n\n ",
|
||||
"format": "full_html",
|
||||
"processed": "\n <p>If <a href=\"/daily\/2025\/02\/18\/conflicts\">feature branches cause conflicts<\/a>, what is the alternative?<\/p>\n\n<p>Don't branch.<\/p>\n\n<p>Keep all changes on a single branch and avoid merge conflicts between branches by not having branches.<\/p>\n\n<p>But how can you avoid releasing changes before they are ready?<\/p>\n\n<p>You can have a local branch with your changes that you don't push and rebase locally, but then <a href=\"/daily\/2025\/02\/17\/ci-cd\">you're not doing continuous integration<\/a> and you're just as likely to get conflicts and have incompatible code.<\/p>\n\n<p>One of the main benefits of trunk-based development, where everything is on a single branch, is that everyone's work always works together.<\/p>\n\n<p>The better option is to use feature toggles (aka feature flags).<\/p>\n\n<p>Wrapping code in feature toggles separates deploying the code from releasing the feature.<\/p>\n\n<p>The code can be released, but the feature isn't active until the toggle is enabled.<\/p>\n\n<p>This means everyone can work on the same branch and continuously deploy changes whilst being selective about the features that are visible to the end users.<\/p>\n\n<p>If you have multiple environments, the same code can be used with different toggles enabled to allow for testing different features.<\/p>\n\n<p>Then, once the feature is ready to be enabled, there is no deployment needed.<\/p>\n\n<p>The code is already there - it just needs to be enabled.<\/p>\n\n<p>For Drupal, there is a <a href=\"https:\/\/www.drupal.org\/project\/feature_toggle\">Feature Toggle module<\/a> and <a href=\"https:\/\/www.drupal.org\/project\/feature_toggle_twig\">an extension that I wrote<\/a> that make it easy to use and manage feature toggles by just logging into the admin UI and selecting the active toggles you want.<\/p>\n\n<p>And, if an issue is discovered, it can also be easily disabled <a href=\"/daily\/2025\/02\/19\/back-or-forward\">without needing to roll back to the previous version<\/a>.<\/p>\n\n ",
|
||||
"processed": "\n <p>If <a href=\"http:\/\/default\/daily\/2025\/02\/18\/conflicts\">feature branches cause conflicts<\/a>, what is the alternative?<\/p>\n\n<p>Don't branch.<\/p>\n\n<p>Keep all changes on a single branch and avoid merge conflicts between branches by not having branches.<\/p>\n\n<p>But how can you avoid releasing changes before they are ready?<\/p>\n\n<p>You can have a local branch with your changes that you don't push and rebase locally, but then <a href=\"http:\/\/default\/daily\/2025\/02\/17\/ci-cd\">you're not doing continuous integration<\/a> and you're just as likely to get conflicts and have incompatible code.<\/p>\n\n<p>One of the main benefits of trunk-based development, where everything is on a single branch, is that everyone's work always works together.<\/p>\n\n<p>The better option is to use feature toggles (aka feature flags).<\/p>\n\n<p>Wrapping code in feature toggles separates deploying the code from releasing the feature.<\/p>\n\n<p>The code can be released, but the feature isn't active until the toggle is enabled.<\/p>\n\n<p>This means everyone can work on the same branch and continuously deploy changes whilst being selective about the features that are visible to the end users.<\/p>\n\n<p>If you have multiple environments, the same code can be used with different toggles enabled to allow for testing different features.<\/p>\n\n<p>Then, once the feature is ready to be enabled, there is no deployment needed.<\/p>\n\n<p>The code is already there - it just needs to be enabled.<\/p>\n\n<p>For Drupal, there is a <a href=\"https:\/\/www.drupal.org\/project\/feature_toggle\">Feature Toggle module<\/a> and <a href=\"https:\/\/www.drupal.org\/project\/feature_toggle_twig\">an extension that I wrote<\/a> that make it easy to use and manage feature toggles by just logging into the admin UI and selecting the active toggles you want.<\/p>\n\n<p>And, if an issue is discovered, it can also be easily disabled <a href=\"http:\/\/default\/daily\/2025\/02\/19\/back-or-forward\">without needing to roll back to the previous version<\/a>.<\/p>\n\n ",
|
||||
"summary": null
|
||||
}
|
||||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "118c906a95ca0d083c79dec04035d210",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -82,15 +82,15 @@
|
|||
],
|
||||
"body": [
|
||||
{
|
||||
"value": "\n <p>Instead of <a href=\"/daily\/2024\/05\/31\/putting-glue-on-pizza\">using AI to autocomplete code<\/a> or <a href=\"/daily\/2024\/10\/08\/ai-in-drupal\">perform tasks within your Drupal website<\/a>, I've seen people using AI as a virtual pair programming partner.<\/p>\n\n<p>Similar to using a search engine or finding results on websites like Stack Overflow, but also being able to ask follow-up questions and for clarification as part of a conversation.<\/p>\n\n<p>You're still relying on its answers and advice to be correct, but using AI as a learning tool seems like a sensible approach if you don't have a non-AI pairing partner available.<\/p>\n\n<p>Just make sure to validate and verify whatever it gives you.<\/p>\n\n<p>Once you've committed it, you're responsible for it.<\/p>\n\n ",
|
||||
"value": "\n <p>Instead of <a href=\"\/daily\/2024\/05\/31\/putting-glue-on-pizza\">using AI to autocomplete code<\/a> or <a href=\"\/daily\/2024\/10\/08\/ai-in-drupal\">perform tasks within your Drupal website<\/a>, I've seen people using AI as a virtual pair programming partner.<\/p>\n\n<p>Similar to using a search engine or finding results on websites like Stack Overflow, but also being able to ask follow-up questions and for clarification as part of a conversation.<\/p>\n\n<p>You're still relying on its answers and advice to be correct, but using AI as a learning tool seems like a sensible approach if you don't have a non-AI pairing partner available.<\/p>\n\n<p>Just make sure to validate and verify whatever it gives you.<\/p>\n\n<p>Once you've committed it, you're responsible for it.<\/p>\n\n ",
|
||||
"format": "full_html",
|
||||
"processed": "\n <p>Instead of <a href=\"/daily\/2024\/05\/31\/putting-glue-on-pizza\">using AI to autocomplete code<\/a> or <a href=\"/daily\/2024\/10\/08\/ai-in-drupal\">perform tasks within your Drupal website<\/a>, I've seen people using AI as a virtual pair programming partner.<\/p>\n\n<p>Similar to using a search engine or finding results on websites like Stack Overflow, but also being able to ask follow-up questions and for clarification as part of a conversation.<\/p>\n\n<p>You're still relying on its answers and advice to be correct, but using AI as a learning tool seems like a sensible approach if you don't have a non-AI pairing partner available.<\/p>\n\n<p>Just make sure to validate and verify whatever it gives you.<\/p>\n\n<p>Once you've committed it, you're responsible for it.<\/p>\n\n ",
|
||||
"processed": "\n <p>Instead of <a href=\"http:\/\/default\/daily\/2024\/05\/31\/putting-glue-on-pizza\">using AI to autocomplete code<\/a> or <a href=\"http:\/\/default\/daily\/2024\/10\/08\/ai-in-drupal\">perform tasks within your Drupal website<\/a>, I've seen people using AI as a virtual pair programming partner.<\/p>\n\n<p>Similar to using a search engine or finding results on websites like Stack Overflow, but also being able to ask follow-up questions and for clarification as part of a conversation.<\/p>\n\n<p>You're still relying on its answers and advice to be correct, but using AI as a learning tool seems like a sensible approach if you don't have a non-AI pairing partner available.<\/p>\n\n<p>Just make sure to validate and verify whatever it gives you.<\/p>\n\n<p>Once you've committed it, you're responsible for it.<\/p>\n\n ",
|
||||
"summary": null
|
||||
}
|
||||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "e41c8f0126dd0649815f7d2f25e91bbc",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "3d0846676f872cb7c1f67b9afcb995ac",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "d138c01e7e0e6b18b39148606ce5111a",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "4f660d322ca2ed3306e781c6c10053a1",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -82,15 +82,15 @@
|
|||
],
|
||||
"body": [
|
||||
{
|
||||
"value": "\n <p>I've recently decided I'm going to open source <a href=\"/presentations\/building-build-configs\">Build Configs tool<\/a> that I use to generate build configuration files for Drupal, Sculpin and Fractal projects.<\/p>\n\n<p>Inspired by <a href=\"/presentations\/working-with-workspace\">Workspace<\/a> and others, and based on previous versions of similar tools - most recently by <a href=\"https:\/\/github.com\/ALT-F4-LLC\/build-configs\">TheAltF4Stream's project with the same name<\/a> (which is written in Rust and supports different template types) - I've been using this tool to manage configuration files for various personal, client and open-source projects.<\/p>\n\n<p>Before I open-source it, there are some changes I'd like to make, such as renaming some template types and updating the format and keys within the configuration file.<\/p>\n\n<p>Changes to the configuration file would be a breaking change and, whilst it's only me using it, I want my other projects to keep working and for me to continue supporting the prior versions - at least for now, so I want to make sure any changes are backward compatible.<\/p>\n\n<h2 id=\"how-it-works\">How it works<\/h2>\n\n<p>There are four steps performed when generating files for a project:<\/p>\n\n<ul>\n<li>Create a final configuration object from the project's configuration file as well as any defaults.<\/li>\n<li>Validate the final configuration.<\/li>\n<li>Create a list of files to generate.<\/li>\n<li>Generate the files.<\/li>\n<\/ul>\n\n<p>If I change <code>sculpin<\/code> to <code>sculpin-site<\/code> in a configuration file, for example, it will fail the validation step.<\/p>\n\n<p>But, I have an opportunity within the first step to perform any normalisation that's needed and to provide a compatibility layer - such as changing <code>sculpin-site<\/code>, which is an invalid value, to <code>sculpin<\/code>.<\/p>\n\n<p>I also renamed <code>symfony<\/code> to <code>symfony-cli<\/code> by performing the same step.<\/p>\n\n<p>This means the validation step will receive valid data that it can use and the new changes have been encapsulated within a single step of the process. I haven't needed to change any code elsewhere.<\/p>\n\n<p>I can also add deprecation warnings if legacy values are used.<\/p>\n\n<h2 id=\"here%27s-the-thing\">Here's the thing<\/h2>\n\n<p>Similar to feature flags, this is temporary code that will later be removed when I'm ready to remove the compatibility layer, similar to how <code>drupal_set_message()<\/code> was deprecated and changed to use the <code>Messenger<\/code> service before being removed in Drupal 9.<\/p>\n\n<p>In the future, I can refactor the internal logic to use a different approach and when I'm ready, eventually remove the compatibility layer and tag a new major version with the breaking changes.<\/p>\n\n ",
|
||||
"value": "\n <p>I've recently decided I'm going to open source <a href=\"\/presentations\/building-build-configs\">Build Configs tool<\/a> that I use to generate build configuration files for Drupal, Sculpin and Fractal projects.<\/p>\n\n<p>Inspired by <a href=\"\/presentations\/working-with-workspace\">Workspace<\/a> and others, and based on previous versions of similar tools - most recently by <a href=\"https:\/\/github.com\/ALT-F4-LLC\/build-configs\">TheAltF4Stream's project with the same name<\/a> (which is written in Rust and supports different template types) - I've been using this tool to manage configuration files for various personal, client and open-source projects.<\/p>\n\n<p>Before I open-source it, there are some changes I'd like to make, such as renaming some template types and updating the format and keys within the configuration file.<\/p>\n\n<p>Changes to the configuration file would be a breaking change and, whilst it's only me using it, I want my other projects to keep working and for me to continue supporting the prior versions - at least for now, so I want to make sure any changes are backward compatible.<\/p>\n\n<h2 id=\"how-it-works\">How it works<\/h2>\n\n<p>There are four steps performed when generating files for a project:<\/p>\n\n<ul>\n<li>Create a final configuration object from the project's configuration file as well as any defaults.<\/li>\n<li>Validate the final configuration.<\/li>\n<li>Create a list of files to generate.<\/li>\n<li>Generate the files.<\/li>\n<\/ul>\n\n<p>If I change <code>sculpin<\/code> to <code>sculpin-site<\/code> in a configuration file, for example, it will fail the validation step.<\/p>\n\n<p>But, I have an opportunity within the first step to perform any normalisation that's needed and to provide a compatibility layer - such as changing <code>sculpin-site<\/code>, which is an invalid value, to <code>sculpin<\/code>.<\/p>\n\n<p>I also renamed <code>symfony<\/code> to <code>symfony-cli<\/code> by performing the same step.<\/p>\n\n<p>This means the validation step will receive valid data that it can use and the new changes have been encapsulated within a single step of the process. I haven't needed to change any code elsewhere.<\/p>\n\n<p>I can also add deprecation warnings if legacy values are used.<\/p>\n\n<h2 id=\"here%27s-the-thing\">Here's the thing<\/h2>\n\n<p>Similar to feature flags, this is temporary code that will later be removed when I'm ready to remove the compatibility layer, similar to how <code>drupal_set_message()<\/code> was deprecated and changed to use the <code>Messenger<\/code> service before being removed in Drupal 9.<\/p>\n\n<p>In the future, I can refactor the internal logic to use a different approach and when I'm ready, eventually remove the compatibility layer and tag a new major version with the breaking changes.<\/p>\n\n ",
|
||||
"format": "full_html",
|
||||
"processed": "\n <p>I've recently decided I'm going to open source <a href=\"/presentations\/building-build-configs\">Build Configs tool<\/a> that I use to generate build configuration files for Drupal, Sculpin and Fractal projects.<\/p>\n\n<p>Inspired by <a href=\"/presentations\/working-with-workspace\">Workspace<\/a> and others, and based on previous versions of similar tools - most recently by <a href=\"https:\/\/github.com\/ALT-F4-LLC\/build-configs\">TheAltF4Stream's project with the same name<\/a> (which is written in Rust and supports different template types) - I've been using this tool to manage configuration files for various personal, client and open-source projects.<\/p>\n\n<p>Before I open-source it, there are some changes I'd like to make, such as renaming some template types and updating the format and keys within the configuration file.<\/p>\n\n<p>Changes to the configuration file would be a breaking change and, whilst it's only me using it, I want my other projects to keep working and for me to continue supporting the prior versions - at least for now, so I want to make sure any changes are backward compatible.<\/p>\n\n<h2 id=\"how-it-works\">How it works<\/h2>\n\n<p>There are four steps performed when generating files for a project:<\/p>\n\n<ul>\n<li>Create a final configuration object from the project's configuration file as well as any defaults.<\/li>\n<li>Validate the final configuration.<\/li>\n<li>Create a list of files to generate.<\/li>\n<li>Generate the files.<\/li>\n<\/ul>\n\n<p>If I change <code>sculpin<\/code> to <code>sculpin-site<\/code> in a configuration file, for example, it will fail the validation step.<\/p>\n\n<p>But, I have an opportunity within the first step to perform any normalisation that's needed and to provide a compatibility layer - such as changing <code>sculpin-site<\/code>, which is an invalid value, to <code>sculpin<\/code>.<\/p>\n\n<p>I also renamed <code>symfony<\/code> to <code>symfony-cli<\/code> by performing the same step.<\/p>\n\n<p>This means the validation step will receive valid data that it can use and the new changes have been encapsulated within a single step of the process. I haven't needed to change any code elsewhere.<\/p>\n\n<p>I can also add deprecation warnings if legacy values are used.<\/p>\n\n<h2 id=\"here%27s-the-thing\">Here's the thing<\/h2>\n\n<p>Similar to feature flags, this is temporary code that will later be removed when I'm ready to remove the compatibility layer, similar to how <code>drupal_set_message()<\/code> was deprecated and changed to use the <code>Messenger<\/code> service before being removed in Drupal 9.<\/p>\n\n<p>In the future, I can refactor the internal logic to use a different approach and when I'm ready, eventually remove the compatibility layer and tag a new major version with the breaking changes.<\/p>\n\n ",
|
||||
"processed": "\n <p>I've recently decided I'm going to open source <a href=\"http:\/\/default\/presentations\/building-build-configs\">Build Configs tool<\/a> that I use to generate build configuration files for Drupal, Sculpin and Fractal projects.<\/p>\n\n<p>Inspired by <a href=\"http:\/\/default\/presentations\/working-with-workspace\">Workspace<\/a> and others, and based on previous versions of similar tools - most recently by <a href=\"https:\/\/github.com\/ALT-F4-LLC\/build-configs\">TheAltF4Stream's project with the same name<\/a> (which is written in Rust and supports different template types) - I've been using this tool to manage configuration files for various personal, client and open-source projects.<\/p>\n\n<p>Before I open-source it, there are some changes I'd like to make, such as renaming some template types and updating the format and keys within the configuration file.<\/p>\n\n<p>Changes to the configuration file would be a breaking change and, whilst it's only me using it, I want my other projects to keep working and for me to continue supporting the prior versions - at least for now, so I want to make sure any changes are backward compatible.<\/p>\n\n<h2 id=\"how-it-works\">How it works<\/h2>\n\n<p>There are four steps performed when generating files for a project:<\/p>\n\n<ul>\n<li>Create a final configuration object from the project's configuration file as well as any defaults.<\/li>\n<li>Validate the final configuration.<\/li>\n<li>Create a list of files to generate.<\/li>\n<li>Generate the files.<\/li>\n<\/ul>\n\n<p>If I change <code>sculpin<\/code> to <code>sculpin-site<\/code> in a configuration file, for example, it will fail the validation step.<\/p>\n\n<p>But, I have an opportunity within the first step to perform any normalisation that's needed and to provide a compatibility layer - such as changing <code>sculpin-site<\/code>, which is an invalid value, to <code>sculpin<\/code>.<\/p>\n\n<p>I also renamed <code>symfony<\/code> to <code>symfony-cli<\/code> by performing the same step.<\/p>\n\n<p>This means the validation step will receive valid data that it can use and the new changes have been encapsulated within a single step of the process. I haven't needed to change any code elsewhere.<\/p>\n\n<p>I can also add deprecation warnings if legacy values are used.<\/p>\n\n<h2 id=\"here%27s-the-thing\">Here's the thing<\/h2>\n\n<p>Similar to feature flags, this is temporary code that will later be removed when I'm ready to remove the compatibility layer, similar to how <code>drupal_set_message()<\/code> was deprecated and changed to use the <code>Messenger<\/code> service before being removed in Drupal 9.<\/p>\n\n<p>In the future, I can refactor the internal logic to use a different approach and when I'm ready, eventually remove the compatibility layer and tag a new major version with the breaking changes.<\/p>\n\n ",
|
||||
"summary": null
|
||||
}
|
||||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "a38ce17b89e3700c2d33876324be5747",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "afe58adbc88026446b4472112f8ea2a7",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "00288ea28683ef7e8d770a0109344500",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "ed9692196aea3236ab447bca233fd4bc",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "e760bef0560b6cb431513a24b2eb0212",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "ef1660e036d0cc4b520bdd563fad7f86",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "e3227fd692a43f0f5a3b4f9afed9df94",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -82,15 +82,15 @@
|
|||
],
|
||||
"body": [
|
||||
{
|
||||
"value": "\n <p>A common misunderstanding for new Developers is that Git and GitHub are the same thing, but they aren't.<\/p>\n\n<p>Git is decentralised, so doesn't rely on using external repositories on services like GitHub, GitLab or Bitbucket.<\/p>\n\n<p>You can run <code>git init<\/code> and use it locally without pushing to any remote services.<\/p>\n\n<p>These services also add extra terminology, such as forks, syncing and pull or merge requests which aren't part of Git itself.<\/p>\n\n<p>This can cause confusion, which is why <a href=\"/daily\/2022\/08\/23\/git-gui-command-line\">I think it's important to learn Git itself<\/a> instead of relying on external services or desktop apps.<\/p>\n\n<p>And, if you're going to use a remote repository, consider something like Gitea, which you can host yourself and keep control of your data.<\/p>\n\n ",
|
||||
"value": "\n <p>A common misunderstanding for new Developers is that Git and GitHub are the same thing, but they aren't.<\/p>\n\n<p>Git is decentralised, so doesn't rely on using external repositories on services like GitHub, GitLab or Bitbucket.<\/p>\n\n<p>You can run <code>git init<\/code> and use it locally without pushing to any remote services.<\/p>\n\n<p>These services also add extra terminology, such as forks, syncing and pull or merge requests which aren't part of Git itself.<\/p>\n\n<p>This can cause confusion, which is why <a href=\"\/daily\/2022\/08\/23\/git-gui-command-line\">I think it's important to learn Git itself<\/a> instead of relying on external services or desktop apps.<\/p>\n\n<p>And, if you're going to use a remote repository, consider something like Gitea, which you can host yourself and keep control of your data.<\/p>\n\n ",
|
||||
"format": "full_html",
|
||||
"processed": "\n <p>A common misunderstanding for new Developers is that Git and GitHub are the same thing, but they aren't.<\/p>\n\n<p>Git is decentralised, so doesn't rely on using external repositories on services like GitHub, GitLab or Bitbucket.<\/p>\n\n<p>You can run <code>git init<\/code> and use it locally without pushing to any remote services.<\/p>\n\n<p>These services also add extra terminology, such as forks, syncing and pull or merge requests which aren't part of Git itself.<\/p>\n\n<p>This can cause confusion, which is why <a href=\"/daily\/2022\/08\/23\/git-gui-command-line\">I think it's important to learn Git itself<\/a> instead of relying on external services or desktop apps.<\/p>\n\n<p>And, if you're going to use a remote repository, consider something like Gitea, which you can host yourself and keep control of your data.<\/p>\n\n ",
|
||||
"processed": "\n <p>A common misunderstanding for new Developers is that Git and GitHub are the same thing, but they aren't.<\/p>\n\n<p>Git is decentralised, so doesn't rely on using external repositories on services like GitHub, GitLab or Bitbucket.<\/p>\n\n<p>You can run <code>git init<\/code> and use it locally without pushing to any remote services.<\/p>\n\n<p>These services also add extra terminology, such as forks, syncing and pull or merge requests which aren't part of Git itself.<\/p>\n\n<p>This can cause confusion, which is why <a href=\"http:\/\/default\/daily\/2022\/08\/23\/git-gui-command-line\">I think it's important to learn Git itself<\/a> instead of relying on external services or desktop apps.<\/p>\n\n<p>And, if you're going to use a remote repository, consider something like Gitea, which you can host yourself and keep control of your data.<\/p>\n\n ",
|
||||
"summary": null
|
||||
}
|
||||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "22be20101f09fc0d4e10cd3c6b867b76",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "d9902d3f03d57f8eef7e67d29133f05f",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "8a79fcd4efce6727224214430cc26505",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "f378ea534b4141dc8290191f8941df2c",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -76,8 +76,7 @@
|
|||
],
|
||||
"path": [
|
||||
{
|
||||
"alias": "",
|
||||
"pid": null,
|
||||
"alias": "\/daily\/2025\/05\/20\/why-write-your-own-cms",
|
||||
"langcode": "en"
|
||||
}
|
||||
],
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "cba5205b68a6ba553b9b34ef661692d2",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -82,15 +82,15 @@
|
|||
],
|
||||
"body": [
|
||||
{
|
||||
"value": "\n <p>Before adding a new feature or change to a codebase, ask if it's really needed and consider its long-term implications.<\/p>\n\n<p>Code is easy to write, but needs to be maintained as newer language or framework features are added or have breaking changes.<\/p>\n\n<p>Something I've added recently to Build Configs was an option to use an <a href=\"/daily\/2024\/01\/27\/gitignore-inclusive-or-exclusive\">inclusive or exclusive .gitignore file<\/a>.<\/p>\n\n<p>Whilst it's only adding an if condition based on a value, it adds a separate path in my code and both need to be maintained.<\/p>\n\n<p>I've been thinking of adding <code>just<\/code> again to some projects instead of a <code>run<\/code> file, which would add separate files that need to be maintained and kept up-to-date with each other so both offer the same features.<\/p>\n\n<p>Is this something I want to maintain going forward? Does it add enough value to justify its maintenance?<\/p>\n\n<p>Different to a feature flag, which usually has a known lifespan, this could need be maintained for the whole lifespan of the application.<\/p>\n\n<p>On a client project, this could be having two sets of buttons with rounded and square corners.<\/p>\n\n<p>Do we need both?<\/p>\n\n<p>It could be the positioning of a title in a header. Fewer options mean there is less code to write and maintain.<\/p>\n\n<p>In a Drupal project, each choice could mean adding a different field, taxonomy term, or content or block type to achieve the desired result.<\/p>\n\n<p>The more we can achieve with fewer options means the application will be easier to maintain and work on in the future.<\/p>\n\n ",
|
||||
"value": "\n <p>Before adding a new feature or change to a codebase, ask if it's really needed and consider its long-term implications.<\/p>\n\n<p>Code is easy to write, but needs to be maintained as newer language or framework features are added or have breaking changes.<\/p>\n\n<p>Something I've added recently to Build Configs was an option to use an <a href=\"\/daily\/2024\/01\/27\/gitignore-inclusive-or-exclusive\">inclusive or exclusive .gitignore file<\/a>.<\/p>\n\n<p>Whilst it's only adding an if condition based on a value, it adds a separate path in my code and both need to be maintained.<\/p>\n\n<p>I've been thinking of adding <code>just<\/code> again to some projects instead of a <code>run<\/code> file, which would add separate files that need to be maintained and kept up-to-date with each other so both offer the same features.<\/p>\n\n<p>Is this something I want to maintain going forward? Does it add enough value to justify its maintenance?<\/p>\n\n<p>Different to a feature flag, which usually has a known lifespan, this could need be maintained for the whole lifespan of the application.<\/p>\n\n<p>On a client project, this could be having two sets of buttons with rounded and square corners.<\/p>\n\n<p>Do we need both?<\/p>\n\n<p>It could be the positioning of a title in a header. Fewer options mean there is less code to write and maintain.<\/p>\n\n<p>In a Drupal project, each choice could mean adding a different field, taxonomy term, or content or block type to achieve the desired result.<\/p>\n\n<p>The more we can achieve with fewer options means the application will be easier to maintain and work on in the future.<\/p>\n\n ",
|
||||
"format": "full_html",
|
||||
"processed": "\n <p>Before adding a new feature or change to a codebase, ask if it's really needed and consider its long-term implications.<\/p>\n\n<p>Code is easy to write, but needs to be maintained as newer language or framework features are added or have breaking changes.<\/p>\n\n<p>Something I've added recently to Build Configs was an option to use an <a href=\"/daily\/2024\/01\/27\/gitignore-inclusive-or-exclusive\">inclusive or exclusive .gitignore file<\/a>.<\/p>\n\n<p>Whilst it's only adding an if condition based on a value, it adds a separate path in my code and both need to be maintained.<\/p>\n\n<p>I've been thinking of adding <code>just<\/code> again to some projects instead of a <code>run<\/code> file, which would add separate files that need to be maintained and kept up-to-date with each other so both offer the same features.<\/p>\n\n<p>Is this something I want to maintain going forward? Does it add enough value to justify its maintenance?<\/p>\n\n<p>Different to a feature flag, which usually has a known lifespan, this could need be maintained for the whole lifespan of the application.<\/p>\n\n<p>On a client project, this could be having two sets of buttons with rounded and square corners.<\/p>\n\n<p>Do we need both?<\/p>\n\n<p>It could be the positioning of a title in a header. Fewer options mean there is less code to write and maintain.<\/p>\n\n<p>In a Drupal project, each choice could mean adding a different field, taxonomy term, or content or block type to achieve the desired result.<\/p>\n\n<p>The more we can achieve with fewer options means the application will be easier to maintain and work on in the future.<\/p>\n\n ",
|
||||
"processed": "\n <p>Before adding a new feature or change to a codebase, ask if it's really needed and consider its long-term implications.<\/p>\n\n<p>Code is easy to write, but needs to be maintained as newer language or framework features are added or have breaking changes.<\/p>\n\n<p>Something I've added recently to Build Configs was an option to use an <a href=\"http:\/\/default\/daily\/2024\/01\/27\/gitignore-inclusive-or-exclusive\">inclusive or exclusive .gitignore file<\/a>.<\/p>\n\n<p>Whilst it's only adding an if condition based on a value, it adds a separate path in my code and both need to be maintained.<\/p>\n\n<p>I've been thinking of adding <code>just<\/code> again to some projects instead of a <code>run<\/code> file, which would add separate files that need to be maintained and kept up-to-date with each other so both offer the same features.<\/p>\n\n<p>Is this something I want to maintain going forward? Does it add enough value to justify its maintenance?<\/p>\n\n<p>Different to a feature flag, which usually has a known lifespan, this could need be maintained for the whole lifespan of the application.<\/p>\n\n<p>On a client project, this could be having two sets of buttons with rounded and square corners.<\/p>\n\n<p>Do we need both?<\/p>\n\n<p>It could be the positioning of a title in a header. Fewer options mean there is less code to write and maintain.<\/p>\n\n<p>In a Drupal project, each choice could mean adding a different field, taxonomy term, or content or block type to achieve the desired result.<\/p>\n\n<p>The more we can achieve with fewer options means the application will be easier to maintain and work on in the future.<\/p>\n\n ",
|
||||
"summary": null
|
||||
}
|
||||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "b412bcd2d4532d309472dae5c82e8109",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
|
|
@ -82,15 +82,15 @@
|
|||
],
|
||||
"body": [
|
||||
{
|
||||
"value": "\n <p>I recently had <a href=\"/podcast\/27-drupalisms\">my first podcast episode with two guests<\/a>, where I discussed Drupal terminology and Drupalisms with Emma Horrell and Luke McCormick.<\/p>\n\n<p>It was a great episode, but there was something I needed to do before I could release it.<\/p>\n\n<p>Before I could release the episode, I needed to update my website to show both guest names.<\/p>\n\n<p>The other 26 episodes only had a single guest per episode, and my podcast pages were built to only show the first guest name.<\/p>\n\n<p>When building the pages for the <a href=\"/podcast\/1-retrofit\">first episode with Matt Glaman<\/a>, I only needed to show a single guest name.<\/p>\n\n<p>There was no need to show multiple guest names until I had an episode with multiple guests.<\/p>\n\n<p>I wrote the simplest code to achieve the requirements I had at the time.<\/p>\n\n<p>If I wrote for two guests but never had an episode with two guests, my website would be bloated and have functionality that wasn't needed or used.<\/p>\n\n<p>Now my requirements have changed.<\/p>\n\n<p>I can have an episode with one or two guests, but not three or more guests.<\/p>\n\n<p>If I have an episode with more than two guests, I'll write that functionality then.<\/p>\n\n<p>But not before.<\/p>\n\n ",
|
||||
"value": "\n <p>I recently had <a href=\"\/podcast\/27-drupalisms\">my first podcast episode with two guests<\/a>, where I discussed Drupal terminology and Drupalisms with Emma Horrell and Luke McCormick.<\/p>\n\n<p>It was a great episode, but there was something I needed to do before I could release it.<\/p>\n\n<p>Before I could release the episode, I needed to update my website to show both guest names.<\/p>\n\n<p>The other 26 episodes only had a single guest per episode, and my podcast pages were built to only show the first guest name.<\/p>\n\n<p>When building the pages for the <a href=\"\/podcast\/1-retrofit\">first episode with Matt Glaman<\/a>, I only needed to show a single guest name.<\/p>\n\n<p>There was no need to show multiple guest names until I had an episode with multiple guests.<\/p>\n\n<p>I wrote the simplest code to achieve the requirements I had at the time.<\/p>\n\n<p>If I wrote for two guests but never had an episode with two guests, my website would be bloated and have functionality that wasn't needed or used.<\/p>\n\n<p>Now my requirements have changed.<\/p>\n\n<p>I can have an episode with one or two guests, but not three or more guests.<\/p>\n\n<p>If I have an episode with more than two guests, I'll write that functionality then.<\/p>\n\n<p>But not before.<\/p>\n\n ",
|
||||
"format": "full_html",
|
||||
"processed": "\n <p>I recently had <a href=\"/podcast\/27-drupalisms\">my first podcast episode with two guests<\/a>, where I discussed Drupal terminology and Drupalisms with Emma Horrell and Luke McCormick.<\/p>\n\n<p>It was a great episode, but there was something I needed to do before I could release it.<\/p>\n\n<p>Before I could release the episode, I needed to update my website to show both guest names.<\/p>\n\n<p>The other 26 episodes only had a single guest per episode, and my podcast pages were built to only show the first guest name.<\/p>\n\n<p>When building the pages for the <a href=\"/podcast\/1-retrofit\">first episode with Matt Glaman<\/a>, I only needed to show a single guest name.<\/p>\n\n<p>There was no need to show multiple guest names until I had an episode with multiple guests.<\/p>\n\n<p>I wrote the simplest code to achieve the requirements I had at the time.<\/p>\n\n<p>If I wrote for two guests but never had an episode with two guests, my website would be bloated and have functionality that wasn't needed or used.<\/p>\n\n<p>Now my requirements have changed.<\/p>\n\n<p>I can have an episode with one or two guests, but not three or more guests.<\/p>\n\n<p>If I have an episode with more than two guests, I'll write that functionality then.<\/p>\n\n<p>But not before.<\/p>\n\n ",
|
||||
"processed": "\n <p>I recently had <a href=\"http:\/\/default\/podcast\/27-drupalisms\">my first podcast episode with two guests<\/a>, where I discussed Drupal terminology and Drupalisms with Emma Horrell and Luke McCormick.<\/p>\n\n<p>It was a great episode, but there was something I needed to do before I could release it.<\/p>\n\n<p>Before I could release the episode, I needed to update my website to show both guest names.<\/p>\n\n<p>The other 26 episodes only had a single guest per episode, and my podcast pages were built to only show the first guest name.<\/p>\n\n<p>When building the pages for the <a href=\"http:\/\/default\/podcast\/1-retrofit\">first episode with Matt Glaman<\/a>, I only needed to show a single guest name.<\/p>\n\n<p>There was no need to show multiple guest names until I had an episode with multiple guests.<\/p>\n\n<p>I wrote the simplest code to achieve the requirements I had at the time.<\/p>\n\n<p>If I wrote for two guests but never had an episode with two guests, my website would be bloated and have functionality that wasn't needed or used.<\/p>\n\n<p>Now my requirements have changed.<\/p>\n\n<p>I can have an episode with one or two guests, but not three or more guests.<\/p>\n\n<p>If I have an episode with more than two guests, I'll write that functionality then.<\/p>\n\n<p>But not before.<\/p>\n\n ",
|
||||
"summary": null
|
||||
}
|
||||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "6d7fff29a7d69d2505863bd126857e30",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Add a link
Reference in a new issue