Change old /archive/* links to /daily/*
This commit is contained in:
parent
661669f2a5
commit
538141466c
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
pubDate: 2022-08-20
|
||||
title: "A return to offline meetups and conferences"
|
||||
permalink: "archive/2022/08/20/return-to-offline-meetups-conferences"
|
||||
permalink: "daily/2022/08/20/return-to-offline-meetups-conferences"
|
||||
tags: ["community"]
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
pubDate: 2022-08-23
|
||||
title: "Git: GUI or command-line?"
|
||||
permalink: "archive/2022/08/23/git-gui-command-line"
|
||||
permalink: "daily/2022/08/23/git-gui-command-line"
|
||||
tags:
|
||||
- "git"
|
||||
---
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
pubDate: 2022-08-25
|
||||
title: "Why I work in Neovim"
|
||||
tags: ["vim", "neovim"]
|
||||
permalink: "archive/2022/08/25/why-i-work-in-neovim"
|
||||
permalink: "daily/2022/08/25/why-i-work-in-neovim"
|
||||
---
|
||||
|
||||
Over a year ago, I posted that I was [switching to using Neovim full-time]({{site.url}}/blog/going-full-vim) for my development work.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
pubDate: 2022-08-26
|
||||
title: "Always be learning"
|
||||
permalink: "archive/2022/08/26/always-be-learning"
|
||||
permalink: "daily/2022/08/26/always-be-learning"
|
||||
---
|
||||
|
||||
I've been a Developer for 15 years and one thing that I've always focussed on is to always keep learning.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
pubDate: 2022-08-27
|
||||
title: "Giving back"
|
||||
permalink: "archive/2022/08/27/giving-back"
|
||||
permalink: "daily/2022/08/27/giving-back"
|
||||
---
|
||||
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
pubDate: 2022-08-28
|
||||
title: "How I started programming"
|
||||
permalink: "archive/2022-08-28/how-started-programming"
|
||||
permalink: "daily/2022-08-28/how-started-programming"
|
||||
---
|
||||
|
||||
In 2007, I was working in the IT sector in a Desktop Support role but hadn't done any coding professionally.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
pubDate: 2022-08-29
|
||||
title: "Why I like Drupal"
|
||||
permalink: "archive/2022/08/29/why-like-drupal"
|
||||
permalink: "daily/2022/08/29/why-like-drupal"
|
||||
tags: ["drupal"]
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
---
|
||||
pubDate: 2022-08-30
|
||||
title: "Why I don't only use Drupal"
|
||||
permalink: "archive/2022/08/30/why-dont-only-use-drupal"
|
||||
permalink: "daily/2022/08/30/why-dont-only-use-drupal"
|
||||
tags: ["drupal"]
|
||||
---
|
||||
|
||||
Yesterday, [I shared some of the reasons]({{site.url}}/archive/2022/08/29/why-like-drupal) why I like Drupal and why I use it for the majority of my projects. But, as I said, I don't use it exclusively and for some projects I used various different tools.
|
||||
Yesterday, [I shared some of the reasons]({{site.url}}/daily/2022/08/29/why-like-drupal) why I like Drupal and why I use it for the majority of my projects. But, as I said, I don't use it exclusively and for some projects I used various different tools.
|
||||
|
||||
Essentially, I always try to recommend and use the best tool for the job.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: "To monorepo, or not to monorepo?"
|
||||
permalink: "archive/2022/08/31/monorepo-or-not"
|
||||
permalink: "daily/2022/08/31/monorepo-or-not"
|
||||
pubDate: 2022-08-31
|
||||
tags: ["git"]
|
||||
---
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
pubDate: 2022-09-01
|
||||
title: "Conventional commits and CHANGELOGs"
|
||||
tags: []
|
||||
permalink: "archive/2022/09/01/conventional-commits-changelogs"
|
||||
permalink: "daily/2022/09/01/conventional-commits-changelogs"
|
||||
---
|
||||
|
||||
One of the things that I've done since joining my current team is to implement a standard approach for our commit messages.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "Automating all the things with Ansible"
|
||||
pubDate: 2022-09-02
|
||||
permalink: "archive/2022/09/02/automating-all-the-things-with-ansible"
|
||||
permalink: "daily/2022/09/02/automating-all-the-things-with-ansible"
|
||||
tags: ["ansible"]
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "Using Ansible for server configuration"
|
||||
pubDate: 2022-09-04
|
||||
permalink: "archive/2022/09/04/using-ansible-for-server-configuration"
|
||||
permalink: "daily/2022/09/04/using-ansible-for-server-configuration"
|
||||
---
|
||||
|
||||
[In yesterday's email]({{site.url}}/archives/2022/09/03/creating-infrastructure-with-ansible), I described how to set up a blank server with Ansible.
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
---
|
||||
title: "Using Ansible for local environment configuration"
|
||||
pubDate: 2022-09-05
|
||||
permalink: "archive/2022/09/05/using-ansible-for-local-configuration"
|
||||
permalink: "daily/2022/09/05/using-ansible-for-local-configuration"
|
||||
---
|
||||
|
||||
As well as [configuring servers]({{site.url}}/archive/2022/09/04/using-ansible-for-server-configuration), you can use Ansible to configure your own local machine and development environment.
|
||||
As well as [configuring servers]({{site.url}}/daily/2022/09/04/using-ansible-for-server-configuration), you can use Ansible to configure your own local machine and development environment.
|
||||
|
||||
The change that you need to make is within the `hosts.ini` file:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "Deploying applications with Ansible"
|
||||
pubDate: 2022-09-06
|
||||
permalink: "archive/2022/09/06/deploying-applications-with-ansible"
|
||||
permalink: "daily/2022/09/06/deploying-applications-with-ansible"
|
||||
---
|
||||
|
||||
The last few days' emails have been about using Ansible to create and configure infrastructure, but it can also be used to deploy application code.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "My Tailwind CSS origin story"
|
||||
pubDate: 2022-09-07
|
||||
permalink: "archive/2022/09/07/my-tailwind-css-origin-story"
|
||||
permalink: "daily/2022/09/07/my-tailwind-css-origin-story"
|
||||
tags: ["tailwind-css"]
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "Keeping secrets with Ansible Vault"
|
||||
pubDate: 2022-09-08
|
||||
permalink: "archive/2022/09/08/keeping-secrets-with-ansible-vault"
|
||||
permalink: "daily/2022/09/08/keeping-secrets-with-ansible-vault"
|
||||
tags: ["ansible"]
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "Refactoring a Tailwind CSS component"
|
||||
pubDate: 2022-09-09
|
||||
permalink: "archive/2022/09/09/refactoring-tailwind-component"
|
||||
permalink: "daily/2022/09/09/refactoring-tailwind-component"
|
||||
tags: ["tailwind-css"]
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "Automating Ansible deployments in CI"
|
||||
pubDate: 2022-09-10
|
||||
permalink: "archive/2022/09/10/automating-ansible-deployments-ci"
|
||||
permalink: "daily/2022/09/10/automating-ansible-deployments-ci"
|
||||
tags: ["ansible"]
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "Custom styles in Tailwind CSS: `@apply`, `theme` or custom plugins"
|
||||
pubDate: 2022-09-11
|
||||
permalink: "archive/2022/09/11/custom-styles-tailwind-css-apply-theme-custom-plugins"
|
||||
permalink: "daily/2022/09/11/custom-styles-tailwind-css-apply-theme-custom-plugins"
|
||||
tags: ["tailwind-css"]
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "A month of daily emails"
|
||||
pubDate: 2022-09-12
|
||||
permalink: "archive/2022/09/12/month-daily-emails"
|
||||
permalink: "daily/2022/09/12/month-daily-emails"
|
||||
---
|
||||
|
||||
It’s already been a month since I started my email list and writing daily emails.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "The simplest Drupal test"
|
||||
pubDate: 2022-09-14
|
||||
permalink: "archive/2022/09/14/simpletest-drupal-test"
|
||||
permalink: "daily/2022/09/14/simpletest-drupal-test"
|
||||
---
|
||||
|
||||
Most of my work uses the Drupal framework, and I've given talks and workshops on automated testing and building custom Drupal modules with test-driven development. Today, I wanted to see how quickly I could get a working test suite on a new Drupal project.
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
---
|
||||
title: "Why I mostly write functional and integration tests"
|
||||
pubDate: 2022-09-16
|
||||
permalink: "archive/2022/09/16/why-mostly-write-functional-and-integration-tests"
|
||||
permalink: "daily/2022/09/16/why-mostly-write-functional-and-integration-tests"
|
||||
tags: ["drupal"]
|
||||
---
|
||||
|
||||
In [Wednesday's email]({{site.url}}/archive/2022/09/14/simpletest-drupal-test), I showed how quick it is to get started writing automated tests for a new Drupal module, starting with a functional test.
|
||||
In [Wednesday's email]({{site.url}}/daily/2022/09/14/simpletest-drupal-test), I showed how quick it is to get started writing automated tests for a new Drupal module, starting with a functional test.
|
||||
|
||||
I prefer the outside-in style (or London approach) of test-driven development, where I start with a the highest-level test that I can for a task. If the task needs me to make a HTTP request, then I’ll use a functional test. If not, I’ll use a kernel (or integration) test.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "Thoughts on automated code formatting"
|
||||
pubDate: 2022-09-17
|
||||
permalink: "archive/2022/09/17/thoughts-automated-code-formatting"
|
||||
permalink: "daily/2022/09/17/thoughts-automated-code-formatting"
|
||||
---
|
||||
|
||||
For a long time, I've been focused on writing code that complies with defined coding standards, either to pass an automated check from a tool like PHP Code Sniffer (PHPCS) or eslint, or a code review from a team member.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "Useful Git configuration"
|
||||
pubDate: 2022-09-19
|
||||
permalink: "archive/2022/09/19/useful-git-configuration"
|
||||
permalink: "daily/2022/09/19/useful-git-configuration"
|
||||
tags: ["git"]
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "Why I like trunk-based development"
|
||||
pubDate: 2022-09-20
|
||||
permalink: "archive/2022/09/20/why-like-trunk-based-development"
|
||||
permalink: "daily/2022/09/20/why-like-trunk-based-development"
|
||||
tags: ["git"]
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "Being a Drupal contribution mentor"
|
||||
pubDate: 2022-09-21
|
||||
permalink: "archive/2022/09/21/being-drupal-contribution-mentor"
|
||||
permalink: "daily/2022/09/21/being-drupal-contribution-mentor"
|
||||
tags: ["drupal"]
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "Releasing a Drupal module template"
|
||||
pubDate: 2022-09-22
|
||||
permalink: "archive/2022/09/22/releasing-drupal-module-template"
|
||||
permalink: "daily/2022/09/22/releasing-drupal-module-template"
|
||||
tags: ["drupal"]
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "ADRs and Technical Design Documents"
|
||||
pubDate: 2022-09-23
|
||||
permalink: "archive/2022/09/23/adrs-technical-design-documents"
|
||||
permalink: "daily/2022/09/23/adrs-technical-design-documents"
|
||||
tags: []
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "Using a component library for front-end development"
|
||||
pubDate: 2022-09-25
|
||||
permalink: "archive/2022/09/25/using-component-library-for-front-end-development"
|
||||
permalink: "daily/2022/09/25/using-component-library-for-front-end-development"
|
||||
tags: []
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "Experimenting with the Nix package manager"
|
||||
pubDate: 2022-09-26
|
||||
permalink: "archive/2022/09/26/experimenting-with-the-nix-package-manager"
|
||||
permalink: "daily/2022/09/26/experimenting-with-the-nix-package-manager"
|
||||
tags: ["nix"]
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,15 +1,15 @@
|
|||
---
|
||||
title: "Mentoring with Drupal Career Online"
|
||||
pubDate: 2022-09-27
|
||||
permalink: "archive/2022/09/27/mentoring-with-drupal-career-online"
|
||||
permalink: "daily/2022/09/27/mentoring-with-drupal-career-online"
|
||||
tags: ["drupal"]
|
||||
---
|
||||
|
||||
Today, I met my new mentee from the Drupal Career Online program.
|
||||
|
||||
[As well as mentoring at events like DrupalCamps and DrupalCons]({{site.url}}/archive/2022/09/21/being-drupal-contribution-mentor), I enjoy mentoring and working with new Developers going through bootcamps and training programmes like Drupal Career Online, some who are experienced Developers who are learning a new skill, and some who are learning how to code and are taking their first steps into programming.
|
||||
[As well as mentoring at events like DrupalCamps and DrupalCons]({{site.url}}/daily/2022/09/21/being-drupal-contribution-mentor), I enjoy mentoring and working with new Developers going through bootcamps and training programmes like Drupal Career Online, some who are experienced Developers who are learning a new skill, and some who are learning how to code and are taking their first steps into programming.
|
||||
|
||||
I've talked about [how I got started programming]({{site.url}}/archive/2022-08-28/how-started-programming), but as self-taught Developer, it would have been great to have had a mentor to ask questions of, to help me get me started, and to make sure that I was going down the right track and learning the correct things.
|
||||
I've talked about [how I got started programming]({{site.url}}/daily/2022-08-28/how-started-programming), but as self-taught Developer, it would have been great to have had a mentor to ask questions of, to help me get me started, and to make sure that I was going down the right track and learning the correct things.
|
||||
|
||||
Maybe this is more applicable these days with more people learning and working from home since COVID-19?
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "Mob programming at PHP South Wales"
|
||||
pubDate: 2022-09-28
|
||||
permalink: "archive/2022/09/28/mob-programming-php-south-wales"
|
||||
permalink: "daily/2022/09/28/mob-programming-php-south-wales"
|
||||
tags: []
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "Store Wars: different state management in Vue.js"
|
||||
pubDate: 2022-09-30
|
||||
permalink: "archive/2022/09/30/store-wars-vuejs"
|
||||
permalink: "daily/2022/09/30/store-wars-vuejs"
|
||||
tags: ["vue"]
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ permalink: daily/2022/10/09/coding-defensively-implicit-explicit
|
|||
tags: [tailwindcss, php]
|
||||
---
|
||||
|
||||
As well as [being introduced to Astro]({{site.url}}/archive/2022/10/08/first-impressions-astro) in Simon's most recent Pro Tailwind workshop, something else that we discussed was implicit vs explicit coding, and coding defensively.
|
||||
As well as [being introduced to Astro]({{site.url}}/daily/2022/10/08/first-impressions-astro) in Simon's most recent Pro Tailwind workshop, something else that we discussed was implicit vs explicit coding, and coding defensively.
|
||||
|
||||
For example, if you had this code:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: Overcoming deployment anxiety
|
||||
pubDate: 2022-10-12
|
||||
permalink: 'archive/2022/10/12/overcoming-deployment-anxiety'
|
||||
permalink: 'daily/2022/10/12/overcoming-deployment-anxiety'
|
||||
---
|
||||
|
||||
As a Developer with 15 years of experience, I still sometimes get "deployment anxiety" - when I've backed up the database and tagged a release, but even though the CI pipelines are passing and the staging site is working, I'm holding off on pushing the latest code to be released to production - trying to think of any potential issues that could arise from this deployment and avoid any downtime.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: 14 years on Drupal.org and working with PHP and Drupal
|
||||
pubDate: 2022-10-17
|
||||
permalink: 'archive/2022/10/17/14-years-drupalorg'
|
||||
permalink: 'daily/2022/10/17/14-years-drupalorg'
|
||||
---
|
||||
|
||||
Today I saw that my Drupal.org profile is showing that I’ve been on that website for 14 years.
|
||||
|
|
|
|||
|
|
@ -1,12 +1,12 @@
|
|||
---
|
||||
title: Pair and mob programming
|
||||
pubDate: 2022-10-18
|
||||
permalink: 'archive/2022/10/18/pair-mob-programming'
|
||||
permalink: 'daily/2022/10/18/pair-mob-programming'
|
||||
---
|
||||
|
||||
As well as my recent session at PHP South Wales, I've also been involved with a lot more mob programming recently with members of my team.
|
||||
|
||||
We recently added a new feature to our codebase that we completed over a couple of mob sessions - starting by describing the problem and some potential solutions within a [technical design document]({{site.url}}/archive/2022/09/23/adrs-technical-design-documents) before moving on to the implementation.
|
||||
We recently added a new feature to our codebase that we completed over a couple of mob sessions - starting by describing the problem and some potential solutions within a [technical design document]({{site.url}}/daily/2022/09/23/adrs-technical-design-documents) before moving on to the implementation.
|
||||
|
||||
I was already familiar with the existing code that we needed to extend, so had some ideas of how to approach parts of the solution which we discussed - but there were other parts that I hadn't thought of.
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ permalink: daily/2022/10/19/run-vs-task-runners
|
|||
# -
|
||||
---
|
||||
|
||||
[I've written a few earlier emails]({{site.url}}/archive/2022/08/15/using-run-file-simplify-project-tasks) about `run` files - a simple bash file that I add to my projects to simplify or combine common commands that I need to run often.
|
||||
[I've written a few earlier emails]({{site.url}}/daily/2022/08/15/using-run-file-simplify-project-tasks) about `run` files - a simple bash file that I add to my projects to simplify or combine common commands that I need to run often.
|
||||
|
||||
Recently, I've looked at a couple of alternatives to see how they compare.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Cherry picking commits is an anti-pattern
|
||||
pubDate: 2022-10-20
|
||||
permalink: >-
|
||||
archive/2022/10/20/cherry-picking-commits-is-an-anti-pattern
|
||||
daily/2022/10/20/cherry-picking-commits-is-an-anti-pattern
|
||||
tags:
|
||||
- git
|
||||
---
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Automated testing and test-driven development are not the same
|
||||
pubDate: 2022-10-21
|
||||
permalink: >-
|
||||
archive/2022/10/21/automated-testing-and-test-driven-development-are-not-the-same
|
||||
daily/2022/10/21/automated-testing-and-test-driven-development-are-not-the-same
|
||||
tags:
|
||||
- testing
|
||||
---
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Looking at LocalGov Drupal
|
||||
pubDate: 2022-10-24
|
||||
permalink: >-
|
||||
archive/2022/10/24/looking-at-localgov-drupal
|
||||
daily/2022/10/24/looking-at-localgov-drupal
|
||||
tags:
|
||||
- drupal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
What are Drupal distributions?
|
||||
pubDate: 2022-10-25
|
||||
permalink: >-
|
||||
archive/2022/10/25/what-are-drupal-distributions
|
||||
daily/2022/10/25/what-are-drupal-distributions
|
||||
tags:
|
||||
- drupal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Neovim as a Personalised Development Environment
|
||||
pubDate: 2022-10-26
|
||||
permalink: >-
|
||||
archive/2022/10/26/neovim-as-a-personalised-development-environment
|
||||
daily/2022/10/26/neovim-as-a-personalised-development-environment
|
||||
tags:
|
||||
- neovim
|
||||
---
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Getting back into live streaming
|
||||
pubDate: 2022-10-27
|
||||
permalink: >-
|
||||
archive/2022/10/27/getting-back-into-live-streaming
|
||||
daily/2022/10/27/getting-back-into-live-streaming
|
||||
---
|
||||
|
||||
Surprisingly, it's been two and a half years since I last did a live coding stream.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Why write framework agnostic packages?
|
||||
pubDate: 2022-10-28
|
||||
permalink: >-
|
||||
archive/2022/10/28/why-write-framework-agnostic-packages
|
||||
daily/2022/10/28/why-write-framework-agnostic-packages
|
||||
tags:
|
||||
- php
|
||||
---
|
||||
|
|
|
|||
|
|
@ -3,12 +3,12 @@ title: >
|
|||
The open-source-first development workflow
|
||||
pubDate: 2022-10-29
|
||||
permalink: >-
|
||||
archive/2022/10/29/the-open-source-first-development-workflow
|
||||
daily/2022/10/29/the-open-source-first-development-workflow
|
||||
tags:
|
||||
- open-source
|
||||
---
|
||||
|
||||
Yesterday's email talked about [writing reusable, framework-agnostic packages]({{site.url}}/archive/2022/10/28/why-write-framework-agnostic-packages) but didn't mention where those packages could be located.
|
||||
Yesterday's email talked about [writing reusable, framework-agnostic packages]({{site.url}}/daily/2022/10/28/why-write-framework-agnostic-packages) but didn't mention where those packages could be located.
|
||||
|
||||
They could be kept within a private repository and still have the same benefits, such as re-usability for internal projects, but I like to open-source code as often as I can and make it available publicly to see and use.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Refactoring one large test into multiple smaller tests
|
||||
pubDate: 2022-10-30
|
||||
permalink: >-
|
||||
archive/2022/10/30/refactoring-one-large-test-into-multiple-smaller-tests
|
||||
daily/2022/10/30/refactoring-one-large-test-into-multiple-smaller-tests
|
||||
tags:
|
||||
- php
|
||||
- phpunit
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Are sprints incompatible with Continuous Deployment?
|
||||
pubDate: 2022-11-08
|
||||
permalink: >-
|
||||
archive/2022/11/08/are-sprints-incompatible-with-continuous-deployment
|
||||
daily/2022/11/08/are-sprints-incompatible-with-continuous-deployment
|
||||
# tags:
|
||||
# - a
|
||||
# - b
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Your conference talk has been accepted
|
||||
pubDate: 2022-11-09
|
||||
permalink: >-
|
||||
archive/2022/11/09/your-conference-talk-has-been-accepted
|
||||
daily/2022/11/09/your-conference-talk-has-been-accepted
|
||||
---
|
||||
|
||||
I’m happy to have had a conference talk proposal accepted for what will be my first in-person conference since DrupalCamp London in February 2020.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Creating a small proof-of-concept application in an afternoon
|
||||
pubDate: 2022-11-11
|
||||
permalink: >-
|
||||
archive/2022/11/12/creating-small-proof-of-concept-application-afternoon
|
||||
daily/2022/11/12/creating-small-proof-of-concept-application-afternoon
|
||||
# tags:
|
||||
# - a
|
||||
# - b
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Building a minimum viable product and managing technical debt
|
||||
pubDate: 2022-11-12
|
||||
permalink: >-
|
||||
archive/2022/11/12/building-a-minimum-viable-product-and-managing-technical-debt
|
||||
daily/2022/11/12/building-a-minimum-viable-product-and-managing-technical-debt
|
||||
# tags:
|
||||
# - a
|
||||
# - b
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
How I manage multiple Drupal websites using the same codebase
|
||||
pubDate: 2022-11-13
|
||||
permalink: >-
|
||||
archive/2022/11/13/how-i-manage-multiple-drupal-websites-using-the-same-codebase
|
||||
daily/2022/11/13/how-i-manage-multiple-drupal-websites-using-the-same-codebase
|
||||
tags:
|
||||
- drupal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Camel-case or snake-case for test methods?
|
||||
pubDate: 2022-11-14
|
||||
permalink: >-
|
||||
archive/2022/11/14/camel-case-or-snake-case-for-test-methods
|
||||
daily/2022/11/14/camel-case-or-snake-case-for-test-methods
|
||||
tags:
|
||||
- testing
|
||||
---
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Writing good automated test names
|
||||
pubDate: 2022-11-15
|
||||
permalink: >-
|
||||
archive/2022/11/15/writing-good-automated-test-names
|
||||
daily/2022/11/15/writing-good-automated-test-names
|
||||
tags:
|
||||
- testing
|
||||
---
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Why don't you write automated tests?
|
||||
pubDate: 2022-11-16
|
||||
permalink: >-
|
||||
archive/2022/11/16/why-don't-you-write-automated-tests
|
||||
daily/2022/11/16/why-don't-you-write-automated-tests
|
||||
tags:
|
||||
- testing
|
||||
---
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Agnostic CI pipelines with run files
|
||||
pubDate: 2022-11-17
|
||||
permalink: >-
|
||||
archive/2022/11/17/agnostic-ci-pipelines-with-run-files
|
||||
daily/2022/11/17/agnostic-ci-pipelines-with-run-files
|
||||
---
|
||||
|
||||
As I work on various projects, I use several different CI tools, such as GitHub Actions, Bitbucket Pipelines, and GitLab CI, as well as hosting providers that have build and deploy steps.
|
||||
|
|
@ -12,6 +12,6 @@ Some only run continuous integration checks, like automated tests and static ana
|
|||
|
||||
Each tool has its configuration file with different settings and formats.
|
||||
|
||||
Rather than being too tightly coupled to a particular tool, I like to keep things as agnostic as possible and [use a run file]({{site.url}}/archive/2022/08/15/using-run-file-simplify-project-tasks) with separate `ci:build` and `ci:deploy` tasks.
|
||||
Rather than being too tightly coupled to a particular tool, I like to keep things as agnostic as possible and [use a run file]({{site.url}}/daily/2022/08/15/using-run-file-simplify-project-tasks) with separate `ci:build` and `ci:deploy` tasks.
|
||||
|
||||
This means that all the logic is within the run file rather than the CI tool-specific configuration file, so the file is shorter and cleaner; I can make changes to the CI tasks locally and quickly test changes and iterate, and also, as the logic is within the run file, I can easily switch to a different CI tool if needed without making changes to the tasks themselves.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
One test a day keeps bugs away
|
||||
pubDate: 2022-11-18
|
||||
permalink: >-
|
||||
archive/2022/11/18/one-test-a-day-keeps-bugs-away
|
||||
daily/2022/11/18/one-test-a-day-keeps-bugs-away
|
||||
tags:
|
||||
- testing
|
||||
---
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Are missing tests a blocker to refactoring?
|
||||
pubDate: 2022-11-19
|
||||
permalink: >-
|
||||
archive/2022/11/19/are-missing-tests-a-blocker-to-refactoring
|
||||
daily/2022/11/19/are-missing-tests-a-blocker-to-refactoring
|
||||
---
|
||||
|
||||
Is having automated tests a prerequisite for refactoring a piece of code?
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Version-controlled commented-out code
|
||||
pubDate: 2022-11-20
|
||||
permalink: >-
|
||||
archive/2022/11/20/version-controlled-commented-out-code
|
||||
daily/2022/11/20/version-controlled-commented-out-code
|
||||
tags:
|
||||
- git
|
||||
---
|
||||
|
|
|
|||
|
|
@ -3,12 +3,12 @@ title: >
|
|||
Git tricks to avoid committing commented-out and other unneeded code
|
||||
pubDate: 2022-11-21
|
||||
permalink: >-
|
||||
archive/2022/11/21/git-tricks-to-avoid-committing-commented-out-and-other-unneeded-code
|
||||
daily/2022/11/21/git-tricks-to-avoid-committing-commented-out-and-other-unneeded-code
|
||||
tags:
|
||||
- git
|
||||
---
|
||||
|
||||
[Yesterday's email]({{site.url}}/archive/2022/11/20/version-controlled-commented-out-code) talked about whether commented-out code should be present if your code is version-controlled, but how do you avoid committing it in the first place?
|
||||
[Yesterday's email]({{site.url}}/daily/2022/11/20/version-controlled-commented-out-code) talked about whether commented-out code should be present if your code is version-controlled, but how do you avoid committing it in the first place?
|
||||
|
||||
You could make sure that you remove everything manually before you stage and commit your changes, or I like to use `git add --patch` (or `git add -p`) to interactively stage my changes, allowing me to select which parts of files I want to include in my commit and ignore anything else. The `--patch` option also works for other commands, including `checkout` and `reset`.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
tldr
|
||||
pubDate: 2022-11-22
|
||||
permalink: >-
|
||||
archive/2022/11/22/tldr
|
||||
daily/2022/11/22/tldr
|
||||
# tags:
|
||||
# - a
|
||||
# - b
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Do you need to branch if you're the only one working on a project?
|
||||
pubDate: 2022-11-23
|
||||
permalink: >-
|
||||
archive/2022/11/23/do-you-need-to-branch
|
||||
daily/2022/11/23/do-you-need-to-branch
|
||||
tags:
|
||||
- git
|
||||
---
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Doing the simplest possible thing
|
||||
pubDate: 2022-11-24
|
||||
permalink: >-
|
||||
archive/2022/11/24/doing-the-simplest-possible-thing
|
||||
daily/2022/11/24/doing-the-simplest-possible-thing
|
||||
---
|
||||
|
||||
I spent most of today working on some code I wrote for the first phase of a client project a few months ago.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Plan, then code
|
||||
pubDate: 2022-11-25
|
||||
permalink: >-
|
||||
archive/2022/11/25/plan-then-code
|
||||
daily/2022/11/25/plan-then-code
|
||||
---
|
||||
|
||||
Recently I [saw this tweet](https://twitter.com/OneJKMolina/status/1303047499238776832) in a screenshot on a LinkedIn post.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Ship, Show or Ask
|
||||
pubDate: 2022-11-30
|
||||
permalink: >-
|
||||
archive/2022/11/30/ship-show-or-ask
|
||||
daily/2022/11/30/ship-show-or-ask
|
||||
tags:
|
||||
- git
|
||||
---
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Writing readable code
|
||||
pubDate: 2022-12-01
|
||||
permalink: >-
|
||||
archive/2022/12/01/writing-readable-code
|
||||
daily/2022/12/01/writing-readable-code
|
||||
---
|
||||
|
||||
This week, I needed to investigate and fix a bug within some existing code.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Commit and push something every day
|
||||
pubDate: 2022-12-02
|
||||
permalink: >-
|
||||
archive/2022/12/02/commit-and-push-something-every-day
|
||||
daily/2022/12/02/commit-and-push-something-every-day
|
||||
---
|
||||
|
||||
One of the significant changes that I've found and that's benefitted me whilst developing is to commit and push something every day.
|
||||
|
|
@ -12,13 +12,13 @@ It doesn't need to be a whole feature. It could be a new class with its passing
|
|||
|
||||
It could be a small refactor - renaming a variable or class name that makes some code easier to read or removing some commented-out code that isn't doing anything other than adding visual clutter.
|
||||
|
||||
It could be updating some documentation or [writing a technical document]({{site.url}}/archive/2022/09/23/adrs-technical-design-documents); if you keep those in your version control repository, that would help you implement the following change or to make the documentation clearer for the next reader - whether that's you or someone else.
|
||||
It could be updating some documentation or [writing a technical document]({{site.url}}/daily/2022/09/23/adrs-technical-design-documents); if you keep those in your version control repository, that would help you implement the following change or to make the documentation clearer for the next reader - whether that's you or someone else.
|
||||
|
||||
Committing something at least once a day creates a different mindset to "I'll write everything and push it when it's done".
|
||||
|
||||
It makes you break up large tasks into multiple smaller ones and set mini-deadlines for yourself. I used to do the same when I commuted to work on a train and had a task for a freelance project to complete before I arrived. I used to think, "What can I start, finish and commit before I get there?" instead of leaving something incomplete.
|
||||
|
||||
You don't need to push your change to mainline. If you use the ["Ship, Show, Ask" approach]({{site.url}}/archive/2022/11/30/ship-show-or-ask) then you could commit to a temporary branch that you either merge yourself once you know it passes the checks, or to show or get feedback from other team members.
|
||||
You don't need to push your change to mainline. If you use the ["Ship, Show, Ask" approach]({{site.url}}/daily/2022/11/30/ship-show-or-ask) then you could commit to a temporary branch that you either merge yourself once you know it passes the checks, or to show or get feedback from other team members.
|
||||
|
||||
Practicing this becomes a habit, and if you're doing test-driven development and committing after every passing test or refactor, you'll find yourself pushing numerous changes a day.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,10 +3,10 @@ title: >
|
|||
What to do with TODO comments
|
||||
pubDate: 2022-12-03
|
||||
permalink: >-
|
||||
archive/2022/12/03/what-to-do-with-todo-comments
|
||||
daily/2022/12/03/what-to-do-with-todo-comments
|
||||
---
|
||||
|
||||
[In a previous email]({{site.url}}/archive/2022/11/20/version-controlled-commented-out-code), I wrote about commented-out code and whether it should remain in a codebase - especially if it's version controlled and there's a commit log of all changes.
|
||||
[In a previous email]({{site.url}}/daily/2022/11/20/version-controlled-commented-out-code), I wrote about commented-out code and whether it should remain in a codebase - especially if it's version controlled and there's a commit log of all changes.
|
||||
|
||||
But what about TODO comments that remind you to do something?
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Writing "Why first" user stories
|
||||
pubDate: 2022-12-04
|
||||
permalink: >-
|
||||
archive/2022/12/04/writing-why-first-user-stories
|
||||
daily/2022/12/04/writing-why-first-user-stories
|
||||
---
|
||||
|
||||
I've usually written user stories that follow this format:
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Outcomes or output
|
||||
pubDate: 2022-12-05
|
||||
permalink: >-
|
||||
archive/2022/12/05/outcomes-or-output
|
||||
daily/2022/12/05/outcomes-or-output
|
||||
---
|
||||
|
||||
I was reading a Twitter thread recently that [started with this tweet](https://twitter.com/allenholub/status/1594786089994067969).
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Should you comment your code?
|
||||
pubDate: 2022-12-06
|
||||
permalink: >-
|
||||
archive/2022/12/06/should-you-comment-your-code
|
||||
daily/2022/12/06/should-you-comment-your-code
|
||||
---
|
||||
|
||||
Something that I hear often is "self-documenting code", and that code should be easy to understand without comments.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Separating releases from deployments with feature flags
|
||||
pubDate: 2022-12-07
|
||||
permalink: >-
|
||||
archive/2022/12/07/separating-releases-from-deployments-with-feature-flags
|
||||
daily/2022/12/07/separating-releases-from-deployments-with-feature-flags
|
||||
---
|
||||
|
||||
In a typical feature release process, a feature is released when you merge the code and push it to production.
|
||||
|
|
@ -20,4 +20,4 @@ If my feature is incomplete, if it's feature flagged, I can commit and deploy it
|
|||
|
||||
If you wanted, you could enable a feature flag for a subset or a certain subsection of your users - allowing them to test it before making it available to everyone.
|
||||
|
||||
Another way I use feature flags is within a [multi-site Drupal application]({{site.url}}/archive/2022/11/13/how-i-manage-multiple-drupal-websites-using-the-same-codebase) to enable a different feature set per site and allow me to keep one version of the code for all sites to keep this easy to manage and maintain.
|
||||
Another way I use feature flags is within a [multi-site Drupal application]({{site.url}}/daily/2022/11/13/how-i-manage-multiple-drupal-websites-using-the-same-codebase) to enable a different feature set per site and allow me to keep one version of the code for all sites to keep this easy to manage and maintain.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
The Decorator design pattern
|
||||
pubDate: 2022-12-08
|
||||
permalink: >-
|
||||
archive/2022/12/08/the-decorator-design-pattern
|
||||
daily/2022/12/08/the-decorator-design-pattern
|
||||
tags:
|
||||
- design-patterns
|
||||
---
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
How and why I started using PostCSS
|
||||
pubDate: 2022-12-09
|
||||
permalink: >-
|
||||
archive/2022/12/09/how-and-why-i-started-using-postcss
|
||||
daily/2022/12/09/how-and-why-i-started-using-postcss
|
||||
tags:
|
||||
- css
|
||||
- front-end
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Managing databases with Neovim and Docker
|
||||
pubDate: 2022-12-10
|
||||
permalink: >-
|
||||
archive/2022/12/10/managing-databases-with-neovim-and-docker
|
||||
daily/2022/12/10/managing-databases-with-neovim-and-docker
|
||||
tags:
|
||||
- docker
|
||||
- neovim
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Happy Drupal 10 release day!
|
||||
pubDate: 2022-12-15
|
||||
permalink: >-
|
||||
archive/2022/12/15/happy-drupal-10-release-day
|
||||
daily/2022/12/15/happy-drupal-10-release-day
|
||||
tags:
|
||||
- drupal
|
||||
- php
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Automating all the things, including infrastructure
|
||||
pubDate: 2022-12-20
|
||||
permalink: >-
|
||||
archive/2022/12/20/automating-all-the-things,-including-infrastructure
|
||||
daily/2022/12/20/automating-all-the-things,-including-infrastructure
|
||||
tags:
|
||||
- automation
|
||||
- devops
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Duck typing
|
||||
pubDate: 2022-12-21
|
||||
permalink: >-
|
||||
archive/2022/12/21/duck-typing
|
||||
daily/2022/12/21/duck-typing
|
||||
---
|
||||
|
||||
If it looks like a duck, walks like a duck, and quacks like a duck, it must be a duck.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
The Boy Scout rule
|
||||
pubDate: 2022-12-22
|
||||
permalink: >-
|
||||
archive/2022/12/22/the-boy-scout-rule
|
||||
daily/2022/12/22/the-boy-scout-rule
|
||||
---
|
||||
|
||||
The Boy Scout rule is "Always leave the campground cleaner than you found it".
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Speaking at PHP Stoke and nor(DEV):con
|
||||
pubDate: 2022-12-23
|
||||
permalink: >-
|
||||
archive/2022/12/23/speaking-at-php-stoke-and-nordevcon
|
||||
daily/2022/12/23/speaking-at-php-stoke-and-nordevcon
|
||||
tags:
|
||||
- public-speaking
|
||||
---
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Debugging gitignore rules
|
||||
pubDate: 2022-12-28
|
||||
permalink: >-
|
||||
archive/2022/12/28/debugging-gitignore-rules
|
||||
daily/2022/12/28/debugging-gitignore-rules
|
||||
tags:
|
||||
- git
|
||||
---
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
What is the cost of a bug?
|
||||
pubDate: 2022-12-29
|
||||
permalink: >-
|
||||
archive/2022/12/29/what-is-the-cost-of-a-bug
|
||||
daily/2022/12/29/what-is-the-cost-of-a-bug
|
||||
---
|
||||
|
||||
All software has bugs, but each has a different cost depending on when and where it's found.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Tests are living documentation
|
||||
pubDate: 2022-12-30
|
||||
permalink: >-
|
||||
archive/2022/12/30/tests-are-living-documentation
|
||||
daily/2022/12/30/tests-are-living-documentation
|
||||
tags:
|
||||
- testing
|
||||
---
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Just start writing
|
||||
pubDate: 2022-12-31
|
||||
permalink: >-
|
||||
archive/2022/12/31/just-start-writing
|
||||
daily/2022/12/31/just-start-writing
|
||||
tags:
|
||||
- productivity
|
||||
---
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Types and static analysis saved me today
|
||||
pubDate: 2023-01-01
|
||||
permalink: >-
|
||||
archive/2023/01/01/types-and-static-analysis-saved-me-today
|
||||
daily/2023/01/01/types-and-static-analysis-saved-me-today
|
||||
tags:
|
||||
- static-analysis
|
||||
- types
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Don't use arbitrary values in Tailwind CSS
|
||||
pubDate: 2023-01-02
|
||||
permalink: >-
|
||||
archive/2023/01/02/dont-use-arbitrary-values-in-tailwind-css
|
||||
daily/2023/01/02/dont-use-arbitrary-values-in-tailwind-css
|
||||
tags:
|
||||
- tailwind-css
|
||||
---
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Tailwind CSS' extensibility is one of its best features
|
||||
pubDate: 2023-01-03
|
||||
permalink: >-
|
||||
archive/2023/01/03/tailwind-css-extensibility-is-one-of-its-best-features
|
||||
daily/2023/01/03/tailwind-css-extensibility-is-one-of-its-best-features
|
||||
tags:
|
||||
- tailwind-css
|
||||
---
|
||||
|
|
|
|||
|
|
@ -3,12 +3,12 @@ title: >
|
|||
Testable Tailwind CSS plugins
|
||||
pubDate: 2023-01-04
|
||||
permalink: >-
|
||||
archive/2023/01/04/testable-tailwind-css-plugins
|
||||
daily/2023/01/04/testable-tailwind-css-plugins
|
||||
tags:
|
||||
- tailwind-css
|
||||
---
|
||||
|
||||
A great thing about [Tailwind CSS plugins]({{site.url}}/archive/2023/01/03/tailwind-css-extensibility-is-one-of-its-best-features) being written in JavaScript is that they can be tested using tools like Jest.
|
||||
A great thing about [Tailwind CSS plugins]({{site.url}}/daily/2023/01/03/tailwind-css-extensibility-is-one-of-its-best-features) being written in JavaScript is that they can be tested using tools like Jest.
|
||||
|
||||
Here's an example from https://github.com/opdavies/tailwindcss-plugin-jest-example (it may need updating to work with the latest Tailwind versions or to use the latest best practices):
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Adding Tailwind CSS to an existing project
|
||||
pubDate: 2023-01-05
|
||||
permalink: >-
|
||||
archive/2023/01/05/adding-tailwind-to-an-existing-project
|
||||
daily/2023/01/05/adding-tailwind-to-an-existing-project
|
||||
tags:
|
||||
- tailwind-css
|
||||
---
|
||||
|
|
|
|||
|
|
@ -3,18 +3,18 @@ title: >
|
|||
Utility-first or utility-last?
|
||||
pubDate: 2023-01-06
|
||||
permalink: >-
|
||||
archive/2023/01/06/utility-first-or-utility-last
|
||||
daily/2023/01/06/utility-first-or-utility-last
|
||||
tags:
|
||||
- tailwind-css
|
||||
---
|
||||
|
||||
Tailwind CSS is based on the "utility-first" approach, where the majority of styling is done using utility CSS classes. You can still add additional custom styles if needed if there is something that can't be achieved with utilities or would be better placed in a custom CSS stylesheet.
|
||||
|
||||
Utility-last is the opposite approach, where a small number of utilities are used alongside other CSS styles or another framework. This is common when [adding a utility-based framework like Tailwind CSS]({{site.url}}/archive/2023/01/05/adding-tailwind-to-an-existing-project) to an existing project and you want to use it for a new page or component whilst keeping the existing styles.
|
||||
Utility-last is the opposite approach, where a small number of utilities are used alongside other CSS styles or another framework. This is common when [adding a utility-based framework like Tailwind CSS]({{site.url}}/daily/2023/01/05/adding-tailwind-to-an-existing-project) to an existing project and you want to use it for a new page or component whilst keeping the existing styles.
|
||||
|
||||
This is what I did when I started learning Tachyons, and later Tailwind CSS. My project already had styling from another CSS framework, I started using utility classes and over time refactored until only utilities were used and the other styles could be removed.
|
||||
|
||||
You could do the opposite too, and refactor groups of utilities into a CSS component, either by using Tailwind's `@apply` directive or [writing a plugin]({{site.url}}/archive/2023/01/03/tailwind-css-extensibility-is-one-of-its-best-features).
|
||||
You could do the opposite too, and refactor groups of utilities into a CSS component, either by using Tailwind's `@apply` directive or [writing a plugin]({{site.url}}/daily/2023/01/03/tailwind-css-extensibility-is-one-of-its-best-features).
|
||||
|
||||
If you did want to use Tailwind for a small number of utilities, by default, it will only generate classes that are used within HTML or template files, but it can also be configured to only use the core modules that you specify - preventing Developers from using unwanted utility based on the rules for that project.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Reducing utility class duplication
|
||||
pubDate: 2023-01-07
|
||||
permalink: >-
|
||||
archive/2023/01/07/reducing-utility-class-duplication
|
||||
daily/2023/01/07/reducing-utility-class-duplication
|
||||
tags:
|
||||
- tailwind-css
|
||||
---
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Back after PHP Stoke
|
||||
pubDate: 2023-01-16
|
||||
permalink: >-
|
||||
archive/2023/01/16/back-after-php-stoke
|
||||
daily/2023/01/16/back-after-php-stoke
|
||||
# tags:
|
||||
# - a
|
||||
# - b
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Things to know about PHP
|
||||
pubDate: 2023-01-17
|
||||
permalink: >-
|
||||
archive/2023/01/17/things-to-know-about-php
|
||||
daily/2023/01/17/things-to-know-about-php
|
||||
tags:
|
||||
- php
|
||||
---
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Drupal turns 22!
|
||||
pubDate: 2023-01-18
|
||||
permalink: >-
|
||||
archive/2023/01/18/drupal-turns-22
|
||||
daily/2023/01/18/drupal-turns-22
|
||||
tags:
|
||||
- php
|
||||
---
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Long-term maintainability with utility classes and Tailwind CSS
|
||||
pubDate: 2023-01-19
|
||||
permalink: >-
|
||||
archive/2023/01/19/long-term-maintainability-with-utility-classes-and-tailwind-css
|
||||
daily/2023/01/19/long-term-maintainability-with-utility-classes-and-tailwind-css
|
||||
tags:
|
||||
- css
|
||||
- tailwind-css
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Tailwind's classes are your classes
|
||||
pubDate: 2023-01-20
|
||||
permalink: >-
|
||||
archive/2023/01/20/tailwinds-classes-are-your-classes
|
||||
daily/2023/01/20/tailwinds-classes-are-your-classes
|
||||
tags:
|
||||
- css
|
||||
- tailwind-css
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Tailwind: Not just translating CSS to utility classes
|
||||
pubDate: 2023-01-21
|
||||
permalink: >-
|
||||
archive/2023/01/21/tailwind-not-just-translating-css-to-utility-classes
|
||||
daily/2023/01/21/tailwind-not-just-translating-css-to-utility-classes
|
||||
tags:
|
||||
- css
|
||||
- tailwind-css
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Building Bootstrap CSS examples with Tailwind
|
||||
pubDate: 2023-01-22
|
||||
permalink: >-
|
||||
archive/2023/01/22/building-bootstrap-css-examples-with-tailwind
|
||||
daily/2023/01/22/building-bootstrap-css-examples-with-tailwind
|
||||
tags:
|
||||
- css
|
||||
- tailwind-css
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: >
|
|||
Debugging with git bisect
|
||||
pubDate: 2023-01-23
|
||||
permalink: >-
|
||||
archive/2023/01/23/debugging-with-git-bisect
|
||||
daily/2023/01/23/debugging-with-git-bisect
|
||||
tags:
|
||||
- git
|
||||
---
|
||||
|
|
|
|||
|
|
@ -3,12 +3,12 @@ title: >
|
|||
Small commits and good commit messges
|
||||
pubDate: 2023-01-24
|
||||
permalink: >-
|
||||
archive/2023/01/24/small-commits-and-good-commit-messges
|
||||
daily/2023/01/24/small-commits-and-good-commit-messges
|
||||
tags:
|
||||
- git
|
||||
---
|
||||
|
||||
An important thing when using a tool like [git bisect]({{site.url}}/archive/2023/01/23/debugging-with-git-bisect) as well as reviewing pull/merge requests and commits is to have small (aka "atomic") commits.
|
||||
An important thing when using a tool like [git bisect]({{site.url}}/daily/2023/01/23/debugging-with-git-bisect) as well as reviewing pull/merge requests and commits is to have small (aka "atomic") commits.
|
||||
|
||||
Commits with small changes make them easier to review and, if needed, to revert and debug with bisect. If a commit has ten new or changed lines, it's much easier to see and fix a bug than if the commit had a hundred lines.
|
||||
|
||||
|
|
@ -20,4 +20,4 @@ Also take some time to write good, informative commit messages.
|
|||
|
||||
As well as the short one-line subject, you can add as much detail as you need to the body of the message about the change that's being committed, why it's needed, what other approaches were considered or tried, as well as links to supporting documentation such as ADRs, technical design documents or diagrams.
|
||||
|
||||
Having as much information as possible makes it much easier when someone needs to review or fix a specific commit. I like to use the [conventional commits specification]({{site.url}}/archive/2022/09/01/conventional-commits-changelogs), though the main objective is to have all of the information documented so it's available in the future.
|
||||
Having as much information as possible makes it much easier when someone needs to review or fix a specific commit. I like to use the [conventional commits specification]({{site.url}}/daily/2022/09/01/conventional-commits-changelogs), though the main objective is to have all of the information documented so it's available in the future.
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue