69 lines
3.8 KiB
YAML
69 lines
3.8 KiB
YAML
uuid:
|
|
- value: 00497277-4b40-4d36-a473-8d8e1a187c18
|
|
langcode:
|
|
- value: en
|
|
type:
|
|
- target_id: daily_email
|
|
target_type: node_type
|
|
target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
|
|
revision_timestamp:
|
|
- value: '2025-05-11T09:00:44+00:00'
|
|
revision_uid:
|
|
- target_type: user
|
|
target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
|
|
revision_log: { }
|
|
status:
|
|
- value: true
|
|
uid:
|
|
- target_type: user
|
|
target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
|
|
title:
|
|
- value: |
|
|
Consistency is key
|
|
created:
|
|
- value: '2023-04-18T00:00:00+00:00'
|
|
changed:
|
|
- value: '2025-05-11T09:00:44+00:00'
|
|
promote:
|
|
- value: false
|
|
sticky:
|
|
- value: false
|
|
default_langcode:
|
|
- value: true
|
|
revision_translation_affected:
|
|
- value: true
|
|
path:
|
|
- alias: /daily/2023/04/18/consistency-is-key
|
|
langcode: en
|
|
body:
|
|
- value: |
|
|
<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>
|
|
|
|
<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>
|
|
|
|
<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>
|
|
|
|
<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>
|
|
|
|
<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>
|
|
|
|
<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>
|
|
|
|
|
|
format: full_html
|
|
processed: |
|
|
<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>
|
|
|
|
<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>
|
|
|
|
<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>
|
|
|
|
<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>
|
|
|
|
<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>
|
|
|
|
<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>
|
|
|
|
|
|
summary: null
|
|
field_daily_email_cta: { }
|