A common mistake I see with new Developers and Development teams when starting with automated testing is to split development time and testing into separate tasks.<\/p>\n\n
They'll say when quoting a client or in an estimation session that the development time will take x hours and writing tests will take y hours.<\/p>\n\n
This is something I've always avoided.<\/p>\n\n
When broken out this way, it implies the automated tests are optional when they should be an integral part of the development process.<\/p>\n\n
They aren't a separate task that can be removed or skipped to save time or money.<\/p>\n\n
If I take my car to a garage, I don't ask them how long it will take to repair and how long to test what they've done.<\/p>\n\n
I want to know how much the whole task will cost and how long it will take.<\/p>\n\n
I assume they automatically test and verify the work they do and follow their industry's standard and best practices.<\/p>\n\n
I'm doing the same when developing software.<\/p>\n\n ", "summary": null } - ], - "feeds_item": [ - { - "imported": "1970-01-01T00:32:50+00:00", - "guid": null, - "hash": "71938847a402f6b5af7c2e34bca063d3", - "target_type": "feeds_feed", - "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76" - } ] } \ No newline at end of file diff --git a/content/node.001f3ebb-79dc-43ad-a363-6dc668d06a0c.json b/content/node.001f3ebb-79dc-43ad-a363-6dc668d06a0c.json index 247ab866a..35cbd87fd 100644 --- a/content/node.001f3ebb-79dc-43ad-a363-6dc668d06a0c.json +++ b/content/node.001f3ebb-79dc-43ad-a363-6dc668d06a0c.json @@ -87,14 +87,5 @@ "processed": "\n
Test cases are usually split into two or three sections - \"Arrange, Act, Assert\" or \"Given, When, Then\".<\/p>\n\n
If the test has a prerequisite, such as some users or content to be created or in a given state, you create the required environment for the test. With unit tests, this would include mocking any dependencies you need to use.<\/p>\n\n
Then you perform an action on the subject under test and, finally, assert that the system is in the desired state.<\/p>\n\n
Maybe a user was pending initially, and they're active after running a command or a cron task. You can assert the initial state of the user as well as the final state to ensure the action did what it was supposed to do.<\/p>\n\n
To help me get started, I'll sometimes write a test like this with placeholders to separate the test into its separate stages:<\/p>\n\n
\/** @test *\/\nfunction should_activate_a_pending_user(): void {\n \/\/ Arrange.\n\n \/\/ Act.\n\n \/\/ Assert.\n}\n<\/code><\/pre>\n\nThis makes me think about the different stages and what each might need to contain.<\/p>\n\n
Option 2<\/h2>\n\n
Or I might write it out in the \"Given, When, Then\" format:<\/p>\n\n
\/** @test *\/\nfunction should_activate_a_pending_user(): void {\n \/\/ Given I have a user.\n \/\/ And the user is pending.\n\n \/\/ When I run the user update command.\n\n \/\/ Then the user should no longer be 'pending'.\n \/\/ And the user status should be 'active'.\n}\n<\/code><\/pre>\n\nThis takes a little longer to write but feels more familiar if you're used to a behavioural testing framework like Behat.<\/p>\n\n
Either way, sometimes, I'll remove the comments once I've written the code around them or leave them to provide additional context.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "a1a228d3231ffab8895ec0cbd78f0b1d",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.00497277-4b40-4d36-a473-8d8e1a187c18.json b/content/node.00497277-4b40-4d36-a473-8d8e1a187c18.json
index a62ed3e85..0c71feebc 100644
--- a/content/node.00497277-4b40-4d36-a473-8d8e1a187c18.json
+++ b/content/node.00497277-4b40-4d36-a473-8d8e1a187c18.json
@@ -87,14 +87,5 @@
"processed": "\n
A side effect of using a tool to generate build configuration files<\/a> with templates is the consistency that it introduces.<\/p>\n\nThe majority of my projects use a PHP-FPM or PHP CLI container. In my Docker Compose file, the service was mostly named php<\/code> but sometimes it was php-fpm<\/code>. In the templated file, it's always named php<\/code>.<\/p>\n\nSome projects would use mysql<\/code> or mariadb<\/code> for the database service and nginx<\/code> or caddy<\/code> depending on which server was being used. These are now always database<\/code> and web<\/code> respectively.<\/p>\n\nAs well as being easier to switch between projects and not having to think about which names are used in each codebase, it's also much easier to write tools and automation when the names are consistent.<\/p>\n\n
For example, I'd always write a long-ish command to import a database file - reading and unzipping it, and importing it by connecting to the database running in its container. The command would essentially be the same with slight changes based on that project - such as the database service name.<\/p>\n\n
Now the command is the same for all projects, and I can automate it by writing a script that works on any project meaning I no longer need to write the long command at all.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "aacb745c094cf5a9f668c64b15000f49",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.00d62e94-80d1-4792-bdea-88a064f6bf65.json b/content/node.00d62e94-80d1-4792-bdea-88a064f6bf65.json
index 666cc01eb..bcbb69ed3 100644
--- a/content/node.00d62e94-80d1-4792-bdea-88a064f6bf65.json
+++ b/content/node.00d62e94-80d1-4792-bdea-88a064f6bf65.json
@@ -87,14 +87,5 @@
"processed": "\n
Something I see on many Developers' websites and CVs is percentages or levels of how well they know certain tools and frameworks.<\/p>\n\n
Things like \"80% of PHP\" or \"Advanced in HTML and CSS\".<\/p>\n\n
But how do you quantify that?<\/p>\n\n
Do people alter their percentages accordingly if a new feature is added to a language or framework?<\/p>\n\n
Or, instead of trying to show how much you understand, focus on what problems you can solve with those tools and how you can provide value to customers or employers instead of what tools you'd use to do it.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "3bf8b7e44f82bf7d6ad5ce1fda692ae6",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0100be71-79ef-44ea-922e-e75fcc26ae16.json b/content/node.0100be71-79ef-44ea-922e-e75fcc26ae16.json
index de3e280a4..9a3089855 100644
--- a/content/node.0100be71-79ef-44ea-922e-e75fcc26ae16.json
+++ b/content/node.0100be71-79ef-44ea-922e-e75fcc26ae16.json
@@ -87,14 +87,5 @@
"processed": "\n
A common reason why environments aren't updated and get out of sync is because it's a time-consuming or complex task.<\/p>\n\n
The process should be simple to run, quick, reliable and reproducible.<\/p>\n\n
It's the same as deploying a change to a staging or production environment.<\/p>\n\n
You want the same result on every time on every environment.<\/p>\n\n
You want every environment - including local development environments<\/a> to be as consistent as possible to minimise bugs and errors.<\/p>\n\nTo do this, I automate things to make them as simple as possible.<\/p>\n\n
I use run files<\/a> with commands to import databases, perform updates and run pre-update and post-update tasks.<\/p>\n\nI use tools like Nix and devenv<\/a> to create identical and reproducible environments.<\/p>\n\nThe simpler and quicker is it, the more it can and will be done.<\/p>\n\n
You can also use automation to perform long or complex tasks outside of working hours such as sanitising and importing large databases.<\/p>\n\n
The more you can automate, the better.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "957251b7baf05530d91b2a9731016317",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.01230324-62b5-442b-80e4-09268a31819b.json b/content/node.01230324-62b5-442b-80e4-09268a31819b.json
index 89862fa7a..7ab11661f 100644
--- a/content/node.01230324-62b5-442b-80e4-09268a31819b.json
+++ b/content/node.01230324-62b5-442b-80e4-09268a31819b.json
@@ -87,14 +87,5 @@
"processed": "\n
I started learning software and web development with HTML and CSS in 2007. Then I started with PHP and soon after started to learn Drupal 6 (or maybe 5).<\/p>\n\n
A lot of Developers' first programming language was PHP and maybe used earlier versions of Drupal before moving to another CMS, framework or language.<\/p>\n\n
They still remember, though, how things were when they used it and aren't aware of the advancements and improvements that have been made.<\/p>\n\n
The PHP language itself has improved significantly in recent versions with new features and much better peformance.<\/p>\n\n
Drupal is more powerful with a lot more available in core compared to when I started to use it and, since adopting modern PHP approaches and third-party code in Drupal 8, writing custom Drupal modules is different with fewer Drupalisms and more industry-standard approaches.<\/p>\n\n
If there's a tool you haven't tried for a while, maybe take another look and see if it's improved since you last used it.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "3baa147faae6a26ac886bb26940c8f43",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.01893784-8f45-4466-8586-17df23e7e4b5.json b/content/node.01893784-8f45-4466-8586-17df23e7e4b5.json
index 827b38a4e..7dc33c1b3 100644
--- a/content/node.01893784-8f45-4466-8586-17df23e7e4b5.json
+++ b/content/node.01893784-8f45-4466-8586-17df23e7e4b5.json
@@ -87,14 +87,5 @@
"processed": "\n
PHPStan is a static analysis tool for PHP.<\/p>\n\n
It finds potential issues in PHP code without needing to run it, so Developers can find and resolve potential issues sooner.<\/p>\n\n
I use it on all my projects including existing ones I've inherited.<\/p>\n\n
But how can you add a static analysis tool to a codebase without getting a lot of errors from the existing code?<\/p>\n\n
PHPStan has different levels of strictness.<\/p>\n\n
Level 0 is the least strict and each level adds more rules and strictness, resulting in more errors.<\/p>\n\n
Most of the time, people will start by running PHPStan on level 0, fixing any errors and committing the changes.<\/p>\n\n
Then repeat the process as many times as needed until you reach the level you want to achieve.<\/p>\n\n
I don't think this is the right approach.<\/p>\n\n
This could mean that you need to edit the same files multiple times as you work through the levels.<\/p>\n\n
There's also a period of time where Developers can still write suboptimal code whilst you work your way up to your desired level.<\/p>\n\n
Another approach is to use a feature of PHPStan called the baseline.<\/p>\n\n
The baseline is a way of capturing and saving all the existing errors up to the selected level so they are no longer reported.<\/p>\n\n
If you did this for an existing project, it would return no errors as everything would be included in the baseline.<\/p>\n\n
Once you decide what level you want your project to run, you can start as soon as the baseline is generated and without needing to change files multiple times.<\/p>\n\n
Instead of spending time working through the levels one at a time, commit some time to pruning the baseline and reducing the errors in it.<\/p>\n\n
This I think is a better approach and how I add PHPStan to existing codebases.<\/p>\n\n
To learn more about static analysis and PHPStan, listen to episode 22 of the Beyond Blocks podcast<\/a> with Dave Liddament.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "9a7b258b69b97c51304c0aa8d6b87263",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.018bf894-2d3e-4130-b0bd-43450ef5753a.json b/content/node.018bf894-2d3e-4130-b0bd-43450ef5753a.json
index f8f2080b6..b2e8aef99 100644
--- a/content/node.018bf894-2d3e-4130-b0bd-43450ef5753a.json
+++ b/content/node.018bf894-2d3e-4130-b0bd-43450ef5753a.json
@@ -87,14 +87,5 @@
"processed": "\n Before I started to use [Tailwind CSS][0], I used CSS preprocessors like Less and Sass to add features like variables and nesting to my CSS files.<\/p>\n\n
Stylesheets would be written in .scss, .sass or .less files and processed to create the stylesheets that would be used by browsers.<\/p>\n\n
But, with the recent improvements to CSS, do we still need these preprocessors?<\/p>\n\n
Here's a very small example of some CSS that just works:<\/p>\n\n
:root {\n --color-primary: red;\n --color-secondary: green;\n}\n\na {\n color: var(--color-primary);\n\n &:hover, &:focus {\n color: var(--color-secondary);\n }\n}\n<\/code><\/pre>\n\nIt looks like a Sass file, but it's native CSS.<\/p>\n\n
It has variables (a.k.a. custom properties) and nesting, which I think are the most used features from preprocessors.<\/p>\n\n
But there's no additional build step to generate the end stylesheet. I can use this stylesheet as it is - making it easier to work on and less confusing for new Developers.<\/p>\n\n
If I'm not using Tailwind CSS or atomic styles, writing plain CSS files is the approach I'd use.<\/p>\n\n
No preprocessors needed.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "cdd9ab25b0351a9082e1580898e5ecbc",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.01f3b831-e981-471f-aef9-076b054e3495.json b/content/node.01f3b831-e981-471f-aef9-076b054e3495.json
index 4e026dd42..4a005336e 100644
--- a/content/node.01f3b831-e981-471f-aef9-076b054e3495.json
+++ b/content/node.01f3b831-e981-471f-aef9-076b054e3495.json
@@ -87,14 +87,5 @@
"processed": "\n
Testing - manual or automated - is about building confidence.<\/p>\n\n
If we deploy this change or release this feature, are we confident it will work as expected and not cause regressions elsewhere?<\/p>\n\n
What if someone asked you on a scale between one and ten?<\/p>\n\n
From an automated perspective, have you written enough tests for the feature to be confident it works?<\/p>\n\n
If you're fixing a bug, do you have a test that reproduces the bug that was originally failing but now passing since you've added the fix?<\/p>\n\n
Do the tests have enough assertions, and have you covered enough use cases and scenarios?<\/p>\n\n
Here's the thing<\/h2>\n\n
You can utilise code coverage metrics, but no hard rule says that the feature will work once x percentage is covered. Something with 100% coverage can still contain bugs.<\/p>\n\n
For me, it's about the answer to the question:<\/p>\n\n
If we deploy this change, how confident are you that it will work as expected?<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "60c550711c51c2b739051e4640eba954",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0209ee07-9e17-4c85-ae5e-d14ae42bb22a.json b/content/node.0209ee07-9e17-4c85-ae5e-d14ae42bb22a.json
index b771a7ad5..c94f1c7a6 100644
--- a/content/node.0209ee07-9e17-4c85-ae5e-d14ae42bb22a.json
+++ b/content/node.0209ee07-9e17-4c85-ae5e-d14ae42bb22a.json
@@ -87,6 +87,5 @@
"processed": "
There's nothing more frustrating for me than seeing an error I've seen before and not remembering how I fixed it last time.<\/p>
I try to remember and search for the error message, just to find and read the same articles and posts again or watch the same videos.<\/p>
I wrote my first blog post on my website in 2010 to document my learning for myself and to share with others.<\/p>
I've also been a keen note taker, using tools like Evernote and others to take notes and write documentation for myself to refer to in the future.<\/p>
These days, I just write plain text files<\/a> using Nick Janetakis' notes program<\/a>, which I've modified slightly by patching it<\/a> to create daily notes instead of monthly ones. <\/p>They're fast to write, easy to search and available offline if I'm traveling or away from my computer.<\/p>
I much prefer being able to search my notes and find what I'm looking for or, if it's a post that I've written publicly, searching online and finding my own answer.<\/p>
Whether you're a new or experienced Developer, you're always learning new things, so write them down for yourself and, if you want, write publicly and share your learnings with others.<\/p>",
"summary": ""
}
- ],
- "feeds_item": []
+ ]
}
\ No newline at end of file
diff --git a/content/node.021e00c1-b813-4edd-8064-71285bc3647d.json b/content/node.021e00c1-b813-4edd-8064-71285bc3647d.json
index 70b549196..92b59f34b 100644
--- a/content/node.021e00c1-b813-4edd-8064-71285bc3647d.json
+++ b/content/node.021e00c1-b813-4edd-8064-71285bc3647d.json
@@ -87,14 +87,5 @@
"processed": "\n
I recently saw this post on X<\/a>, talking about an open-source project.<\/p>\n\nThis was the part that I want to highlight:<\/p>\n\n
\n I was also impressed by the decisions documents. More projects should implement this concept.<\/p>\n<\/blockquote>\n\n
Looking at the repository, it contains records of 36 decisions made on the project between May 2023 and April 2024.<\/p>\n\n
Decision records provide useful information to new people to a project, whether you want to contribute to an open-source project or it's a new client or work codebase.<\/p>\n\n
The code and project will likely continue once you've finished working on it, so capturing decisions for future Developers is key.<\/p>\n\n
I've often joined projects and wondered why or how something was done, and can only guess as the decision wasn't recorded or is somewhere not available to me, such as an old wiki or ticketing system.<\/p>\n\n
Here's the thing<\/h2>\n\n
I agree with the poster.<\/p>\n\n
More people should record the decisions made on their project, whether it's open-source or not.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "bc11c3125e2e228f16b76f91b749c764",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0231b26c-ac28-44e8-a2bf-cc7c86984e7e.json b/content/node.0231b26c-ac28-44e8-a2bf-cc7c86984e7e.json
index 2db8fb91d..518b0641a 100644
--- a/content/node.0231b26c-ac28-44e8-a2bf-cc7c86984e7e.json
+++ b/content/node.0231b26c-ac28-44e8-a2bf-cc7c86984e7e.json
@@ -87,14 +87,5 @@
"processed": "\n
When reviewing a pull or merge request, tools like GitHub and GitHub offer the option to squash the commits before merging.<\/p>\n\n
If the request had twenty commits, they'd be combined into a single commit before being merged.<\/p>\n\n
But should you do it?<\/p>\n\n
The answer will be \"it depends\" based on the project or team, but I'm personally not a fan of squashing commits.<\/p>\n\n
Even though I commit small changes often, I put quite a bit of effort into crafting commits and writing detailed commit messages<\/a> that capture the reason for each change. If the commits are squashed, either the messages will be combined into one extra-long commit message or I've seen them be deleted completely.<\/p>\n\nOne large commit message would be very difficult to read and connect specific messages with their changes, and deleting the commit body would lose the history completely and waste the time it took to write the messages and craft the commits. It may be available within the pull or merge request page but there's no guarantee that you'll continue to use the same repository hosting service in the future.<\/p>\n\n
One large commit would also be difficult to debug if there was an error. If the whole feature was added in a single commit, tools like git bisect<\/a> would no longer work and a single commit couldn't be simply reverted if it contained a bug.<\/p>\n\nI 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:32:50+00:00",
- "guid": null,
- "hash": "54447bfd288cd6e71d4b06bd0646502d",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.024f2c81-68af-4eef-bea5-1b1d43bd1b39.json b/content/node.024f2c81-68af-4eef-bea5-1b1d43bd1b39.json
index 1726a3422..90988d4f9 100644
--- a/content/node.024f2c81-68af-4eef-bea5-1b1d43bd1b39.json
+++ b/content/node.024f2c81-68af-4eef-bea5-1b1d43bd1b39.json
@@ -87,14 +87,5 @@
"processed": "\n
In yesterday's email, I mentioned that deprecating code allows it to be backwards compatible - but what does that mean?<\/p>\n\n
If I were to remove a function like drupal_set_message()<\/code> that is used code elsewhere in an application, the code would no longer work and would break.<\/p>\n\nAs a module or library maintainer, I don't want to cause applications to break by making backward incompatible changes (a \"BC break\" or a \"breaking change\").<\/p>\n\n
Maintaining backward compatibility means that people who use the code can update to the latest version without breakages, and if they use any deprecated code, they know to update it to be compatible with future versions.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "18e7b8e123a0c299bb44600a75b56d9e",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.025f0dde-748b-44f4-93e2-4e0602d30104.json b/content/node.025f0dde-748b-44f4-93e2-4e0602d30104.json
index 8c2c5f37c..d591a8bdf 100644
--- a/content/node.025f0dde-748b-44f4-93e2-4e0602d30104.json
+++ b/content/node.025f0dde-748b-44f4-93e2-4e0602d30104.json
@@ -87,14 +87,5 @@
"processed": "\n
Today, I was speaking with a colleague about configuring Git, which led to a conversation about dotfiles repositories - somewhere where you version the changes to your configuration files and, usually, create symlinks to their expected locations.<\/p>\n\n
Afterwards, I realised the first commit to my personal dotfiles repository<\/a> was over eight years ago, in July 2015.<\/p>\n\nWhat started as a repository to put my own Git configuration has undergone various changes since the tools I use changed, as well as the tools to manage the files themselves.<\/p>\n\n
In 2021, I switched my .vimrc<\/code> configuration file to an init.vim<\/code> and switched to Neovim full-time and, most recently, almost a year ago, I started to use the Nix package manager and later adopted NixOS as my primary Linux distribution.<\/p>\n\nMy complete NixOS and Home Manager configurations are within my dotfiles<\/code> repository, and the configuration for tools, including Neovim, tmux and Git.<\/p>\n\nI wonder what the repository will look like in another eight years...<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "b663fb9c5e0257d2fdece24454ad3bfd",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.02777730-3fe8-4eba-8a16-e847042b7351.json b/content/node.02777730-3fe8-4eba-8a16-e847042b7351.json
index 941036510..9ffc86930 100644
--- a/content/node.02777730-3fe8-4eba-8a16-e847042b7351.json
+++ b/content/node.02777730-3fe8-4eba-8a16-e847042b7351.json
@@ -87,14 +87,5 @@
"processed": "\n
Today, I've been at an event run by a local animal rescue charity. It's one that we attend often as my children like to enter the dog show, but this year, I've also sponsored one of the categories.<\/p>\n\n
As well as organising the PHP South Wales user group, I'm also now a sponsor - donating books and elePHPant plushies for raffle prizes and paying the group's Meetup.com subscription costs.<\/p>\n\n
Giving back and supporting open-source maintainers and content creators is a big priority of mine. If I use some open-source software or find that someone's Twitch or YouTube channel is useful, if that person or organisation is on GitHub or Patron, then I'll sponsor them, or I'll subscribe to their channel.<\/p>\n\n
If I find a useful blog post or video, I'll add a comment or link to it on Twitter, thanking them and letting them know that it helped me.<\/p>\n\n
Especially if it's something that I've used within my projects, it makes sense to support it and it's maintainers, so that they keep working on and improving the software, continue streaming, and keep writing blog posts and recording videos for me to learn from.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "891d018e5d9b5fa68288878004365cce",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.02bd7b93-43c7-453f-8af9-0be875b27f82.json b/content/node.02bd7b93-43c7-453f-8af9-0be875b27f82.json
index d8951f2b1..833fba019 100644
--- a/content/node.02bd7b93-43c7-453f-8af9-0be875b27f82.json
+++ b/content/node.02bd7b93-43c7-453f-8af9-0be875b27f82.json
@@ -87,14 +87,5 @@
"processed": "\n
How do you validate an idea from a client or stakeholder?<\/p>\n\n
Unlike a minimum viable product, which is the smallest amount of functionality for a feature to be released, a proof of concept is an initial investigation into whether the idea is viable.<\/p>\n\n
What's the least amount of development you can do to prove the concept?<\/p>\n\n
Can you create something using a smaller data set or with simplified functionality?<\/p>\n\n
What can you build within a minimal timeframe so, if the idea isn't used, too much time wasn't invested in it, but still verifies it?<\/p>\n\n
Do you need to write any code or do any development at all?<\/p>\n\n
All we need to do is find out if the concept could work.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "f671ea961bdda4e275277b04dc159c79",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.02c9e148-b98f-42ae-80f1-d19a6d3fcfb2.json b/content/node.02c9e148-b98f-42ae-80f1-d19a6d3fcfb2.json
index aac457b30..01a1be1a2 100644
--- a/content/node.02c9e148-b98f-42ae-80f1-d19a6d3fcfb2.json
+++ b/content/node.02c9e148-b98f-42ae-80f1-d19a6d3fcfb2.json
@@ -87,14 +87,5 @@
"processed": "\n
The main programming languages I write are PHP and JavaScript.<\/p>\n\n
Both offer types where, as well as declaring a parameter or property, you can define what type it is - whether it's a string, array, boolean, etc.<\/p>\n\n
Adding types is optional.<\/p>\n\n
You don't need to add types to your PHP code, and you can choose to write plain JavaScript instead of TypeScript.<\/p>\n\n
Some people prefer simpler or cleaner code or less \"visual debt\".<\/p>\n\n
I like the extra clarity that types add.<\/p>\n\n
I like to be able to read some code and immediately know what types things should be.<\/p>\n\n
I like the clearer errors and messages if a different type is given than was expected.<\/p>\n\n
Tools like PHPStan know more about my code and give better recommendations than if I don't add types.<\/p>\n\n
I like the better autocompletion I get when writing code that has types.<\/p>\n\n
I like types, but I also like the flexibility of whether or not to add them and for Developers and development teams to make their own decisions based on their preferences.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "c50e363614371738c421f8a32ee763f3",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0300b4ea-e71b-4f9c-b4f2-f04f98e92d6c.json b/content/node.0300b4ea-e71b-4f9c-b4f2-f04f98e92d6c.json
index 80d7a01d6..6ae1bbb5a 100644
--- a/content/node.0300b4ea-e71b-4f9c-b4f2-f04f98e92d6c.json
+++ b/content/node.0300b4ea-e71b-4f9c-b4f2-f04f98e92d6c.json
@@ -87,14 +87,5 @@
"processed": "\n
Yesterday's email<\/a> explained why your company should contribute to open-source software, but why should you contribute as an individual?<\/p>\n\nMost of the same reasons apply, such as gaining experience and improved knowledge from contributing.<\/p>\n\n
As an individual, you can build your own reputation and personal brand.<\/p>\n\n
You'll get exposure from contributions and involvement with initiatives, such as the Drupal admin UI improvements and other core initiatives, which look great on your CV and LinkedIn profile.<\/p>\n\n
This could lead to better career opportunities and potential projects.<\/p>\n\n
I've had paid development work directly from my open-source code contributions, as well as public speaking and event organising, so I can vouch for this.<\/p>\n\n
Like companies, if you make money from open-source software - either a salary or from paid projects or courses - it's in your interest to contribute so the software you use is maintained and improved so it's the best it can be.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "0f37079942ad6ce63ae32e8ea7c57c79",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0316dfcf-b709-47e1-9622-9355b5ece6d9.json b/content/node.0316dfcf-b709-47e1-9622-9355b5ece6d9.json
index 20c3e8880..71b41bdb7 100644
--- a/content/node.0316dfcf-b709-47e1-9622-9355b5ece6d9.json
+++ b/content/node.0316dfcf-b709-47e1-9622-9355b5ece6d9.json
@@ -87,14 +87,5 @@
"processed": "\n
Does your team have a \"No deploy Friday\" policy?<\/p>\n\n
What about not deploying after a certain time in the afternoon?<\/p>\n\n
These approaches are attempts to minimise risk when deploying.<\/p>\n\n
If there is an issue, will someone be available during the evening or weekend to resolve it?<\/p>\n\n
To me, this indicates the deployment process is too complicated, possibly due to a lack of automation, or deployments aren't happening frequently enough.<\/p>\n\n
Having a robust and passing CI pipeline<\/a> that runs automated checks and tests is crucial to know the code is deployable.<\/p>\n\nFeature 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\nToo much time between deployments is a smell.<\/p>\n\n
The more time there is between a deployment and the larger the changeset, the riskier the deployment will be.<\/p>\n\n
There is more to go wrong and it'll be harder to diagnose and resolve any issues.<\/p>\n\n
I always advocate for many smaller releases than larger less frequent ones.<\/p>\n\n
Ideally, a production release every day - even if the changes are small or everything is hidden behind feature flags.<\/p>\n\n
Deploying on Friday is easy if you last deployed on Thursday.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "021827be7bf3f083020a0f2ff11066d8",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0318e249-a9a8-476f-9bd4-432544369917.json b/content/node.0318e249-a9a8-476f-9bd4-432544369917.json
index abd9d7501..2a844e1cc 100644
--- a/content/node.0318e249-a9a8-476f-9bd4-432544369917.json
+++ b/content/node.0318e249-a9a8-476f-9bd4-432544369917.json
@@ -87,14 +87,5 @@
"processed": "\n
Applying patch files<\/a> is a common way to customise and extend open source software, and how we used to submit changes to Drupal before issue forks and merge requests were added to Drupal.org.<\/p>\n\nSome software, such as dwm and st from suckless.org are released as minimal versions that you patch to add features to.<\/p>\n\n
If you find a line of code that you want to add, edit or delete, a patch file describes the changes so you can re-apply them whenever the source file changes.<\/p>\n\n
Patching offers unlimited customisation and flexibility.<\/p>\n\n
Whatever changes you want to make, you can.<\/p>\n\n
The downside is you need to maintain any patches you've written.<\/p>\n\n
If a change is made that causes your patch to no longer apply, you'll need to update the patch.<\/p>\n\n
There are some patches I commonly apply to Drupal projects, but I'll try to either contribute the changes back to the Drupal so I no longer need the patch or make the change in a custom module.<\/p>\n\n
Sometimes, though, patching is the only option<\/a>.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "e1882c079f5b933697958ec2ac91a1b7",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.033f0b46-69f9-4ea0-9706-d930e67dd5d8.json b/content/node.033f0b46-69f9-4ea0-9706-d930e67dd5d8.json
index 833ae8771..dba56f68b 100644
--- a/content/node.033f0b46-69f9-4ea0-9706-d930e67dd5d8.json
+++ b/content/node.033f0b46-69f9-4ea0-9706-d930e67dd5d8.json
@@ -87,14 +87,5 @@
"processed": "\n My website is built with Sculpin - a static site generator written in PHP.<\/p>\n\n
It uses a some of the same Symfony components as Drupal, uses Twig for templating and YAML for configuration, and has similar features like content types and taxonomies for structuring content.<\/p>\n\n
When I first created my website it was on Drupal 6 and upgraded to Drupal 7 before I started to take an interest in static site generators and later using Jekyll, Sculpin and Astro (and Sculpin, again).<\/p>\n\n
I enjoyed learning Sculpin and took it as an opportunity to learn Twig before Drupal 8, which I spoke about in the first Sculpin talk I gave<\/a>, at DrupalCamp North in July 2015.<\/p>\n\nI had three Git repositories, the current Sculpin one, the Astro version, and the original Sculpin version with its first commit in March 2015 - a few months before DrupalCamp North.<\/p>\n\n
Static site generators keep the files in text files intead of a database, so I was wondering if it was possible to merge the repositories together and combine the information whilst keeping the same commit history so existing tags and contribtions would still apply to the original commits.<\/p>\n\n
In short, I was able to do it by adding the old repositories as additional remotes and using the --allow-unrelated-histories<\/code> option for git merge<\/a>.<\/p>\n\nAfter fixing some minor merge conflicts, everything was merged successfully and I have [one repository containing 5,272 all commits][2], going back to 2015.<\/p>\n\n
This makes it older than my dotfiles repository<\/a>, which I started in July 2015.<\/p>\n\nSimilar to why I use Linux<\/a>, I believe in owning your own content rather than relying on third-party platforms, so having all my content and history in one repository is great.<\/p>\n\nAnd I learned something new about Git at the same time.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "cc353a3343b4a9ed6dc01850a09c8f76",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.036a8839-c5f9-4206-a979-201e9dac1557.json b/content/node.036a8839-c5f9-4206-a979-201e9dac1557.json
index ee4d0661d..4e2bd240c 100644
--- a/content/node.036a8839-c5f9-4206-a979-201e9dac1557.json
+++ b/content/node.036a8839-c5f9-4206-a979-201e9dac1557.json
@@ -87,14 +87,5 @@
"processed": "\n
I've recently started as a Mentor for the School of Code, working with a student on their cohort that started last week. Whilst the Bootcamp is focussed on JavaScript and node, and is currently looking at front-end development and using APIs, we've already started talking about different back-end technologies and frameworks.<\/p>\n\n
Something that I've believed for a while is that software development is about solving problems and different languages and frameworks are tools to use to solve the problem and achieve the desired result. The programming fundamentals that he's learning now can be applied to different languages and some may be better depending on the problem that needs to be solved.<\/p>\n\n
I've also said when speaking with a client this week that development is about adding business value.<\/p>\n\n
Whilst there is some value to doing security updates and maintenance to keep an application running and secure, I'd much rather be working on tasks that directly add value for the client like some of the tasks I've done for them recently like improving eCommerce conversions and adding new payment methods or revenue streams.<\/p>\n\n
It's easier for the client to justify and see the results of the work, it improves the experience for their customers or users, and it's more interesting and fulfilling for me.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "7256a5bb0e6800a548d88e2979344646",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.037796b8-42d8-4ea4-abec-f8c8de0d97e8.json b/content/node.037796b8-42d8-4ea4-abec-f8c8de0d97e8.json
index 8dfe76d70..f82f6cdef 100644
--- a/content/node.037796b8-42d8-4ea4-abec-f8c8de0d97e8.json
+++ b/content/node.037796b8-42d8-4ea4-abec-f8c8de0d97e8.json
@@ -87,14 +87,5 @@
"processed": "\n
This week's episode<\/a> of the Beyond Blocks podcast is live, where I speak with Panagiotis Moutsopoulos (vensires on Drupal.org) - Drupal Backend Developer at E-Sepia.<\/p>\n\nWe 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:32:50+00:00",
- "guid": null,
- "hash": "4ddf140ca0555c2028d2bb2db394282f",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.03bbb03d-5963-477a-a904-19e2c1f1a581.json b/content/node.03bbb03d-5963-477a-a904-19e2c1f1a581.json
index 85d82b9d0..9d868adfa 100644
--- a/content/node.03bbb03d-5963-477a-a904-19e2c1f1a581.json
+++ b/content/node.03bbb03d-5963-477a-a904-19e2c1f1a581.json
@@ -87,14 +87,5 @@
"processed": "\n
There are three things you can do with legacy code.<\/p>\n\n
Refactor it, remove it or replace it.<\/p>\n\n
You can refactor it to make it easier to maintain and change in the future.<\/p>\n\n
If it's not needed, you can remove it.<\/p>\n\n
If it's not used, there's no need to keep it.<\/p>\n\n
Or you can replace it with something else.<\/p>\n\n
There isn't one right answer and the correct approach will depend on the situation and objective.<\/p>\n\n
In a future email, I'll give some examples of how I refactor legacy code.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "a3ea19c23705f4574c9b1455cc2169bc",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.03c0a713-f32d-445b-9397-add68fbf2fe5.json b/content/node.03c0a713-f32d-445b-9397-add68fbf2fe5.json
index 2bc2585d5..bca2bd993 100644
--- a/content/node.03c0a713-f32d-445b-9397-add68fbf2fe5.json
+++ b/content/node.03c0a713-f32d-445b-9397-add68fbf2fe5.json
@@ -87,14 +87,5 @@
"processed": "\n
As well as my laptop configuration<\/a>, local development environments<\/a> and production server<\/a>, I've also been using Nix for something else recently.<\/p>\n\nSetting up and configuring a Homelab on an old laptop.<\/p>\n\n
I've been able to install and configure services like Jellyfin for playing video files, Immich for photo hosting and management, Gitea as my own Git server, Vaultwarden for securely storing my passwords and Traefik as a reverse proxy.<\/p>\n\n
Each of these was very easy to configure with only a few lines of the Nix language and avoided a heavy use of Docker which seems common in most Homelab setups.<\/p>\n\n
Next, I'd like to add home automation with Home Assistant and explore running a local DNS server within my network.<\/p>\n\n
I'm looking forward to these, and seeing what else I can add to this setup using Nix and NixOS.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "ddffb71cbb4982c0c4d9ca78fecdcd4c",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.042e4d0c-f835-47dd-8075-745df0a7f8f2.json b/content/node.042e4d0c-f835-47dd-8075-745df0a7f8f2.json
index d73539315..3425f95df 100644
--- a/content/node.042e4d0c-f835-47dd-8075-745df0a7f8f2.json
+++ b/content/node.042e4d0c-f835-47dd-8075-745df0a7f8f2.json
@@ -87,14 +87,5 @@
"processed": "\n
After yesterday's post on why I prefer using Git on the command line rather than using a GUI tool, today I thought that I'd post about how I've configured Git.<\/p>\n\n
First, I rarely ever run the git<\/code> command - I usually run a g<\/code> function that I've created within my zsh configuration.<\/p>\n\nRather than being an simple alias, it's a shell function that will run git status -sb<\/code> to show the current status of the repository if there are no additional arguments. If there are, such as when running g add<\/code>, then this is executed as a normal Git command. (This is something that I first saw from Thoughtbot, if I remember correctly).<\/p>\n\nUsing .gitconfig<\/h2>\n\n
The main part of my configuration is within Git's ~\/.gitconfig<\/code> file, where I can configure Git to work how I want.<\/p>\n\nFor example, I like to avoid merge conflicts, so I always want to use fast-forward merges whilst pulling and also to rebase by default. I can do this by adding ff = only<\/code> and rebase = true<\/code> to the [pull]<\/code> section of my ~\/.gitconfig<\/code> file.<\/p>\n\nI can do this manually, or running git config --global pull.rebase true<\/code> will set the option but also update the file automatically.<\/p>\n\nSome of the tweaks that I've made are to only allow fast-forward merges by adding merge.ff = only<\/code>, automatically squash commits when rebasing by setting rebase.autosquash = true<\/code>, and automatically pruning branches by adding fetch.prune = true<\/code>.<\/p>\n\nSimple aliases<\/h3>\n\n
Another way that I configure Git is using aliases, which are also within the ~\/.gitconfig<\/code> file.<\/p>\n\nFor example, if I ran git config --global alias.b \"branch\"<\/code>, then running git b<\/code> would just run git branch<\/code> which shortens the command and saves some time and keystrokes.<\/p>\n\nI have similar one- or two letter \"short\" aliases for pushing and pulling code, and some that also set some additional arguments such as aa<\/code> for add --all<\/code> and worktrees<\/code> for worktree list<\/code>.<\/p>\n\nMore complicated aliases<\/h3>\n\n
Aliases can be more complex if needed by prefixing it with a !<\/code>, meaning that it executes it as a shell command.<\/p>\n\nThis means that I can have repush = !git pull --rebase && git push<\/code> to chain two separate Git commands and combine them into one, and ureset = !git reset --hard $(git upstream)<\/code> which executes the full command, including another alias as part of it.<\/p>\n\nI also have issues = !gh issue list --web<\/code> and pulls = !gh pr list --web<\/code> to open the current repository's GitHub issues or pull requests respectively, which can be done as it's not limited to just running git<\/code> commands.<\/p>\n\nCustom functions<\/h3>\n\n
Finally, if an alias is getting too long or complex, then it can extracted to it's own file.<\/p>\n\n
Any executable file within your $PATH<\/code> that starts with git-<\/code> will automatically become a Git command.<\/p>\n\nOne example that I have is git-cm<\/a> which, similar to the g<\/code> function`, is a bash script that checks for any arguments passed to it and runs a slightly different command. It achieves the same thing as if it were an alias, but it does make it easier to write and maintain as it's in a separate file.<\/p>\n\nThese are just some examples. If you want to see my entire configuration, then check out my dotfiles repository on GitHub<\/a>.<\/p>\n\nHow have you configured Git for your workflow? Reply to this email and let me know.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "4d3892ad51836bdd33e47e7043615d75",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.04ccaf9c-a0e4-4ca9-b96b-d32e3fc7f384.json b/content/node.04ccaf9c-a0e4-4ca9-b96b-d32e3fc7f384.json
index be9ace625..e0c57f56d 100644
--- a/content/node.04ccaf9c-a0e4-4ca9-b96b-d32e3fc7f384.json
+++ b/content/node.04ccaf9c-a0e4-4ca9-b96b-d32e3fc7f384.json
@@ -87,14 +87,5 @@
"processed": "\n
The more code you have, the more potential problems you have.<\/p>\n\n
More code means more opportunities for bugs in your software.<\/p>\n\n
There's more code to maintain and more chance of encountering breaking changes as you update between major software versions of your project's dependencies, such as a CMS or framework.<\/p>\n\n
If you can keep your amount of code to a minimum and reduce the maintenance overhead, you are less likely to experience issues.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "137f467c7894dcf4d534ab6c7572567a",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.050525d7-3275-486e-8f0e-9548aa81a156.json b/content/node.050525d7-3275-486e-8f0e-9548aa81a156.json
index f86304c1f..0e05915c0 100644
--- a/content/node.050525d7-3275-486e-8f0e-9548aa81a156.json
+++ b/content/node.050525d7-3275-486e-8f0e-9548aa81a156.json
@@ -87,14 +87,5 @@
"processed": "\n
Code review with pull and merge requests is great for open-source but not for development teams or soloists.<\/p>\n\n
On an open-source project, the code changes are most likely being submitted by someone you don't know and don't work with regularly, so having a step to review the code prior to merging it and decide if you want to take on the responsibility of maintaining it is a big decision.<\/p>\n\n
On a development team, you work closely with the person submitting the change request and you have a shared responsibility and ownership of the code being added. The person isn't going to submit their change and not be seen again.<\/p>\n\n
It takes time for code to be reviewed, which means it takes longer for the change to be released to users.<\/p>\n\n
If you're a soloist, are you going to submit a request for you to review your own code?<\/p>\n\n
If you don't need to do code review on your team, do you need to create feature or topic branches?<\/p>\n\n
I'd suggest sticking to one canonical branch and doing trunk-based development instead.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "54fdebe3f9556a6d18a8f24c72f72652",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.050a5113-59bc-461e-ac78-420e16055303.json b/content/node.050a5113-59bc-461e-ac78-420e16055303.json
index 1132b0225..084a763af 100644
--- a/content/node.050a5113-59bc-461e-ac78-420e16055303.json
+++ b/content/node.050a5113-59bc-461e-ac78-420e16055303.json
@@ -87,14 +87,5 @@
"processed": "\n
This week on the Beyond Blocks podcast<\/a>, I'm joined by Dan Leech - a PHP Developer and open-source project creator.<\/p>\n\nHe 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
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
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:32:50+00:00",
- "guid": null,
- "hash": "3cc8c054a1675b2ab1a1ec63dd5f49ad",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.05232b81-d945-4112-99bf-d1adb2552428.json b/content/node.05232b81-d945-4112-99bf-d1adb2552428.json
index 0ae10181f..7fecd4d5b 100644
--- a/content/node.05232b81-d945-4112-99bf-d1adb2552428.json
+++ b/content/node.05232b81-d945-4112-99bf-d1adb2552428.json
@@ -87,14 +87,5 @@
"processed": "\n I've noticed a lot of Developers recently adopting SQLite for their database and I wonder why this is.<\/p>\n\n
Laravel changed their default database to SQLite for local development.<\/p>\n\n
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
Drupal supports using SQLite, but, other than for my automated testing course<\/a>, or when running automated tests, I've always used a MySQL or MariaDB database.<\/p>\n\nMaybe 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:32:50+00:00",
- "guid": null,
- "hash": "91a7ebf19cb056c110911fc721129f1a",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0610a25f-884a-48b6-8be0-e969749d316a.json b/content/node.0610a25f-884a-48b6-8be0-e969749d316a.json
index 33ee76c7b..bddd99e18 100644
--- a/content/node.0610a25f-884a-48b6-8be0-e969749d316a.json
+++ b/content/node.0610a25f-884a-48b6-8be0-e969749d316a.json
@@ -87,14 +87,5 @@
"processed": "\n
With most things, it's easy to see where an issue is. There's only one way to build a car or a mobile phone, for example.<\/p>\n\n
With other things, such as software, it's not as clear.<\/p>\n\n
There are usually multiple ways to achieve the same result, but not all implementations are equal.<\/p>\n\n
It's important to understand if an issue is caused by the software itself or how it's been implemented.<\/p>\n\n
Some approaches may be quicker, better for end-user experience or more performant.<\/p>\n\n
Each has its own advantages and disadvantages.<\/p>\n\n
What was the correct solution then may not be the best one now.<\/p>\n\n
Priorities may have changed or new approaches could be available.<\/p>\n\n
You know more now about the problem that's being solved than you did at the time.<\/p>\n\n
One of the original discarded solutions could now be the best option, or a new option that wasn't previously available that solves the problem in a different way.<\/p>\n\n
The software may be capable of achieving what you want - it may just need to be configured in a different way.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "838a5e92a344c70d064478815bc8dd16",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.062c06ac-6ca0-4b03-8d5e-63a84eb8b9c2.json b/content/node.062c06ac-6ca0-4b03-8d5e-63a84eb8b9c2.json
index 6320964b7..0a46a83dd 100644
--- a/content/node.062c06ac-6ca0-4b03-8d5e-63a84eb8b9c2.json
+++ b/content/node.062c06ac-6ca0-4b03-8d5e-63a84eb8b9c2.json
@@ -87,14 +87,5 @@
"processed": "\n
A quote I heard from DrupalCon, made by my former colleague Tim Lehnen - CTO at the Drupal Association - when talking about contribution:<\/p>\n\n
\n Contribution is what makes Drupal thrive.<\/p>\n \n
Drupal is built by people.<\/p>\n \n
No one entity, no one person builds Drupal.<\/p>\n \n
It's you who builds Drupal.<\/p>\n<\/blockquote>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "957b36c5f9d9b70a87a9a60d1f31f9ab",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.066297b1-ab00-4769-afe1-d3831ed2a654.json b/content/node.066297b1-ab00-4769-afe1-d3831ed2a654.json
index 8f731db06..b062c09d1 100644
--- a/content/node.066297b1-ab00-4769-afe1-d3831ed2a654.json
+++ b/content/node.066297b1-ab00-4769-afe1-d3831ed2a654.json
@@ -87,14 +87,5 @@
"processed": "\n
As well as writing comments first<\/a>, when writing tests, I sometimes like to write my tests backwards and start by writing the assertions first.<\/p>\n\nI know what I want to assert in the test, so it's an easy place to start.<\/p>\n\n
I'll run it, see the error, fix it and continue working backwards.<\/p>\n\n
For example, I could start with this:<\/p>\n\n
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\nThis 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
In this case, I need to make a request to the page that should render the text:<\/p>\n\n
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\nThis will still fail, as I also need to create the required posts:<\/p>\n\n
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\nNow the test passes.<\/p>\n\n
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:32:50+00:00",
- "guid": null,
- "hash": "3bdc81d1ff8f05f8b1beb3069dfdd370",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.06b8d0b3-318a-4a06-902c-f42ce169774b.json b/content/node.06b8d0b3-318a-4a06-902c-f42ce169774b.json
index 1628a42c1..85520b1bd 100644
--- a/content/node.06b8d0b3-318a-4a06-902c-f42ce169774b.json
+++ b/content/node.06b8d0b3-318a-4a06-902c-f42ce169774b.json
@@ -87,14 +87,5 @@
"processed": "\n
Last week, it was announced that Newport City Council's (my local council) website is now running on LocalGov Drupal - a distribution for council websites.<\/p>\n\n
This increases the total to 44 councils in the UK and Ireland.<\/p>\n\n
Newport is the first Welsh council to use it and the first LocalGov website to be bilingual, serving content in both English and Welsh.<\/p>\n\n
It's great to see Drupal adoption continue to grow in Wales and within the Welsh public sector, and LocalGov being adopted by more councils across the UK and Ireland.<\/p>\n\n
I think LocalGov Drupal is a great project and one I've contributed to previously<\/a>, and I plan to do more in the future.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "2955d4cb562bc0a9ba0456bc040c629b",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.079f2e09-0827-458e-91d3-6dd5b8b80c56.json b/content/node.079f2e09-0827-458e-91d3-6dd5b8b80c56.json
index aac618038..6eb7e4471 100644
--- a/content/node.079f2e09-0827-458e-91d3-6dd5b8b80c56.json
+++ b/content/node.079f2e09-0827-458e-91d3-6dd5b8b80c56.json
@@ -87,14 +87,5 @@
"processed": "\n It's shown in the examples of the conventional commits specification<\/a> as part of the optional footer data.<\/p>\n\nBut is it useful?<\/p>\n\n
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
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
That makes the issue IDs that reference the old IDs useless as no one has access to the issues it references.<\/p>\n\n
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
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
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:32:50+00:00",
- "guid": null,
- "hash": "1029a860138fe970164e891ad1617d01",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.08209d64-40fa-4771-9415-c23e962a5028.json b/content/node.08209d64-40fa-4771-9415-c23e962a5028.json
index 04714395d..48f4d10ef 100644
--- a/content/node.08209d64-40fa-4771-9415-c23e962a5028.json
+++ b/content/node.08209d64-40fa-4771-9415-c23e962a5028.json
@@ -87,14 +87,5 @@
"processed": "\n
Usually, in software development, there isn't always a definitive black-and-white answer to a question or situation.<\/p>\n\n
Most of the time, the answer is \"it depends\".<\/p>\n\n
How you approach a problem depends on context.<\/p>\n\n
How long do you have?<\/p>\n\n
Are you working on the final version or a prototype or minimum-viable product?<\/p>\n\n
Should you use a contributed module or write one yourself?<\/p>\n\n
What if an existing module hasn't been updated for some time or doesn't have tests or other quality checks included?<\/p>\n\n
Do you write custom CSS or use a framework like Tailwind CSS or Bootstrap?<\/p>\n\n
Should this project be written in this framework or CMS, or would a different one be better suited?<\/p>\n\n
Here's the thing...<\/h2>\n\n
There are usually multiple approaches to achieve the same result.<\/p>\n\n
Decisions will depend on a combination of various factors. In a different situation, the answer could be different.<\/p>\n\n
This doesn't make any solution outright wrong.<\/p>\n\n
It was right given the situation.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "f40826212e5c798e718edd8ad155d3c0",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0843614b-645e-4d55-9e70-f960d504cadb.json b/content/node.0843614b-645e-4d55-9e70-f960d504cadb.json
index 8bb3fa25d..d7c6b1967 100644
--- a/content/node.0843614b-645e-4d55-9e70-f960d504cadb.json
+++ b/content/node.0843614b-645e-4d55-9e70-f960d504cadb.json
@@ -87,14 +87,5 @@
"processed": "\n
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
It was a great event with around 35 attendees and two other speakers as well as myself.<\/p>\n\n
The latest version of my slides are online<\/a> as well some updated resources<\/a>.<\/p>\n\nMy next talk will be at the Norfolk Developers conference next month where I'll be presenting an updated version of Taking Flight with Tailwind CSS<\/a>.<\/p>\n\nIf 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:32:50+00:00",
- "guid": null,
- "hash": "c6186e7dbf6c19f8512dc083f70d7840",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.09073a81-2a1b-4200-905b-98b43152fe37.json b/content/node.09073a81-2a1b-4200-905b-98b43152fe37.json
index 8d0dcb4d1..33b4e27f7 100644
--- a/content/node.09073a81-2a1b-4200-905b-98b43152fe37.json
+++ b/content/node.09073a81-2a1b-4200-905b-98b43152fe37.json
@@ -87,14 +87,5 @@
"processed": "\n
\"Frequency reduces difficulty\" is a phrase I heard on a podcast today, though I have heard it before.<\/p>\n\n
It's a better way of saying, \"If it hurts, do it more often\".<\/p>\n\n
If software deployments and releases are large, risky, and contain bugs, break them into smaller, less-risky deployments and release them more often.<\/p>\n\n
If you get a lot of merge conflicts in Git, merge your code more frequently. Make your topic branches as short-lived as possible, or try trunk-based development and avoid topic branches by default.<\/p>\n\n
If writing tests is difficult and takes time, persevere. It will get easier the more you do it, and you'll save time in the future by releasing fewer bugs and being able to refactor safely.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "48855aeeae21e4c8f58c4898ddd9fea4",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.09097ac1-03ea-456c-a1bd-49bdc2bb9499.json b/content/node.09097ac1-03ea-456c-a1bd-49bdc2bb9499.json
index 43b434b79..9e2cbdc6c 100644
--- a/content/node.09097ac1-03ea-456c-a1bd-49bdc2bb9499.json
+++ b/content/node.09097ac1-03ea-456c-a1bd-49bdc2bb9499.json
@@ -87,14 +87,5 @@
"processed": "\n
The Override Node Options module that I said yesterday is used on 35,000 websites isn't a complicated module.<\/p>\n\n
It doesn't add a lot of features.<\/p>\n\n
It solves a problem by adding additional permissions to Drupal that site administrators can assign to user roles and not need to give a more global permission like \"administer nodes\".<\/p>\n\n
The problem being solved is allowing users to set node options, like the created date or published status, in a secure way.<\/p>\n\n
If it wasn't solving a problem, it wouldn't be used on 35,000 Drupal websites.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "1c6afa84bf0230b6fc71cdc42239c6e2",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.098d8367-a714-4e16-97b5-44f42a2a1cc2.json b/content/node.098d8367-a714-4e16-97b5-44f42a2a1cc2.json
index d5d079ef0..2e44c5dce 100644
--- a/content/node.098d8367-a714-4e16-97b5-44f42a2a1cc2.json
+++ b/content/node.098d8367-a714-4e16-97b5-44f42a2a1cc2.json
@@ -87,14 +87,5 @@
"processed": "\n
One of my favorite features that was introducted in PHP 8 was promoted constructor properties.<\/p>\n\n
If I'm passing arguments into a constructor, I can declare a visibility and it will be promoted to a property on the class.<\/p>\n\n
Here's an example of a value of a data transfer object that accepts a sort code and account number as strings:<\/p>\n\n
class AccountDetails {\n\n public function __construct(\n public string $accountNumber,\n public string $sortCode,\n ) {}\n\n}\n<\/code><\/pre>\n\nWithout promoted constructor properties, I'd need to create the properties and assign them manually, and I'd have this:<\/p>\n\n
class AccountDetails {\n\n public string $accountNumber;\n\n public string $sortCode;\n\n public function __construct(\n string $accountNumber,\n string $sortCode,\n ) {\n $this->accountNumber = $accountNumber;\n $this->sortCode = $sortCode;\n }\n\n}\n<\/code><\/pre>\n\nWhilst text editors and IDEs can create the properties automatically, I prefer this as it's less code, more readable and easier to understand.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "6e7b86e1b92a964e048c10b4a1bb65da",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.09d6a39f-ac99-44fc-b660-4f976132d813.json b/content/node.09d6a39f-ac99-44fc-b660-4f976132d813.json
index ea39a1563..96083eea7 100644
--- a/content/node.09d6a39f-ac99-44fc-b660-4f976132d813.json
+++ b/content/node.09d6a39f-ac99-44fc-b660-4f976132d813.json
@@ -87,14 +87,5 @@
"processed": "\n
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
Around that time, I discovered static site generators and built the next version of my website with Jekyll.<\/p>\n\n
I liked how I could write content in simple plain files, export them to HTML and upload them to a server.<\/p>\n\n
Static websites are fast and secure.<\/p>\n\n
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
I later switched to Sculpin, a static site generator written with PHP, which has a lot of similarities with Drupal.<\/p>\n\n
But what if you want the power of Drupal with the benefits of a static website?<\/p>\n\n
Tome<\/a> is a module that turns Drupal into a static site generator.<\/p>\n\nDrupal 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
Sam Mortenson, the creator of the Tome module discussed it on our episode of the Beyond Blocks podcast<\/a> where we also talked about single file components.<\/p>\n\nIf 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:32:50+00:00",
- "guid": null,
- "hash": "2b68ef78311dde7624d8a9f3bf2aecd5",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.09dff532-7bc4-4949-bfdf-7c4a6e59097a.json b/content/node.09dff532-7bc4-4949-bfdf-7c4a6e59097a.json
index d7680363a..ae7fba060 100644
--- a/content/node.09dff532-7bc4-4949-bfdf-7c4a6e59097a.json
+++ b/content/node.09dff532-7bc4-4949-bfdf-7c4a6e59097a.json
@@ -87,14 +87,5 @@
"processed": "\n
I started developing websites in HTML and CSS in 2007 before adopting PHP and Drupal in 2008.<\/p>\n\n
Since then, I've used Drupal 6, 7, 8, 9 and 10 to deliver applications for clients, agencies and in-house teams.<\/p>\n\n
I also use Symfony and Laravel, as well as JavaScript, TypeScript and Vue.js.<\/p>\n\n
Here's the thing<\/h2>\n\n
There isn't one outright \"best\" programming language, CMS or framework.<\/p>\n\n
It depends on the project and its requirements as well as the knowledge and experience of the team working on it.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "6878d25dc442270921c029ddd00724c8",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.09f421c4-eff1-4b5c-a692-45dfbd837758.json b/content/node.09f421c4-eff1-4b5c-a692-45dfbd837758.json
index f2ee22d67..0fa7854b1 100644
--- a/content/node.09f421c4-eff1-4b5c-a692-45dfbd837758.json
+++ b/content/node.09f421c4-eff1-4b5c-a692-45dfbd837758.json
@@ -87,14 +87,5 @@
"processed": "\n
As with client applications, I recommend releasing new versions of open-source software as often as possible.<\/p>\n\n
This makes it easier for users to update to newer versions as they can easily see the changes, and less risky as it's easier to roll back or diagnose the problem if there is an issue.<\/p>\n\n
If you've added a feature or fixed a bug, fewer people will likely use it if it's not within a released version of your project and sat on a development branch or waiting for a tagged release. This means they're not benefiting from the changes and getting value from them.<\/p>\n\n
You can add feature flags to hide work-in-progress features that you don't want people to use yet, but you don't want to block yourself from releasing a new version until it's complete.<\/p>\n\n
Regular releases encourage smaller and simpler changes rather than larger and more complex - and potentially breaking - changes.<\/p>\n\n
I like to have a release day each month to release new versions of my open-source projects, which works well for me.<\/p>\n\n
I have a recurring task on my To Do list to review my projects and tag and release any new versions that are needed.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "2a66b63393fa72ffccd1e378ef840bca",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0a04ac23-4d64-40e8-8e94-ead3cab7129d.json b/content/node.0a04ac23-4d64-40e8-8e94-ead3cab7129d.json
index 0824072c3..31e20b58d 100644
--- a/content/node.0a04ac23-4d64-40e8-8e94-ead3cab7129d.json
+++ b/content/node.0a04ac23-4d64-40e8-8e94-ead3cab7129d.json
@@ -87,14 +87,5 @@
"processed": "\n
Yesterday I replied to a post on X<\/a>:<\/p>\n\n\n 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
\"CI is the practice of merging all developers' working copies to a shared mainline several times a day\"<\/p>\n<\/blockquote>\n\n
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\nCI, 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
It isn't something that is configured or created - it's a process.<\/p>\n\n
Here's the thing<\/h2>\n\n
You can do CI without a CI pipeline and vice versa.<\/p>\n\n
You can have a CI pipeline but not do continuous delivery or deployment.<\/p>\n\n
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
Whilst important, it's not \"CI\".<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "44876b1c656f7fa3e4611f4f47e7c361",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0a2a3238-42ea-46de-8140-94e74f381916.json b/content/node.0a2a3238-42ea-46de-8140-94e74f381916.json
index 0b6fc8df2..8210834a0 100644
--- a/content/node.0a2a3238-42ea-46de-8140-94e74f381916.json
+++ b/content/node.0a2a3238-42ea-46de-8140-94e74f381916.json
@@ -87,14 +87,5 @@
"processed": "\n
Last Friday and Saturday, I was happy to attend and present two sessions at DrupalCamp Ghent in Belgium.<\/p>\n\n
I was able to present talks on automated testing and Tailwind CSS, which were my 99th and 100th talks, respectively!<\/p>\n\n
The sessions were streamed live, or the slides and previous recordings are on my website<\/a>.<\/p>\n\nIt 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
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:32:50+00:00",
- "guid": null,
- "hash": "666722719a2759d76794a08b3c2837fa",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0a3bf034-7203-45c2-aae5-74f9211929fa.json b/content/node.0a3bf034-7203-45c2-aae5-74f9211929fa.json
index c78cc7e4e..a277c3809 100644
--- a/content/node.0a3bf034-7203-45c2-aae5-74f9211929fa.json
+++ b/content/node.0a3bf034-7203-45c2-aae5-74f9211929fa.json
@@ -87,14 +87,5 @@
"processed": "\n
When giving talks and workshops or coaching on automated testing and test-driven development, some people may not have written tests before and aren't familiar with the structure or know where to begin.<\/p>\n\n
In the workshops I ran for DrupalCamp London and DrupalCamp NYC, I wanted to cover this first before writing any implementation code.<\/p>\n\n
Where do you put a test class, and what does it contain?<\/p>\n\n
How do you run the tests, and how can you make it pass or fail?<\/p>\n\n
What we did<\/h2>\n\n
To start, we wrote a test for existing functionality within Drupal core - anonymous users can visit the front page.<\/p>\n\n
This is the whole test:<\/p>\n\n
<?php\n\nnamespace Drupal\\Tests\\my_module\\Functional;\n\nuse Drupal\\Tests\\BrowserTestBase;\nuse Symfony\\Component\\HttpFoundation\\Response;\n\nclass MyModuleTest extends BrowserTestBase {\n\n protected $defaultTheme = 'stark';\n\n \/** @test *\/\n public function the_front_page_loads_for_anonymous_users() {\n $this->drupalGet('<front>');\n\n $this->assertResponse(Response::HTTP_OK);\n }\n\n}\n<\/code><\/pre>\n\nThis is a test someone can write, run and see the test pass.<\/p>\n\n
They can then experiment by changing the values to make the test fail in different ways.<\/p>\n\n
What next?<\/h2>\n\n
Then, we tested anonymous users cannot access the administration pages, which is also already the case in Drupal core, and then authenticated users with the correct permissions could access them.<\/p>\n\n
People were getting the idea by now, and we moved on to writing and testing some of our own code.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "af41a18ab3e2e252ab86e7243333ad9f",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0a3c28cf-0365-40a7-bc3d-074e90bb28ce.json b/content/node.0a3c28cf-0365-40a7-bc3d-074e90bb28ce.json
index 84ff4a80e..76fc6b5ab 100644
--- a/content/node.0a3c28cf-0365-40a7-bc3d-074e90bb28ce.json
+++ b/content/node.0a3c28cf-0365-40a7-bc3d-074e90bb28ce.json
@@ -87,14 +87,5 @@
"processed": "\n
A common cause of not refactoring code is a lack of test coverage.<\/p>\n\n
Why change some code if it works? What if we break it whilst refactoring it and introduce a regression?<\/p>\n\n
If the code has accompanying automated tests, this can't happen.<\/p>\n\n
The tests should be passing before starting a refactor and should be passing once the refactor is complete.<\/p>\n\n
If the tests fail, the refactor was unsuccessful and should be reverted.<\/p>\n\n
If you have a CI pipeline, a failing test should break the pipeline and prevent any further steps if you're doing continuous delivery or deployment whilst signalling to the Developer their refactor was unsuccessful and the pipeline needs to be fixed.<\/p>\n\n
Without tests, the code could be broken during the refactor, and we wouldn't know.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "aa56bdd02fef215659f339a51ad72312",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0a4f05ae-4240-476b-bb57-bcf3d3a598a3.json b/content/node.0a4f05ae-4240-476b-bb57-bcf3d3a598a3.json
index a325627f7..a30d5ea8a 100644
--- a/content/node.0a4f05ae-4240-476b-bb57-bcf3d3a598a3.json
+++ b/content/node.0a4f05ae-4240-476b-bb57-bcf3d3a598a3.json
@@ -87,14 +87,5 @@
"processed": "\n
If feature branches cause conflicts<\/a>, what is the alternative?<\/p>\n\nDon't branch.<\/p>\n\n
Keep all changes on a single branch and avoid merge conflicts between branches by not having branches.<\/p>\n\n
But how can you avoid releasing changes before they are ready?<\/p>\n\n
You can have a local branch with your changes that you don't push and rebase locally, but then you're not doing continuous integration<\/a> and you're just as likely to get conflicts and have incompatible code.<\/p>\n\nOne 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
The better option is to use feature toggles (aka feature flags).<\/p>\n\n
Wrapping code in feature toggles separates deploying the code from releasing the feature.<\/p>\n\n
The code can be released, but the feature isn't active until the toggle is enabled.<\/p>\n\n
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
If you have multiple environments, the same code can be used with different toggles enabled to allow for testing different features.<\/p>\n\n
Then, once the feature is ready to be enabled, there is no deployment needed.<\/p>\n\n
The code is already there - it just needs to be enabled.<\/p>\n\n
For Drupal, there is a Feature Toggle module<\/a> and 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\nAnd, if an issue is discovered, it can also be easily disabled without needing to roll back to the previous version<\/a>.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "118c906a95ca0d083c79dec04035d210",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0ab79b3f-c48b-4e56-a50f-d39baf2df02e.json b/content/node.0ab79b3f-c48b-4e56-a50f-d39baf2df02e.json
index 488519dd7..e148c8235 100644
--- a/content/node.0ab79b3f-c48b-4e56-a50f-d39baf2df02e.json
+++ b/content/node.0ab79b3f-c48b-4e56-a50f-d39baf2df02e.json
@@ -87,14 +87,5 @@
"processed": "\n Instead of using AI to autocomplete code<\/a> or perform tasks within your Drupal website<\/a>, I've seen people using AI as a virtual pair programming partner.<\/p>\n\nSimilar 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
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
Just make sure to validate and verify whatever it gives you.<\/p>\n\n
Once you've committed it, you're responsible for it.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "e41c8f0126dd0649815f7d2f25e91bbc",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0bb8a36a-3c0e-4545-bbc6-b6c5b80b0ee6.json b/content/node.0bb8a36a-3c0e-4545-bbc6-b6c5b80b0ee6.json
index 265d4a56d..d3349ffba 100644
--- a/content/node.0bb8a36a-3c0e-4545-bbc6-b6c5b80b0ee6.json
+++ b/content/node.0bb8a36a-3c0e-4545-bbc6-b6c5b80b0ee6.json
@@ -87,14 +87,5 @@
"processed": "\n
Following the announcement at DrupalCon, the official announcement has been released regarding Drupal 7's end-of-life extension:<\/p>\n\n
\n Today, we are officially announcing that Drupal 7 will reach its end of life on January 5, 2025.<\/p>\n \n
With this final extension, the Drupal Security Team is also adjusting the level of support provided.<\/p>\n \n
This will be the final extension.<\/p>\n<\/blockquote>\n\n
If you're involved with one of the ~400,000 Drupal 7 websites (according to https:\/\/www.drupal.org\/project\/usage\/drupal), what does the additional year and a half of Drupal 7 mean to you?<\/p>\n\n
Will you use the time to find the budget to upgrade, assemble a migration plan, port any missing contributed modules or refactor your custom modules or theme to make it easier to upgrade?<\/p>\n\n
Is it different knowing it\u2019s the final extension compared to the previous time when it wasn\u2019t known if it would be extended again?<\/p>\n\n
If you're stuck on Drupal 7 or staying on it into 2024 or 2025, what's stopping you from upgrading?<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "3d0846676f872cb7c1f67b9afcb995ac",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0be950c9-3eaf-4ac1-9833-8b3f3fde5a0f.json b/content/node.0be950c9-3eaf-4ac1-9833-8b3f3fde5a0f.json
index 833ad0ad6..51bc4fb96 100644
--- a/content/node.0be950c9-3eaf-4ac1-9833-8b3f3fde5a0f.json
+++ b/content/node.0be950c9-3eaf-4ac1-9833-8b3f3fde5a0f.json
@@ -87,14 +87,5 @@
"processed": "\n
I recently saw a social media post that said something like \"Don't add blank lines within functions. They take up space and don't add anything\".<\/p>\n\n
I may have misremembered the exact wording, but that was the gist of it.<\/p>\n\n
I like to add blank lines within my functions to create and add separation between logical blocks of code.<\/p>\n\n
Whilst this doesn't add anything for a computer parsing and serving the code, or a CI pipeline performing checks, it makes the code easier for people to read and understand which, it my opinion, adds its own value - even if the functionality is the same.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "d138c01e7e0e6b18b39148606ce5111a",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0c1ee324-e522-440a-85bf-e91847091ec9.json b/content/node.0c1ee324-e522-440a-85bf-e91847091ec9.json
index b0c147eed..ff224011e 100644
--- a/content/node.0c1ee324-e522-440a-85bf-e91847091ec9.json
+++ b/content/node.0c1ee324-e522-440a-85bf-e91847091ec9.json
@@ -87,14 +87,5 @@
"processed": "\n
A major addition to my Git workflow has been the ability to interactively add hunks of code to be committed.<\/p>\n\n
There's git add -i<\/code> to interactively add, though I usually go straight to git add -p<\/code> to use patch<\/code>.<\/p>\n\nThis will ask you to confirm if you want to add each hunk to the commit (a.k.a. the staging area) or not.<\/p>\n\n
For example, here's the prompt I get whilst working on the post for this email:<\/p>\n\n
diff --git a\/source\/_daily_emails\/2024-05-06.md b\/source\/_daily_emails\/2024-05-06.md\nindex 42fe48f..ef36a2b 100644\n--- a\/source\/_daily_emails\/2024-05-06.md\n+++ b\/source\/_daily_emails\/2024-05-06.md\n@@ -4,10 +4,12 @@ date: 2024-05-06\n permalink: daily\/2024\/05\/06\/interactive-staging\n tags:\n - software-development\n- # - drupal\n- # - php\n- # - podcast\n+ - git\n cta: ~\n snippet: |\n TODO\n ---\n+\n+A major addition to my Git workflow has been the ability to interactively add hunks of code to be committed.\n+\n+There's `git add -i` to interactively add, though I usually go straight to `git add -p` to use `patch`.\n+There's `git add -i` to interactively add, though I usually go straight to `git add -p` to use `patch`.\n(1\/1) Stage this hunk [y,n,q,a,d,s,e,?]?\n<\/code><\/pre>\n\nI can add the whole hunk, split it into smaller hunks, add all the hunks in the file or ignore this hunk and later hunks in the file.<\/p>\n\n
Then the process is repeated for any following hunks.<\/p>\n\n
This means I can add the relevant hunks to craft the commit I want and I can keep my commits small and meaningful, and easy to revert if there is an issue.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "4f660d322ca2ed3306e781c6c10053a1",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0c899647-4916-4ad6-bde0-5ae1f397cc13.json b/content/node.0c899647-4916-4ad6-bde0-5ae1f397cc13.json
index 81952507b..4dba67f2d 100644
--- a/content/node.0c899647-4916-4ad6-bde0-5ae1f397cc13.json
+++ b/content/node.0c899647-4916-4ad6-bde0-5ae1f397cc13.json
@@ -87,14 +87,5 @@
"processed": "\n
I've recently decided I'm going to open source Build Configs tool<\/a> that I use to generate build configuration files for Drupal, Sculpin and Fractal projects.<\/p>\n\nInspired by Workspace<\/a> and others, and based on previous versions of similar tools - most recently by 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\nBefore 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
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
How it works<\/h2>\n\n
There are four steps performed when generating files for a project:<\/p>\n\n
\n- Create a final configuration object from the project's configuration file as well as any defaults.<\/li>\n
- Validate the final configuration.<\/li>\n
- Create a list of files to generate.<\/li>\n
- Generate the files.<\/li>\n<\/ul>\n\n
If I change sculpin<\/code> to sculpin-site<\/code> in a configuration file, for example, it will fail the validation step.<\/p>\n\nBut, I have an opportunity within the first step to perform any normalisation that's needed and to provide a compatibility layer - such as changing sculpin-site<\/code>, which is an invalid value, to sculpin<\/code>.<\/p>\n\nI also renamed symfony<\/code> to symfony-cli<\/code> by performing the same step.<\/p>\n\nThis 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
I can also add deprecation warnings if legacy values are used.<\/p>\n\n
Here's the thing<\/h2>\n\n
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 drupal_set_message()<\/code> was deprecated and changed to use the Messenger<\/code> service before being removed in Drupal 9.<\/p>\n\nIn 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:32:50+00:00",
- "guid": null,
- "hash": "a38ce17b89e3700c2d33876324be5747",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0cc877ae-0361-456e-be2c-73c322fe1780.json b/content/node.0cc877ae-0361-456e-be2c-73c322fe1780.json
index 5da138e98..a7c77963c 100644
--- a/content/node.0cc877ae-0361-456e-be2c-73c322fe1780.json
+++ b/content/node.0cc877ae-0361-456e-be2c-73c322fe1780.json
@@ -87,14 +87,5 @@
"processed": "\n
I started using the Nix package manager in September 2022<\/a> as a replacement for Ansible.<\/p>\n\nSince then, I've switched to daily-driving NixOS as my main operating system and Home Manager to manage my dotfiles (configuration files for managing application settings, like Neovim, tmux and Alacritty).<\/p>\n\n
A benefit I didn't initially think of was that now I can write all my configuration files in the Nix language.<\/p>\n\n
I don't need to write YAML, TOML, INI or JSON configuration files. Nix and Home Manager will convert it for me.<\/p>\n\n
For example, see my Git configuration written in Nix<\/a> which is converted and written to .gitignore.<\/p>\n\nAnd, if there isn't a built-in module for what I need, there are functions like toJSON<\/code> that will convert Nix code to JSON that I can write to a file.<\/p>\n\nThis is also great if a program changes its configuration file language, which Alacritty did recently.<\/p>\n\n
They changed from YAML to TOML and I didn't need to change anything.<\/p>\n\n
Nix has become my one configuration language to rule them all.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "afe58adbc88026446b4472112f8ea2a7",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0ce2a823-c7ad-475b-9cca-29e1b1702e77.json b/content/node.0ce2a823-c7ad-475b-9cca-29e1b1702e77.json
index 4dc6abd1d..287cd3228 100644
--- a/content/node.0ce2a823-c7ad-475b-9cca-29e1b1702e77.json
+++ b/content/node.0ce2a823-c7ad-475b-9cca-29e1b1702e77.json
@@ -87,14 +87,5 @@
"processed": "\n
Computers don't care how code is written or formatted, but humans do.<\/p>\n\n
A computer will parse and execute your code whether it's written on a single line or multiple.<\/p>\n\n
So, don't optimise for computers.<\/p>\n\n
Optimise your code for humans.<\/p>\n\n
People read more code than they write, so write your code in a readable way so it's easy for people to read and understand - not the computer.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "00288ea28683ef7e8d770a0109344500",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0cedee86-a2d2-4325-a662-a7399be15d44.json b/content/node.0cedee86-a2d2-4325-a662-a7399be15d44.json
index d951b54dd..a29ba441a 100644
--- a/content/node.0cedee86-a2d2-4325-a662-a7399be15d44.json
+++ b/content/node.0cedee86-a2d2-4325-a662-a7399be15d44.json
@@ -87,14 +87,5 @@
"processed": "\n
Surprisingly, it's been two and a half years since I last did a live coding stream.<\/p>\n\n
As well as talk recordings and demos, I did a few live streams back then, working on the \"Test-Driven Drupal\" project and submitting a merge request to Drupal core.<\/p>\n\n
It's been something that I'd like to get back into and pick up again, and I plan on doing that within the next few weeks.<\/p>\n\n
I have a new freelance project due to start in December but getting back into streaming seems like a good way to make sure that I put aside time for open-source and side projects, as well as for writing longer form blog posts and hopefully starting to prepare more meetup and conference talks again.<\/p>\n\n
I'll be streaming again on my YouTube channel, so if you'd like to be notified when I do, please subscribe<\/a>.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "ed9692196aea3236ab447bca233fd4bc",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0d65cf74-92ad-4d03-a7d1-90a63c8a2823.json b/content/node.0d65cf74-92ad-4d03-a7d1-90a63c8a2823.json
index 4d8245e34..23660660d 100644
--- a/content/node.0d65cf74-92ad-4d03-a7d1-90a63c8a2823.json
+++ b/content/node.0d65cf74-92ad-4d03-a7d1-90a63c8a2823.json
@@ -87,14 +87,5 @@
"processed": "\n What is a Changelog?<\/h2>\n\n
A Changelog is a file that documents changes made to a codebase.<\/p>\n\n
In its simplest form, it's a plain text file within a code repository, or it can be written in Markdown or reStructuredText or kept within a separate tool like Confluence or Sharepoint. Regardless of where it's kept, the main thing is the content.<\/p>\n\n
It's not a copy of the Git log. It's a summary of the changes to be read by humans and for them to see what's changed, not a list of Git commits.<\/p>\n\n
If you're considering using my open-source package, you can see what changes I've released, when, and what changes are due to release.<\/p>\n\n
How is it structured?<\/h2>\n\n
Each version should have a heading specifying the version number and\/or release date and a list of changes grouped by their type - whether something was added, changed, deprecated, removed, etc. This works well if you use conventional commits!<\/p>\n\n
I like to follow a format called Keep a Changelog<\/a>.<\/p>\n\nThe headings link to a diff so you can see all of the commits and changes made to the code, and there's an Unreleased<\/code> section that shows commits that have yet to be tagged and released.<\/p>\n\nIf you need to present changes to a review or approval board, having an easy-to-read list of changes, separated by their type, is a much clearer format than a list of Git commits.<\/p>\n\n
When should it be updated?<\/h2>\n\n
I recommend continually updating the Changelog rather than leaving it to just before a deployment. It's quick to add it to the Unreleased<\/code> section as part of the commit and update the headings later.<\/p>\n\nCan I see an example?<\/h2>\n\n
Sure. See the one I added to the National Rail Enquiries feed parser library<\/a> I've been working on or the Tailwind CSS starter kit theme for Drupal<\/a>.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "e760bef0560b6cb431513a24b2eb0212",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0d707bca-be14-4504-b500-9e44abebab44.json b/content/node.0d707bca-be14-4504-b500-9e44abebab44.json
index 1fa8cccd0..c820c8490 100644
--- a/content/node.0d707bca-be14-4504-b500-9e44abebab44.json
+++ b/content/node.0d707bca-be14-4504-b500-9e44abebab44.json
@@ -87,14 +87,5 @@
"processed": "\n In some of my first emails to this list, I wrote about just<\/code> and run<\/code> files.<\/p>\n\nBoth allow you to write project-specific aliases and commands. For example, instead of running docker compose exec php phpunit<\/code>, you run just test<\/code> or run test<\/code>.<\/p>\n\nWhile just<\/code> uses a simple Makefile-like syntax, it requires its own program, so it needs to be installed.<\/p>\n\nWhile I have it installed locally, I've had instances where CI pipelines have failed because they can't download and install just<\/code> and not because of an error in my code.<\/p>\n\nHere's the thing<\/h2>\n\n
A run<\/code> script is a file of Bash functions.<\/p>\n\nBecause it's written in Bash, it runs anywhere without installing additional dependencies.<\/p>\n\n
If a CI pipeline fails, which is less often, it's due to a failure within my code and not because of a download error.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "ef1660e036d0cc4b520bdd563fad7f86",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0da14ab3-af09-42cf-9813-877a7a66cf87.json b/content/node.0da14ab3-af09-42cf-9813-877a7a66cf87.json
index 21200a29f..f89286658 100644
--- a/content/node.0da14ab3-af09-42cf-9813-877a7a66cf87.json
+++ b/content/node.0da14ab3-af09-42cf-9813-877a7a66cf87.json
@@ -87,14 +87,5 @@
"processed": "\n
With Drupal 7's end-of-life date of the 5th of January 2025 quickly approaching, I've recently seen again a number of companies offering support for Drupal 7 after its end-of-life date.<\/p>\n\n
I've seen the same in corporate IT environments where they're running versions of software post their EOL date, so it's not only Drupal 7, but I wonder if this is a good thing?<\/p>\n\n
Is this deterring companies from upgrading if they know this is an option, or should everyone upgrade and we can move forward from Drupal 7 and other end-of-life software?<\/p>\n\n
According to https:\/\/www.drupal.org\/project\/usage\/drupal<\/a>, there are still 281,000 active Drupal 7 installations.<\/p>\n\nIt's considerably less than before - this time last year, it was over 380,000 installations - but it's still a lot of Drupal 7 being used.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "e3227fd692a43f0f5a3b4f9afed9df94",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0db2d25b-3e50-4f36-abe1-f84b938c21db.json b/content/node.0db2d25b-3e50-4f36-abe1-f84b938c21db.json
index a39640de0..2eb0d5a9c 100644
--- a/content/node.0db2d25b-3e50-4f36-abe1-f84b938c21db.json
+++ b/content/node.0db2d25b-3e50-4f36-abe1-f84b938c21db.json
@@ -87,14 +87,5 @@
"processed": "\n
A common misunderstanding for new Developers is that Git and GitHub are the same thing, but they aren't.<\/p>\n\n
Git is decentralised, so doesn't rely on using external repositories on services like GitHub, GitLab or Bitbucket.<\/p>\n\n
You can run git init<\/code> and use it locally without pushing to any remote services.<\/p>\n\nThese services also add extra terminology, such as forks, syncing and pull or merge requests which aren't part of Git itself.<\/p>\n\n
This can cause confusion, which is why I think it's important to learn Git itself<\/a> instead of relying on external services or desktop apps.<\/p>\n\nAnd, 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:32:50+00:00",
- "guid": null,
- "hash": "22be20101f09fc0d4e10cd3c6b867b76",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0dc691fb-cba3-4dce-b9ad-94fd84b7ca7f.json b/content/node.0dc691fb-cba3-4dce-b9ad-94fd84b7ca7f.json
index e6fa47566..c074463a1 100644
--- a/content/node.0dc691fb-cba3-4dce-b9ad-94fd84b7ca7f.json
+++ b/content/node.0dc691fb-cba3-4dce-b9ad-94fd84b7ca7f.json
@@ -87,14 +87,5 @@
"processed": "\n
Today, I made my Drupal module template<\/a> compatible with Drupal 10.<\/p>\n\nBecause Drupal 10 is developed from Drupal 9, the changes between the two and the changes required are minimal.<\/p>\n\n
In this case, I only needed to change the core_version_requirement<\/code> in drupal_module_template.info.yml<\/code> from ^9<\/code> to ^9 || ^10<\/code> - meaning the template works for both Drupal 9 and 10, so there's no need for different versions.<\/p>\n\nIf it used any deprecated code that was removed before Drupal 10, I'd have needed to update it to use the Drupal 10-compliant code.<\/p>\n\n
Updating to new major Drupal versions is much easier than it used to be!<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "d9902d3f03d57f8eef7e67d29133f05f",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0dcdf3e3-9f83-426e-9dfa-ab7a28c63951.json b/content/node.0dcdf3e3-9f83-426e-9dfa-ab7a28c63951.json
index 9bf4cfb38..d41ea0a96 100644
--- a/content/node.0dcdf3e3-9f83-426e-9dfa-ab7a28c63951.json
+++ b/content/node.0dcdf3e3-9f83-426e-9dfa-ab7a28c63951.json
@@ -87,14 +87,5 @@
"processed": "\n
I've been a Drupal and Linux user for a long time, as well as using command-line tools and utilities like Neovim and tmux.<\/p>\n\n
Since September 2022, I've used NixOS as my daily operating system on my computers.<\/p>\n\n
Based on similar programs, in particular by ThePrimeagen, I wrote and use a program to automatically open tmux sessions and run initial commands for any project in my Code directory.<\/p>\n\n
In October, he released tmux-sessionizer as its own package<\/a>.<\/p>\n\nThere is a tmux-sessionizer<\/code> already in nixpkgs, but I wrote my own derivation<\/a> to use Prime's.<\/p>\n\nThere was also this problem in the code:<\/p>\n\n
# If someone wants to make this extensible, i'll accept\n# PR\nselected=$(find ~\/ ~\/personal ~\/personal\/dev\/env\/.config -mindepth 1 -maxdepth 1 -type d | fzf)\n<\/code><\/pre>\n\nThese directories don't match what I use on my computers.<\/p>\n\n
People have submitted pull requests, but these haven't yet been merged.<\/p>\n\n
Either I change my directory structure or I can't use it.<\/p>\n\n
But, in my derivation, I can apply my own patch files to make any changes I want - such as changing the directories to ones I'd want to use - making it usable for me.<\/p>\n\n
I can also apply other people's patches, the same as I'm doing with dwm.<\/p>\n\n
Someone has created a pull request to make the directories dynamic based on a configuration file.<\/p>\n\n
I can apply these changes as a patch to my configuration and remove my custom one.<\/p>\n\n
I can make any other changes I want or need to.<\/p>\n\n
The possibilities are endless.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "8a79fcd4efce6727224214430cc26505",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0dd5ea9d-9d43-4a2a-92f5-c140738ffedd.json b/content/node.0dd5ea9d-9d43-4a2a-92f5-c140738ffedd.json
index c1e02dfda..1493409d6 100644
--- a/content/node.0dd5ea9d-9d43-4a2a-92f5-c140738ffedd.json
+++ b/content/node.0dd5ea9d-9d43-4a2a-92f5-c140738ffedd.json
@@ -87,14 +87,5 @@
"processed": "\n
This morning, I was asked a \u201cCould you build\u2026\u201d question.<\/p>\n\n
It was an idea mentioned a short while ago and involves a simple, interactive form on the front end that sends requests to a public API, filters the results from the response and displays them to the user.<\/p>\n\n
I\u2019d probably want to hide the API request behind a service responsible for interacting with the API and filtering the results - ensuring that the API could be switched with something else later if needed.<\/p>\n\n
This afternoon, I built a small proof-of-concept application with Vue.js and TypeScript.<\/p>\n\n
There\u2019s no API, or service retrieving real-time results. All of the data is hard-coded within the App component, as well as the code that filters, sorts and returns the results.<\/p>\n\n
The results are shown by adding a <pre><\/pre><\/code> to the page, with a <pre><\/pre><\/code> to show the input data.<\/p>\n\nThere isn\u2019t even any styling, with just some basic horizontal rules to split the page - similar to these screenshots from Taylor Otwell<\/a> of some work-in-progress versions of Vapor and Nova.<\/p>\n\nA working proof of concept, or a \"spike\", answers the initial \"Can we build...\" question. It can be shown to a client or other stakeholders, act as a starting point for discussions and requirements gathering and then be turned into user stories. It also allows the Developers to validate their initial thoughts and experiment with different approaches.<\/p>\n\n
If the spike is successful, the idea can then be moved forward and implemented in a full way, otherwise, it can be stopped with a minimal amount of effort and time.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "f378ea534b4141dc8290191f8941df2c",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0e1fbc03-a045-4ca4-8925-69e39b67d893.json b/content/node.0e1fbc03-a045-4ca4-8925-69e39b67d893.json
index 98508dec3..a2088d39f 100644
--- a/content/node.0e1fbc03-a045-4ca4-8925-69e39b67d893.json
+++ b/content/node.0e1fbc03-a045-4ca4-8925-69e39b67d893.json
@@ -87,6 +87,5 @@
"processed": "
I've been surprised to still recently find software development agencies using their own proprietary content management systems and frameworks.<\/p>
With so many available open source options, like Drupal and Symfony, why would people write their own?<\/p>
Why spend the time and effort to build basic functionality like user registration and login when existing tools already solve that problem?<\/p>
Why ignore the thousands of open source modules, themes, plugins, packages and libraries that are available?<\/p>
Instead, leverage the tools that already exist and focus on solving domain-specific issues and writing code that's genuinely specific to the project.<\/p>
Then you can contribute some of the saved time back to the project and make it better for yourself and others in the future and ready for the next project.<\/p>",
"summary": ""
}
- ],
- "feeds_item": []
+ ]
}
\ No newline at end of file
diff --git a/content/node.0e2dc3d6-4054-495b-9c8c-bad2475a0c13.json b/content/node.0e2dc3d6-4054-495b-9c8c-bad2475a0c13.json
index 39dd61f07..bc13c42a9 100644
--- a/content/node.0e2dc3d6-4054-495b-9c8c-bad2475a0c13.json
+++ b/content/node.0e2dc3d6-4054-495b-9c8c-bad2475a0c13.json
@@ -87,14 +87,5 @@
"processed": "\n
I've built Drupal websites for 18 years and have worked with versions as old as Drupal 5.<\/p>\n\n
A common issue for people using the CMS has been the editorial experience when adding and editing content.<\/p>\n\n
Once logged in, to add or edit a node, they need to go to a separate administration screen to enter or change the content.<\/p>\n\n
The administration page usually looks nothing like what the page will look like once published, with the user only seeing large forms and different styles, or a different theme altogether.<\/p>\n\n
There is a page preview option, but this only works once the forms have been completed and requires the user to be able to \"see\" how the page will look beforehand and know what content will appear where.<\/p>\n\n
This has become trickier with the use of Paragraphs and entity reference fields, where the editor only sees the title of the content they want to reference but not what they will see or how it will look.<\/p>\n\n
As well as being difficult to create content, it also makes it difficult to edit it.<\/p>\n\n
Layout Builder<\/h2>\n\n
This is why I like Drupal's Layout Builder module.<\/p>\n\n
Originally released as a contributed module, it has been part of Drupal core since 8.7 and allows editors to be able to create complex pages using a drag and drop interface and instantly see how they look.<\/p>\n\n
There's now an ecosystem of Layout Builder-related modules, including one I wrote<\/a>, that add more functionality to the Layout Builder, such as adding more template suggestions, restricting the available blocks, or adding inline styles - making it even more powerful.<\/p>\n\nIf you have a Drupal site and haven't tried Layout Builder, you can incrementally opt in and only enable it for certain content types. You don't need to go all in straight away.<\/p>\n\n
But, I think that once you've tried it, you won't be able to go back.<\/p>\n\n ",
"summary": null
}
- ],
- "feeds_item": [
- {
- "imported": "1970-01-01T00:32:50+00:00",
- "guid": null,
- "hash": "cba5205b68a6ba553b9b34ef661692d2",
- "target_type": "feeds_feed",
- "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
- }
]
}
\ No newline at end of file
diff --git a/content/node.0f327d3d-33ce-498a-9234-6c1fe9f51d6a.json b/content/node.0f327d3d-33ce-498a-9234-6c1fe9f51d6a.json
index f9ba1ccbd..d74cece71 100644
--- a/content/node.0f327d3d-33ce-498a-9234-6c1fe9f51d6a.json
+++ b/content/node.0f327d3d-33ce-498a-9234-6c1fe9f51d6a.json
@@ -87,14 +87,5 @@
"processed": "\n
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
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