DEV Community: Gary Bell

Why you should keep an eye on the job market

Gary Bell — Mon, 01 Mar 2021 08:51:04 +0000

Following the nightmare that was 2020, and the losses of jobs which happened, this may seem like an odd statement. A lot of people are suffered and struggled as a result of losing jobs. Others are very thankful they kept theirs. It may, therefore, come in bad taste to say that you should be keeping an eye on the job market. Especially when a lot of people are fully immersed in it to keep a roof over their heads, or food on their tables.

This isn't a post about pushing for a raise during touch economic times. Nor is it about encouraging people to leave a stable job for something which might be unstable or risky.

That said, one of the reasons to keep an eye on the job market is to make sure you are paid at least the market rate for your role. That may drive some resentment to your current employer if you are (or feel) underpaid. But it may help drive negotiations at any performance review or appraisal to help get you what you are worth.

The main reason, I would suggest, to keep an eye on the job market is to see what trends are occurring. Technology, especially, is a fast moving industry where new skills come up all the time, and new languages, processes, or tools emerge. The last few years have seen a huge rise in JavaScript frameworks like React and Vue becoming in-demand skills. If you are working predominantly with a tech stack which doesn't use these tools, then you should consider learning them in your spare time.

Similarly with new architectural models and languages which support them. The last half-decade has seen a big push to microservice architecture, and a mix of languages. This allows companies to pick the right tool(s) for the job. A lot of those (from what I have seen) appear to be written in Go, a language which seemingly appeared out of nowhere.

Some of these things may be a passing phase and be replaced again in a couple of years. But, if you are able to get involved in some of them, you can add projects to your portfolio which demonstrate your ability to learn. They can demonstrate your ability to adapt. They can also help develop different thought processes for solving various problems.

All of those benefits can lead to new doors opening up in the future. New roles. More senior or decision making roles, should you want that. The benefits of career progression and the economic boos that may bring to you (yes, it usually comes back round to money), are something which a lot of individuals want.

There you have it. Keeping an eye on the job market doesn't mean you need to be open to applying for jobs. See what is out there, what skills they need, and see how you can utilise that information to carve out the career path you want. Hopefully you can help build your way to financial independence at the same time.

PHP Static Site Generators (Twig Templates)

Gary Bell — Mon, 22 Feb 2021 08:51:07 +0000

I've previously loosely covered static site generators and mentioned that they can bring performance benefits to a site. They do this by building the HTML that would otherwise be built by a CMS when a page is requested and storing that as a file with the full content. This means when a request comes in to the web server for a resource, it can directly serve the page, with no processing via a database or similar. Couple that with a CDN and cache like Cloudflare, then those files can be cached closer to your end user, and speed up the site even further.

In this post, I'm going to take a look at some of the static site generators written in PHP, and outline some pros and cons of them.

Sculpin

Sculpin is written for PHP 7 and is quickly installed using Composer. It uses Symfony Bundles to allow you to extend the functionality in a way which may be familiar to you already, and builds pages using Twig templates.

I found it fairly easy to get up and running, but with a few changes needed in places to get URLs how I would want them i.e. without needing /blog/ in every URL. Fortunately the process for that is documented pretty well.

Because the base blog skeleton comes bundled with Bootstrap, the generated CSS is pretty big (nearly 600kB). This is unfortunate as the idea behind a static site generator is to improve website performance. One thing which came out of lighthouse audit tests of a simple sample post (base styling and lipsum text) was to remove unused CSS. It also listed minify CSS as a task to undertake. That may happen as part of a production build, but could lead to a big overhead if not.

A few things which may be off putting for people is the lack of activity around the project. Prior to November 29th 2020, the most recent tweet was in April 2020. At the time of writing, the latest blog post was August 2019. If it wasn't for a recent release, then you'd assume the project was dead!

Speaking of releases, these are few and far between. There was 3.1.0 in December 2020, 3.0.3 was a full year earlier, and 3.02 six month prior to that. It could be that it is just very stable and doesn't need a lot of work. However, there are issues on the project dating back to 2012 which are for older versions and haven't been closed as part of a release, or closed as obsolete due to the new version.

If you like Twig templates, Symfony, and a little bit of configuration in your life, this might be the static site generator for you.

Cecil

Cecil is a generator which only requires one file to get started, the cecil.phar file. Running that and using the commands it comes with should get most people up and running quickly. It requires PHP 7.1+, and uses Twig templates for to generate the site.

With releases every few days, this is one which will be time-consuming to keep up-to-date. Most updates appear to be very small fixes, so getting the updates might not be as essential. Though if you rely on downloading the cecil.phar as part of your CI/CD pipeline, then you will need to consider setting the phar to be a specific URL, rather than the download location online.

The default theme and styling which comes with Cecil is very basic. That's not a bad thing, it means there's a lot of scope for your own creativity. Or to implement a template from elsewhere. Because there's not a lot of styling out of the box, Cecil has a tiny page footprint, and will see the 4x100 score in lighthouse audit with ease.

Documentation for the system is comprehensive, but takes some getting used to. It's not as easy as you might hope to start a fresh and get new blog posts displaying on a grid (like most blog home pages). Adding elements like a list of tags and similar common blog post functionality can be done by reading the documentation and working this into the posts and templates.

Cecil is good, and fast! It will take some getting used to, at least to start with, but is worth checking out.

Symfony Static Dumper

I started this section by looking at Statie, but found it was deprecated from March 2020. It directs users to Symfony Static Dumper. As I like Symfony, I thought I would give it a try. It also means I could use Twig templating to generate the pages.

This differs massively from the others as it builds static static sites from a symfony app. That means you're going to need to create a full blog app and have a database (or manually code every page) to then be able to dump the changes. This is great if you're working on something with multiple contributors who aren't comfortable with source control or markdown. You can build a traditional WYSIWYG platform for them to work on. Then use a CI pipeline or batch job to publish the new pages once they are ready.

Because it's not a static structure, such as markdown, to build the pages, there's greater flexibility in the output. You aren't restricted to needing to follow specific file formats to get the right output. Build the content with whatever tools and editors you normally use, and let the dumper create the static pages from the output normally generated.

I didn't actually test this one further than installing the components, as I don't have a blog platform in place to try it with. Building one for this test wasn't something I wanted to do, as that can take a lot of time and be a source of distraction. If you already have a Symfony application in place serving dynamic pages, this might be something to look in to.

Spress

Spress is another static site generator which runs as a .phar to perform its tasks. Spress requires PHP 7.4+, not 5.6+ as started in the "getting started" documentation, and templating is done using Twig.

Like Cecil, above, the documentation available is comprehensive and easy to understand. Arguably, the Spress documentation is better than Cecil, with slightly more in-depth examples used, and greater functional coverage. However, as has been seen from the PHP requirements, not all of the documentation is accurate, so some trial and error may be needed to get things right.

Also like Sculpin, the default theme (which you should install if you want to make any sort of progress quickly) uses Bootstrap. Spress also includes FontAwesome in the default theme source.
These two items, plus the associated font files and javascript, make up the majority of the page download footprint. This might not seem like it's a lot when the whole page content for an article (a long article), came to 400kB, but over 90% of that footprint is CSS, JavaScript, or fonts.

The last release for Spress was in May 2020, which was the 3.0.0 release. There's been no changes made since then on the master branch, and the issues on GitHub seem a little stale. This is a bit concerning, especially when their Gitter channel hasn't had any activity since May 2020, nor has the blog or the Twitter account.

Getting up and running with Spress is easy enough, so long as you install a theme. If you don't, then there's nothing to build your content into, and you might not have the right structure to generate the output correctly. You will spend a lot of time reading documentation to solve that. Instead, just install the spresso theme as described in the document, and modify a copy of that to build your own theme (don't forget to modify the default theme in config.yml).

Conclusion

Whilst this list is by no means exhaustive for the PHP static site generators which use Twig templating, it should give you some things to think about. Only one of those options has regular updates, but those updates might be too frequent to stay on-top of without breaking things. Two of those have seen their development apparently stagnate, and should leave you with concerns about their long term viability.

Out of all the options here, Sculpin and Cecil are the ones I would look to for getting started with static site generation.

I would avoid the Symfony Static Dumper, unless you already have a Symfony site you want to make static. Building a blog platform only to then make the content itself static will take you way from actually getting content live.

Spress seems overly complicated on the surface, and has the larger learning curve of all of the systems here. Unless there's a clear benefit to using it which I haven't found at a glance, this might be one to avoid if you want to get running quickly and in an easily understandable way.

I prefer Sculpin to get up and running without needing to use a CLI to start new posts. I don't like the time between updates, and the uncertainty around future ones.

I really like the simplicity of Cecil, what it produces, and its general no-nonsense approach. I just feel it updates too often to be considered stable without fully understanding each change. It is good to know that it is regularly maintained and is continually evolving to build a better experience.

There are other options with other templating engines which I will look into on other posts. If you are considering starting, or migrating to, a static site, then give serious consideration and investigation time to Sculpin and Cecil.

Test and Trace - A failure in IT procurement?

Gary Bell — Mon, 15 Feb 2021 08:51:01 +0000

Regardless of where you live on the planet, you will be aware of Covid-19, the novel Coronavirus strain. It's affected all corners of the globe. Depending on how good your Government is will also determine how well your country has dealt with it, and at what cost (a notable well-done to New Zealand, based on UK media, for getting things back to normal quickly).

Here in the UK, the response has been abysmal; money has been thrown at the problem like cost doesn't matter. A great example of this is the 'Test and Trace' system, regularly billed by UK politicians as "world leading". It's also been named 'Track and Trace' and 'Test, Track and Trace'.

Disclaimer: This post is a political discussion centred around the UK Government’s IT procurement, and the checks which should have been taken in relation to the ‘Test and Trace’ system. Please act responsibly to prevent the spread of disease.

It was announced on 16th January 2021 by the Public Accounts Committee that by March 2021 the system will have cost the UK taxpayer £23 billion.

Public Accounts Committee

@commonspac

🧐What's gone wrong with #NHSTestandTrace?

By March it will have cost the #UKtaxpayer £23bn - but it's missed a lot of targets along the way

Monday we'll ask @DHSCgovuk & @didoharding what the plan is to make sure #TTT can deliver for the future

👓👉🏽parliamentlive.tv/event/index/c4…

14:06 PM - 16 Jan 2021

What this highlights is why Governments need impartial IT experts to look at the costing of any IT projects, to provide a realistic insight into the whole thing. Yes, that would remove the nepotism which comes from knowing a prominent MP when something like this happens. It would remove the exorbitant profiteering which seems to run rife within Government contracts which, I speculate, comes as a result of MPs having significant shares in the bidding companies; large profits make for good dividends!

I digress; though it seems to be the only plausible explanation for the cost.

Why?

Looking at the cost-per-day of the project (based on the first 365 days), that's £63,013,698.63. Sixty Three Million Pounds. Per day! That works out around £1 per day, per person (population estimate for 2020 is 67,886,004 on Wikipedia).

According to the UK Government (based on data from ONS), the median weekly wage in the UK is £585; this works out at £30,420 per year. The amount paid for the Test and Trace system could give over 750,000 people the median salary.

Okay, giving money to people wouldn't have solved the crisis, but it helps to show the scale of the cost.

To further illustrate why this has been a monumental failure in cost management, we can look at some of the tech giants out there.

Netflix

Netflix is huge; they serve content to 204 million people in 190 countries. They make their own content, licence content from other studios, and generally keep people entertained. It's well known that they run their infrastructure on AWS, and that AWS is not exactly cheap.

However, being a business with shareholders, Netflix has a responsibility to keep costs down so they can make money. I looked at their financial records from 2019. It shows that their 'Cost of Revenues' specifically relating to 'Technology and development' was $1,545,149,000 (with an exchange rate of $1 = £0.71), that's £1,120,619,312.25 - about 5% of the cost of Test and Trace for a year.

Facebook

Facebook has something everywhere. Many different technologies and various avenues to make revenue. It is estimated that they have 1.8 billion active users per day on their platform. Serving content from a complicated network of friends, businesses, fan pages and other content. It takes a lot of resources to do that, particularly at the speed they do.

Their accounts from 2018 (when they only had an estimated 1.4 billion active users per day) show the cost of running Facebook in 2018 to be just under $31 billion. Of that, $4.15 billion was for share based compensation, so the actual running and other associated costs was more like $27 billion. At the same 1:0.71 exchange rate for the Netflix comparison, that is £19.41 billion.

That covers the cost of Facebook, Instagram, Messenger, WhatsApp, and Occulus.

Twitter

The social media giant, which was the preferred battleground of Donald Trump during his Presidency, has around 330 million active users per month. Again, it has some of the complicated personal networking and "relevant" post integration as Facebook to make money, but it does well.

Twitter's annual account for 2019 show the total costs and expenses (not just technology) at Twitter to be around $3.1 billion; £2.27 billion.

Reality Check

For the £23 billion cost of the UK's test and trace program, you could have run all of Twitter (2019), all of Facebook and associated companies (2018), and covered all of Netflix's 'Technology and development' costs (2019). A total of £22.8 billion, if you were wondering.

Instead, the UK has a system which has repeatedly failed to hit its goals. The same system which requires contact tracers to contact the same household for each individual member of a family. And the very same system which encouraged people to self-isolate, but which prevented them from claiming financial help.

If anyone with a sensible head was approached regarding this program and told the annual cost to run track and trace would be £23 billion, there is no way it would be signed off . A single program which would cost as much as the combined Government spending on "Environmental protection" and "Housing and community amenities", or 57% of the nation's defence budget, would never pass a sense check.

The numbers simply aren't grounded in reality.

A private business has to answer to, and provide value for, its shareholders. A Government should have the same accountability to its citizens as a business does to its shareholders. In the case of Test and Trace, it is the UK taxpayer who has to foot the cost of the system, despite the failings in cost management.

A possible reason for the excessive cost of the system may be related to some misconfiguration in the tech stack used. Without actually pointing fingers, Google’s Firebase has been known to generate large bills if used incorrectly, and AWS misconfigurations can be similarly alarming. If that is the case, then it's a solid case that the contract was given to someone who doesn’t know what they are doing, and the process needs to be reviewed.

What the UK government (and Governments of other nations) needs is a panel of IT experts to review the requirements of projects, and to vet them for inflated prices. Even in times of a pandemic, there should still be a proper tendering process, and things like Test and Trace shouldn't just be handed out lightly with a blank cheque.

Personally, I would be shocked if the actual cost to suppliers of the Test and Trace system came to 10% of the billed cost. The cost of manning call centres is £720 million for a year (18,000 trace staff indicates an average £40,000 per year, assuming cost is purely for staff, not other overheads). I can't imagine the cost of any software hosting being over £10 million a month (£120 million/year). The cost of developing the app shouldn't have topped £500 million for a rushed job with a lot of overtime. Even doubling the £10 million a month hosting cost; with the other estimates, the whole program should have come to around £1.5 billion for a year. It would still be a cost of £4.1 million per day, but a lot easier to imagine.

It would be interesting to see what the project actually cost to run vs. what was actually billed; and how the numbers came about. That's never going to happen because it would show some seriously underhanded tactics, or conflicts of interest in the process. But from an academic side, understanding how it cost so much would be great.

Getting Closer to the Truth

As you dig further into the whole ‘Test and Trace’ system, it eventually becomes apparent that the £23 billion is not all down to IT expenditure. Actual estimates for the cost of the mobile app put that at only (but still high) £35 million. That includes the initial app which was abandoned after spending £10 million. That appears to include the running of the app for a financial year, putting the cost of the app and staffing of the trace contact centre staff at under £1 billion.

What about the other £22 billion?

A lot of that comes down to understanding what ‘Test and Trace’ actually covers. It actually has four objectives:

increase the availability and speed of testing
identify possible close contacts of those who test positive, and asking those close contacts to isolate
rapidly identify and contain outbreaks
enable government to learn about infection rates and respond appropriately.

The speed and availability of testing is something the Government has been pushing to increase. New laboratories, more testing centres, generally a greater percentage of the population tested each day. They have a moonshot goal of testing 10 million people per day, which is estimated to cost an additional £100 billion per year. The cost of which would be attributed to ‘Test and Trace’.

Any positive cases identified will then have the system try and identify the close contacts of those who are infected, and those who may have come into contact with them. This is where the IT side, and the contact centres come in. As we’ve seen, this is only around £1 billion of the cost. But because the Government made a huge deal about the tracing app and the infrastructure around it, that’s all people think of when they hear about ‘Test and Trace’.

Identifying and containing outbreaks is where costs will spiral. In June 2020, local authorities in England were given £300 million to help with Test and Trace. Another £57 million was allocated to the devolved Governments of the Union. That was on top of the £3.2 billion which had been allocated previously to local authorities.

The Government scheme where low income families would be eligible for support of £500 if they had to isolate is also part of the test and trace system. There are around 4million people who would be eligible for that support, totalling £2 billion allocated to it.

Taking the amount allocated to local authorities to help with Test and Trace measures (£3.5bn total), plus £2bn allocated to low income families, and the £1bn for the app and contact centres, that’s £6.5bn. There’s £16.5bn which isn’t easily accounted for. I’ve not yet been able to account for the actual cost of testing, but the cost can’t fully be there either. Around 68 million tests had been conducted between April 2020 and 27th January 2021, which would mean each test cost £242.65 (staff, transportation, testing and returning results).

If the government is to expect 10 million tests per day to cost £100bn per year, then the cost for the test has to drop by several orders of magnitude. Or they are already a lot cheaper than that amount. Which begs the question; where is all of the money for the Test and Trace actually going? I cannot accurately say at this point.

What is apparent, is that it’s not all gone on IT overspending. Which, given the history of Government spending on IT, is actually refreshing.

Unfortunately, because any mention of “Test and Trace” is always shown alongside a picture of the app on a mobile phone, the insinuation that the cost is purely IT related is present in people’s minds. Mine included until I wrote this.

Yes, the UK Government - and probably others around the world - jumped into deals with suppliers without vetting or sense checking them first (PPE, anyone). Despite being critical to everyday life, IT and the associated costs are still seen by some as being excessive, unnecessary, and undesired. That makes the industry as a whole an easy direction to point the finger, deliberately or not, when there’s a high cost involved somewhere.

Is the Test and Trace program a failure in the IT procurement process? Possibly. But the overall cost of battling against the Coronavirus pandemic has brought about far higher expenditure which isn’t as easy to work through, and likely won’t be fully known or understood outside of very tight circles.

Conspiracy theory? Probably. Covering up high-profit backhanders? Likely. Just don’t blame it all on IT, please.

Special Thanks

Special thanks to Faye Sipiano for editing this article (up to the ‘Getting Closer to the Truth’ - she is blameless for typos from there!). You can get in touch with Faye via her website, or on Twitter (@JavaScriptCoff1).

Project Wikis - Share knowledge from the start

Gary Bell — Fri, 12 Feb 2021 08:50:48 +0000

Welcome to Tanuki Tuesday, where I look at the features offered by GitLab. Up this week, knowledge sharing in the form of project Wikis.

Most people will already be familiar with the concept of a wiki, courtesy of Wikipedia and the mass contribution ethos it has. But why would you use a wiki for a project?

Documentation. It's one thing often forgotten in projects, shoehorned into a massive README.md file, or something which developers hope the community will create later. Why? because it's yet something else to design ahead of consumption.

It doesn't have to be!

The wiki feature within GitLab projects provides a useful space to put your documentation. Better still, the content is built using markdown. If developers can contribute to the README.md file, then they will be able to add the content into the wiki.

Getting Started

If you've not got a wiki for a project yet, navigate to your project and select the wiki option in the left-hand menu (of, if g->w if you use keyboard shortcuts) and click the 'Create your first page' button.

This will take you to the page edit screen, where the title will be pre-populated to get you started with the basic home page. You don't need to create the home page straight away, but any time you visit a wiki which has some pages but not a home page, you'll be shown the 'Create New Page' screen for the home page.

What are the benefits of a wiki?

Because the wiki is a separate git repository of its own, it is not checked out at the same time as the project source. This reduces the amount of data needed to be downloaded by anyone cloning the project. It has the added benefit of your project commit history not being clogged up with typo fixes and additions in the wiki, leading to a cleaner commit history for code.

This has the added benefit of allowing small, single word changes to be done without it forming part of a code review on save. Similarly, the repository can be checked out and back in to allow larger scale changes take place outside of the slow nature of editing online. This is particularly useful if there's a mass change of locations to be done.

Each page then gets its own history of changes to be fully transparent about who changed what, and when.

There's no need to design the layout. Sure, great looking documentation looks, well, great. But design resources are often limited. And documentation should be useful and easy to find above all else. By using the wiki the documentation can be produced in a consistent manner from the outset.

Conclusion

If you don't have the time to set up your own documentation site, or to design one, then simply start with a wiki. You can still have useful documentation which develops organically with your project, and is still closely linked to it. In most cases, some documentation is better than none. So create some!

If and when you have the time to design and build a stand-alone site for your documentation, you'll have all of the content you need to get started. It's less of a daunting prospect because it won't be created from scratch, or need someone to understand how things work if they don't already know.

As usual, the GitLab documentation provides a great insight into how to use the Wiki feature, and even how to customise the sidebar menu.

Using Gitpod to start a new project

Gary Bell — Mon, 08 Feb 2021 08:50:48 +0000

Ever since I used Gitpod as part of some early access with GitLab I've wanted to use the platform more. The trouble is, I don't have a lot of projects which justify the time setting up a full config just for development. Normally everything I do small scale stuff, like my password validator.

Now I have a project I want to work on which is bigger in scale, I figured it was a great opportunity to use it from the ground up.

What is Gitpod?

Gitpod is an open source developer platform automating the provisioning of ready-to-code development environments. It streamlines developer workflows by providing prebuilt, collaborative development environments in your browser.
Designed for applications running in the cloud, Gitpod frees engineering teams from the friction of manually setting-up local dev environments, saving dozens of hours and enabling a new level of collaboration to create applications much more quickly than ever before.

Natively integrated with GitLab, GitHub, and Bitbucket, Gitpod automatically and continuously prebuilds dev environments for all your branches. As a result team members can instantly start coding with fresh dev environments for each new task - no matter if you are building a new feature, want to fix a bug, or work on a code review.

Getting Started

Because I use GitLab as my source control, this article will be based on interactions from within GitLab. It should be fairly adaptable for Github or Bitbucket, if either of those are your preferred source control platform.

As this is a Greenfield project, the first step is to create a repository for it. Within GitLab, I chose to initialise it with a README.md file to allow cloning. From this point, the steps should be the same for new or existing projects wanting to get started with Gitpod.

From the Project Overview "details" page, click on the Gitpod button. This will open the repository's default branch within a new Gitpod workspace. When this opens, Theia (Gitpod's IDE), will detect that there is no .gitpod.yml file, and offer to help you create one.

Clicking Setup Project will open a side panel which acts as the guide to start the process.

Because Gitpod uses Docker to serve the content for testing and debugging, some level of Docker knowledge is advisable. Or, at the very least, a willingness to learn. Fortunately, learning docker is one of my goals for 2021. You need to be prepared for fiddling round with a Dockerfile (.gitpod.Dockerfile) or accepting the full Gitpod base one to work with. There's more information on configuring this for Gitpod within the official documentation.

When setting up the Dockerfile for the first time, be aware that Gitpod recommend committing the change to a new branch and opening that as a new workspace. If the Dockerfile fails, then the workspace won't open. It will give the option to open using the default Docker image, but doing this on a new branch will not break the branch for others if you are working on an existing project and using Gitpod only as an IDE.

Be aware that if you're using a Debian base image, you may get stuck on configuring tzdata. This is a common issue with Debian based Docker images, and I've covered it before as part of my GitLab CI/CD series.

If you do run into issues with the Dockerfile on a new branch:

change the .gitpod.Dockerfile on a different workspace (which is why you should do this part on a different branch)
commit the changes
refresh the workspace with the Dockerfile errors.

This will restart the workspace and try to build the environment from the Dockerfile. If it is successful, you'll get the IDE screen and be able to build.

From there you can start building your project to your liking. Create your folder structure, and work with your own dependencies.

Additional configuration

If you have additional services as part of your workspace which you need to expose, you will need to configure the ports to expose as part of the configuration. These don't need to be setup as part of an elaborate Docker compose file. Instead you can treat the whole instance as a single server. Just remember to start each service in the .gitpod.yml file under tasks.

The editor itself works a lot like VS Code, which will suit a lot of people out there. Your normal VS Code extensions can be added to the workspace on startup by adding them to the .gitpod.yml file. For instance

vscode:
  extensions:
    - MehediDracula.php-namespace-resolver@1.1.8
    - vscode.php-language-features@1.52.1
    - felixfbecker.php-pack@1.02

You can find the available extensions at the Open VSX Registry.

If you have specific VS Code settings for a language or project they can be brought straight over into Gitpod, as Theia (the IDE) can be configured using the .vscode/settings.json file (which can also be located at .theia/settings.json). This makes it easier to get up and running if you already use VS Code as your IDE.

Things to be aware of

If you click on the Gitpod button within your repository, this will always create a new workspace within Gitpod (unless you have a workspace for that branch already open).
If you want to open an existing workspace (because there are data there you want to utilise, or any other reason), you need to open the Gitpod workspace dashboard.

Early Conclusion

I've still not done a lot with Gitpod in the grand scheme of things. But getting up and running with it as an IDE and environment isn't that bad so long as you try to strip away the complicated parts. You don't need to think of it as being full-on Docker where you should have separate containers for each service. Pull them all together and use them as one single container.

There are some things which need to be considered, such as getting Apache up and running. When I tried using the service apache2 start command as part of the .gitpod.yml task, it wouldn't start properly and use the envvars file I had set it to use. I needed to set the task to be command: apache2ctl start. Small things like that will catch you out, and cause a bit of frustration.

My main problem is entirely my own. I've used PhpStorm for so long that the editor simply not working in the way I've built my way of working around slows me down a lot. That's something which will only be resolved with time and with using it. I need to work out (or reconfigure) the shortcuts to be what I am used to, and learn other shortcuts to build my productivity. Simple things like being able to generate any getters and setters, or implement methods from interfaces or abstract classes are things I miss.

If you are just getting started with coding, or are already a VS Code user, this is absolutely something you should try. It will help people contribute to projects in a way which fosters consistency and reliability. Everyone has the same tooling regardless of their background. It lowers the barrier of entry to contributions, as people don't need a high-spec machine to be able to contribute due to the entire stack being within the browser window for them. Most importantly, new contributors don't need to spend hours setting up an environment to allow them to contribute. Just let Gitpod set the environment up, and they can start making changes.

I'll more than likely split between Gitpod and PhpStorm for my development going forward. I need to give it more of a chance than a few evenings of getting set up and starting a project. I imagine it will be a lot easier when a project has a little more maturity than just a README.md file in the repository.

Special Thanks

A big special thanks this week to Christin at GitPod for providing the generic screenshots and text to explain what Gitpod is.

Using Keyboard Shortcuts in GitLab

Gary Bell — Fri, 05 Feb 2021 08:50:54 +0000

Welcome to Tanuki Tuesday, where I look at the features offered by GitLab. This week I'm going to look at keyboard shortcuts, and how you can use them to speed up your personal process within GitLab.

There are a lot of places where you use keyboard shortcuts without even thinking about them. Ctrl+C for copy, Ctrl+V for paste, and Ctrl+S for saving are the ones most people will use. It's become ingrained in certain applications to use shortcuts to save the need to move from keyboard to mouse, select a menu, and then the select the option.

Learn keyboard shortcuts, and save time.

You can get a full list of shortcuts by pressing ? within GitLab, or from the ? icon and selecing Keyboard Shortcuts in the header. That will be the basis of most of this article.

Shortcuts for navigation

A lot of the shortcuts are used within specific projects. It allows navigation to various areas within a project using a g+(another key). The additional keys have been chosen for their ease of memory and to be intuitive; g+i to go to issues; g+f for files; g+m for merge requests.

I focus on those ones because they are the start of how I improved my productivity. It might seem trivial, but from entering gitlab.com and pressing enter in my address bar, I can get into my projects quickly, and work through the different sections of the projects I am working on.

By using the search function in the browser (Ctrl+f) to get to what I want on a given page, I can open a record and then use quick actions to perform a lot of the actions I do as part of my daily work.

Shortcuts in issues

Issues are where I most frequently use shortcuts. They allow me to get to the notes/comments section where I can provide additional information as needed, or ass the quick actions for setting labels and other meta informaiton as needed. When an issue loads, I can press r to go straight to the comments, add the content I need, and then use Ctrl+Enter to save the changes.

Other keyboard shortcuts

I don't currently use a lot of shortcuts within merge requests, other than the ones I also use in issues. Mainly for utilising quick actions to save me clicking round and searching for things in drop downs. Similarly, within jobs, epics and other areas, my use of keyboard shortcuts is limited.

Not everyone will use shortcuts everywhere. And for areas where you may not spend a lot of time, it might be counterproductive to learn and use keyboard shortcuts. Simply get the job done with the mouse, and get back to areas where you do spend your time.

Even in areas where you do spend a lot of time, you might not use all of the shortcuts. For me, within issues I know I can assign a milestone by pressing m, or change the assignee by pressing a. The chances are, however, I'm going to be performing multiple actions like that at the same time, so I work within the comments section. I focused on learning how to get there and using that area proficiently for my needs that I don't feel the need to use the individual shortcuts. You may not feel the need to learn them all, either.

Conclusion

Much like a lot of people were tricked into trying the Alt+F4 shortcut in school, you should only try using shortcuts when you won't be upset if you lose that section of work. When you do start with them it may be a little slower at first to get done what you need to. However, in time, you will be able to work more effectively when you don't need to more your hands away from the keyboard to reach for the mouse, move it, preform an action or two, and then move back to the keyboard.

Give some of the shortcuts a try, and see if you can improve your efficiency around GitLab. I'd love to know how you get on, so please let me know on Twitter.

Static Site Generators

Gary Bell — Mon, 01 Feb 2021 08:51:13 +0000

There is more and more focus on the performance of a website, and the effect performance has on search engine rankings.
Performance is the first metric loaded by Google's lighthouse audit.
The obvious reason why this is the case, is that Google wants to get the information to users as fast as possible.

The ultimate goal for any website is to get 4x100 ratings across the lighthouse audit, both on desktop and mobile.
Getting to that rating isn't always easy. Performance is the hardest to hit (in my opinion).

At the time of writing, the performance metric for my website homepage was sitting at 91/100.

On mobile, the story is different. It's a much lower at 75/100.

Where's the Bottleneck

The slow part of most sites is due to the CMS in the background.
A lot of the time taken for a page to load is the communication between the CMS code and the database.
In a lot of cases this requires requests across the network to communicate with the database.
The returned data then need to be processed to generate the page content, which can then be returned to the user.
Each of these steps takes time.

If you can remove some of those steps, then the speed of the site will naturally improve.
This is where a static site generator comes in.

These remove the requirement to perform some of the steps.
Specifically any of the database and processing work.
It does this by building the page once, and storing it as a html file on the webserver.
This means the visitor is served the information they requested directly, because the page which would be built from the CMS at each request is already generated in full.

There are a lot of options out there if you want to use a static site generator.
A list of 314 (probably not even comprehensive) is available on the jamstack website.
I'll be taking a look at a few of the PHP based ones in a future edition.
For now, I'll let you go and marvel in amazement at how many options there actually are for static site generation (and that doesn't count hand-crafting the HTML).

Merge Request Templates

Gary Bell — Fri, 29 Jan 2021 08:50:50 +0000

Welcome to Tanuki Tuesday, where I look at the features offered by GitLab.
This week I'm going to look at merge request templates, and how they can help guide users through providing the required information to get their changes merged into other branches.

I've previously covered issue templates. Merge request templates work in a very similar manner, but for selection during creating merge requests.
The best way (I've found) to use them, is to give contributors a checklist of things to cover as part of their submission. This can also be used by the reviewer or maintainer to ensure everything is present and correct ahead of accepting the change.

What Are Merge Request Templates

Like issue templates, merge request templates are pre-defined layouts for use when creating a merge request within GitLab.
If you have them set up in your project repository, then they are available during the merge request process for selection to use.

Creating Merge Request Templates

Merge request templates are written in markdown. They exist as .md files within your project repository.
Create a template in the .gitlab/merge_request_templates folder (you may need to create the folder first) and, once it is on your default branch, it will be available when creating new merge requests.

The templates use Gitlab Flavored Markdown, which is an extension of standard Markdown.

Comments are hidden from the preview and rendered displays, and are just use HTML comments e.g. .

A commonly used method of ensuring each merge request goes through the same process is to use checklists within the template.
Checkboxes can be created by starting a line with - [ ], followed by any text.
GitLab use this to great effect in their default merge request template, from which the snippet below was taken:

### Conformity

- [ ] [Changelog entry](https://docs.gitlab.com/ee/development/changelog.html) 
- [ ] [Documentation](https://docs.gitlab.com/ee/development/documentation/workflow.html) ([if required](https://docs.gitlab.com/ee/development/documentation/workflow.html#when-documentation-is-required))
- [ ] [Code review guidelines](https://docs.gitlab.com/ee/development/code_review.html)
- [ ] [Merge request performance guidelines](https://docs.gitlab.com/ee/development/merge_request_performance_guidelines.html)
- [ ] [Style guides](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/doc/development/contributing/style_guides.md)
- [ ] [Database guides](https://docs.gitlab.com/ee/development/README.html#database-guides)
- [ ] [Separation of EE specific content](https://docs.gitlab.com/ee/development/ee_features.html#separation-of-ee-code)

This results in the following output when the markdown has been saved (except the strike-throughs - this image was taken from an in-progress merge request):

Why Use Merge Request Templates?

Giving users the guidance to ensure everything is in order ahead of a review should increase the likelihood the change is merged sooner.

Merge request templates are another area where you can use scoped labels to help improve the efficiency of your workflow.
Creating a merge request relating to Security? Use /assign ... to assign it to someone in the security team to review (see my quick actions post for more details on this).
Doing this on a template means even new starters can have their work reviewed by the right person rather than involving their team lead just to change the assignee.
Having different merge requests for different types of requests can reduce the amount of training needed to get someone new to their most productive when contributing to the project.

Conclusion

Merge requests are stressful for both the submitter and the reviewer.
There's so much to remember, and so much depending on a successful outcome.
Using merge request templates can help reduce that stress on both side, especially by using checklists.
Add the absolute requirements for a submission, and everyone has their expectations set.
If there's some items not ticked off, it's likely not ready to merge.
When a reviewer is looking at the request, they can work through the list and ensure everything has been done.

An added bonus is that if the process changes, such as a new task being added, then the template can be updated.
Everyone who is submitting following the process change can follow it using the new list.
There's full transparency of the process for merge requests, and people won't feel cheated for missing steps which have not been documented.

Reduce the cognitive load on everyone in the process, and increase the chances of a successful merge.
What more could you want?
Merge request templates facilitate that.

Are mobile workstations dead?

Gary Bell — Mon, 25 Jan 2021 08:50:45 +0000

I need to open by saying that this is not a guarantee of the actual demise of a product, rather my view on why it is obsolete. I have a feeling that the mobile workstation will be around for a while longer, but likely with a few small changes.

What is a Mobile Workstation?

In a nutshell, it's a "laptop" which is packed with the power of an entire data centre, all in the compact weight of a elephent. Serously, they are powerful machines, but weigh a lot (mine is over 3.2Kg). They look rugged, but aren't exactly practical for carrying around. They look like the user has a clue what they are doing. Why else would they be lugging round a behomoth like that?

Who uses them?

I have one with work. It is robust, and has roughly enough resource to run what I need to most days. It's always worrying to say "most days", especially when it already has 32GB RAM. Something I regularly use 98+% of. I requested something with this level of power as I knew I needed to support a produciton system whilst on the go, and need to run the database locally. Something which uses around 20GB RAM when it's running.

It doesn't run often. I'm working on a new project which has a lot of different components. In the production environment these run on different servers, so I run them all on different virtual machines. I've written about the reasons for using virtual machines in development previously. Those virtual machines take a lot of resource to run. There's more efficient ways of doing so, and many reasons to avoid using virtual machines in development. Regardless of how it's set up, it was needed for the power.

I use a workstations because I have never used a Mac. When I started my current role, I knew I needed something with a lot of power. A lot of jobs I was interviewing for were giving new developers Macbooks. They can come with some serious resource in a fairly pleasing case. All the power, some good looks, and not a lot of weight. Factor in Apple's reputation for build quality, and the cost of them doesn't seem too bad. When you compare the cost of a Macbook against a Dell, it's not actually a crazy proposition.

Why are Mobile Workstations dead?

Quite simply, there's no need for them. They ar expensive pieces of equipment because they pack PC power into a laptop shell. Some of them are closer to server power than PCs. The problem is, there's better options. A Macbook Pro can be specified with an intel i9 processor and 64GB RAM - it's expensive (from £3799), but possible. A Lenovo X1 can be had with an intel i7 which can boos to over 5GHz, and have 64GB RAM also. Both of these are far lighter than a traditional mobile workstations, and can do everything a mobile workstations would be needed for. All for the cost of some mobile workstations, and they will have better battery life.

The Future of Mobile Workstations

I can no longer see the need to buy new mobile workstations. Everything can be put together in a much neater package, and one which isn't intrinsically ugly and heavy. I wouldn't buy one myself anyway, and I certainly won't be looking to add any more to my IT inventory. Future developers will have something much nicer to work with.

That being said, there's a good chance that they will shift to allow memory sizes of 128GB or more RAM to be added to them. They will become mobile data centres for folks who need to be able to access a lot of the data production may have, but where they aren't going to have the connectivity to get that volume of data from the cloud. If a lot of memory is needed, and needed on the go, then this may be the only option. Stuff an i7 or i9 into one of these bodies, and load it with 128GB RAM. That can be the only direction these devices go.

Whether or not mobile workstations do die out as a concept is largely irrelevant. I simply can't see a reason to have them. The health and safety (yes, really!) aspect of their existence is serious. They are heavy, and shouldn't be carried over any relatively large distance. There's far better options which are far safer. If you are considering getting one, give serious consideration to something much more slimline. Your back will thank you, and you'll look like someone from the 21st Century, rather than from the 1980s.

Quick Actions in GitLab

Gary Bell — Fri, 22 Jan 2021 08:51:05 +0000

Quick Actions

Welcome to Tanuki Tuesday, where I look at the features offered by GitLab.
This week I am looking at quick actions, and how they can increase your productivity. Get more done in less time by not leaving the issue description or comment box.

I am focusing this article specifically on actions within issues. There are some quick actions which can be used in Merge Requests or within Epics

What Are Quick Actions?

Quick actions replace the need to stop what you are doing in the markdown editors to click on elements of an issue, by letting you perform the actions within the editor.

Things like assigning issues to people, adding labels, setting the issue weights, milestones, and epics can all be done through quick actions.
Some of those are only relevant at specific subscription levels. But if the feature is available for your project then, once you get used to them, I'm sure you'll love them.

Quick actions have been built, it seems, with Newton's third law of motion - "For every action, there is an equal and opposite re-action".
Basically, if you can add something to an issue via a quick action, you can also remove it.

Uses of Quick Actions

When adding some meta information to an issue, such as a label, you normally do this by clicking on a drop-down select box, search for the label you want, and click it.
To remove a label, it's the same process. Search (using the same drop down), and click to remove it.
If you are adding, removing, or changing a lot of labels, this can be time intensive.

Labels

Labels are where I use quick actions the most. I rarely use the drop-down to select a label.
Prior to the image above, I don't recall the last time I used it. I've completely trained myself to do it via quick actions.

Adding a label to an issue using quick actions is as simple as starting a line in the editor window with /label once that's in place, you can search for labels by adding ~.

When the list of labels to select is available, you can use the up/down arrows to select, and enter to auto-complete.
If there are spaces in the label name, the label will have quotations added automatically.
You don't need a new line starting /label for each label you wish to add. Just add them all on the same line.

If you are using scoped labels as part of your workflow, then these are available as you would expect.
They will remove the previous label of the same scope (if applicable) and replace it with the one from the comment/issue edit box.
If you don't have scoped labels as part of your subscription but still need to remove label(s) from an issue, you can use /remove_label in the same way as /label.
/unlabel is an alternative to /remove_label and does the same thing so fewer characters are needed, if you want to save time.
That, and not everyone is used to typing underscores.

Milestones and Epics

Rather than finding the right milestone or epic to create the issue from, quick actions are available to add and remove those.
By starting a line in the description with /epic &, you can add the issue to an epic as soon as it's saved.
Similarly, a line starting /milestone % will let you search and use auto-complete for the milestones.

Closing issues

More often than not, this will be done from the comment part of an issue. Why? because you aren't going to create and close an issue at the same time, probably!
Chances are, you'll add a comment as to why the issue was closed, so there's a history of the decision being made.
Yes there's a "Comment & close issue" button right below the comment button, but that requires the use of Tab or a mouse to get there.
Some people (and I am one of them) will use keyboard shortcuts (more about those another time) to submit the comment (Ctrl+Return if you are interested).

Once you are in the comment box, you add your closure reason, add a new line, type /close, then submit. Done, issue closed. No need to leave the comfort of the keyboard.

Issue and Merge Templates

I've previously covered issue templates and the benefits they bring.
Even better is when they are combined with quick actions.
Adding quick actions to the templates allows the meta data about an issue be set correctly from the start.

When you've got a workflow which requires issues to be categorised in such a way which is known to mean it needs attention, then getting it right early is important.
My workflow for bugs being raised, for example, is for it to have scoped labels for Issue Type::Bug, Bug::New, Priority::TBC, and Severity::TBC.
These have colouring such that I can quickly see them on the issues list, but they also appear in custom issue boards.
Asking someone to remember to add those every time is going to result in errors and things being missed.
Adding them to the template means they don't need to remember; they simply submit the issue and it's added for them.
The template contains the following line, and they are added when the issue is created.

/label ~"Issue Type::Bug" ~"Bug::New" ~"Priority::TBC" ~"Severity::TBC"

Different issue templates may relate to specific areas of the system. It doesn't matter if it's front-end and back-end, or as granular as modules in a system e.g. Products Bug.
Those issues might be better placed to be triaged by a specific person or team. This is where /assign might be included in a template.
Sure, you might be able to remember who looks after a specific team or set of issues, but what if they leave, or swap teams, or someone else is triaging those issues?
You might not be aware of that change, and things might be left to one side until someone picks up those issues.
Setting the /assign in a templates allows for the direction of issues to be kept up-to-date quickly and easily.
Change the template in the default branch, and it's done. New issues are assigned to the new person.

Summary

There's a lot more which can be done with quick actions, and the full list of them is available within GitLab's quick action documentation.
Some of them can only be used within certain contexts, e.g /wip can only be used within a merge request, but some are useful in issues, merge requests and epics.

I don't believe the are a great learning curve, but what they bring is, for me at least, a lot of time saved from clicking all over the screen.
There's no switching back-and-forth between keyboard and mouse to select things and add the meta information to a record.
Even more time is saved when these issues are included within issue templates.
There's no need to remember who needs to be assigned to triage an issue, or what labels need to be given by default to issues.
Reduced cognitive load; reduced stress.

Next time you're working within GitLab and need to add some meta information, give quick actions a try.

Updating CI pipelines to allow PHP8

Gary Bell — Mon, 18 Jan 2021 08:56:25 +0000

With the release of PHP8, there's going to be a scramble from people to get their PHP applications up-to-date. Yes, PHP 7.4 is supported until 28th November 2021, but there could still be a lot of work to do. Especially if your application uses external libraries. This puts you at the mercy of the maintainers.

I maintain one of those packages on which you may rely, an entropy based password validator. Knowing that PHP 8 was going to be released made me want to get ahead of the curve on migrating to be able to use it. To do that, and have some level of proof that it would be ok, I needed to update the CI pipeline to also run the unit tests under PHP 8. This will be the starting point for a lot of teams with good code coverage, I imagine. Here's how I found the experience (with the issues I ran into). First, it was a case or copying and renaming the existing PHP Unit test suite, which resulted in:

PHP 8.0 Tests:
  image: ubuntu:focal
  stage: unitTest
  # Install composer dependencies
  before_script:
    - DEBIAN_FRONTEND=noninteractive apt-get update
    - DEBIAN_FRONTEND=noninteractive apt-get -y install curl php php-xdebug php-curl php-dom php-json php-mbstring php-pdo zip unzip php-zip
    - curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
  script:
    - composer install
    - ./vendor/bin/phpunit --coverage-text --colors=never --configuration phpunit.xml --log-junit phpunit_results.xml

That's not much use, as it still runs things on PHP 7.4 (the default with Ubuntu 20.04). It needs PHP to be updated, so I added the PPA to allow this. This needed the following line added to the start of the before_script section:

- DEBIAN_FRONTEND=noninteractive apt-get update
- DEBIAN_FRONTEND=noninteractive apt install -y software-properties-common
- DEBIAN_FRONTEND=noninteractive add-apt-repository ppa:ondrej/php

The I changed the php elements to be php8.0, again in the before script:

- DEBIAN_FRONTEND=noninteractive apt-get -y install curl php8.0 php8.0-xdebug php8.0-curl php8.0-dom php8.0-json php8.0-mbstring php8.0-pdo zip unzip php8.0-zip

Done - queue excitement for the run...FAIL. The pipeline console showed the following error:

E: Package 'php8.0-json' has no installation candidate

What the...?
It turns out that JSON is included within PHP 8 by default, which saves issues on forgetting to install it. With it not being needed, I removed the php8.0-json part, so the unit test full job was:

PHP 8.0 Tests:
  image: ubuntu:focal
  stage: unitTest
  before_script:
    - DEBIAN_FRONTEND=noninteractive apt-get update
    - DEBIAN_FRONTEND=noninteractive apt install -y software-properties-common
    - DEBIAN_FRONTEND=noninteractive add-apt-repository ppa:ondrej/php
    - DEBIAN_FRONTEND=noninteractive apt-get update
    - DEBIAN_FRONTEND=noninteractive apt-get -y install curl php8.0 php8.0-xdebug php8.0-curl php8.0-dom php8.0-mbstring php8.0-pdo zip unzip php8.0-zip
    - curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
  script:
    - composer install
    - ./vendor/bin/phpunit --coverage-text --colors=never --configuration phpunit.xml --log-junit phpunit_results.xml

All done, all good to run...Fail.

Your requirements could not be resolved to an installable set of packages.
  Problem 1
    - Root composer.json requires php ^7.4 but your php version (8.0.0RC3) does not satisfy that requirement.

Yes, I forgot to update the required PHP version in composer.json. It was then changed from

"require": {
  "php": "^7.4"
}

"require": {
  "php": "^7.4|^8.0"
}

Re-run the pipeline. Success!

Conclusion

For a small component like my password validator, this was a trivial exercise. It's a handful of files, and doesn't have much in the way of complexity. The issues I had were due to me rushing for a success (forgetting to update the PHP requirement) or simply not knowing that JSON was included by default now. The actual updating of the pipeline was pretty straight forward. It's an exercise certianly worth undertaking on a development branch (even if it goes nowhere for a while) to see if there's any impending compatibility issues for your application. If there are, you can be aware of them early, and start working to mitigte or resolve them to keep on a supported version of PHP.

GitLab Scoped Labels

Gary Bell — Fri, 15 Jan 2021 09:46:55 +0000

What are they, and why use them?

Welcome to Tanuki Tuesday, where I look at the features offered by GitLab. This week I'm going to look at scoped labels, and how they can help you streamline your workflow and minimise confusion. Please be aware, this feature is only available on Silver/Premium subscriptions or higher ($19 per user per month).

I have to start by saying I absolutely love scoped labels.
They were the primary driving force for me pushing to upgrade my company's subscription from Bronze to Silver. I use them every day, and they save me a lot of time.

What are scoped labels?

Scoped labels are a way of categorising labels, so that only one of that category can be used at any given time. This lets you build workflow around the labels, and prevent things being double-labelled in a way which leads to confusion.

By using scoped labels, it would not be possible for something to be categorised Priority::Low and Priority::High at the same time. That is important as, seeing an issue allocated both high and low priority is going to be confusing. It is going to require someone to spend time looking at the issue, understanding the information and context, and then determining which of the two it would be.

It is important to note that labelling an issue Priority::Low does not stop you then giving it the label Priority::High, but when you do so the Priority::Low label will be automatically removed.

Configuring Scoped Labels

As shown above, the scope of a label is separated by a double-colon ::. Everything up to the final :: is part of the same scope. Priority::Low is within the scope of Priority, and an issue or merge request can only have one Priority. Things get slightly more complicated when adding multiple levels i.e. more than one set of :: present.

Assume you had issues which needed work from multiple teams e.g. Frontend, Backend, Infrastructure, Security. To visualise where the issue sat with each team you might then have statuses todo, in progress, review, complete. An issue could then labels Team::Backend::review, Team::Infrastructure::in progress, and Team::Security::todo all at the same time. It would not be possible to allocate labels Team::Backend::review and Team::Backend::complete, as the scope is the same.

When combined with different colours for the label, it becomes easy to determine a lot of information about an issue without having to read and digest each and every label. I always aim to colour labels of the same scope in shades of the same colour, which helps me visualise where in a given scope it sits.

Use cases for scoped labels

There's likely a lot of creative ways to use scoped labels, and each will likely depend on the workflow of an individual, business, or project. Here are some useful ways they could be quickly implemented, based on the way I work:

Issue Priorities

I gave issue priority as an example when explaining what scoped labels were. To reduce cognitive load when looking at a list of issues, I find it useful to split priorities into sub-scopes:

Priority::Bug
Priority::Feature

Both of these get the following 4 labels:

TBC - this is always grey. It shows that it needs reviewing and categorising before they can be worked on.
Low
Medium
High

This introduces a risk of something being labelled as a high priority bug and a low priority feature. I find that to be a better alternative than a whole board turning red (bug priority colour scheme) when there's a mix of features and bugs with high priority using the same label. The issues this may cause are mitigated by...

Issue Type

Issues can be split into different types. I tend to use:

Bug
New Feature
Change Request

By setting these types against the scope Issue Type:: they can only be allocated a single one of these, which helps clear any ambiguity arising from double-labelling around issue priority.

Status

I use status to let items become a critical part of workflow. I can see what my team is working on, and what has been completed because of the labels. To prevent something being To Do, In Progress, and For Review at the same time, these get scoped as Status::.

I also use an additional level of status here for testing. This is sub-scoped as Status::Testing:: with labels in that scope being:

To Test
In Progress
Passed
Failed

I use a status of To Spec (again, always grey in colour) to let me visually see it needs attention from myself before it enters the main work stream.

Bug Status

Separate from the status elements above, I use scoped labels to help triage bugs or issues raised by users. These break down into:

New - this is the grey status here. It's not been reviewed or triaged, so needs attention
Accepted
Insufficient Detail - this is also used when I or another developer cannot replicate the issue
Rejected

It's not possible to have a bug accepted into the work stream when it also has insufficient detail and/or cannot be replicated. Once a bug has been accepted, it will be given the label Status::To Spec so it can enter a different workflow for progression.

Conclusion

Scoped labels are a simple feature, but incredibly powerful when used to manage the flow of work through the pipeline. They can provide a useful visual clue as to what is being done, or what needs to be done, on an issue by simple colouring. Huge time savings can be made using scoped labels due to way scopes override any matching scope already on the issue. It doesn't take a lot of time to search for a label and click to remove it (less so with the click to delete feature), but those few seconds rapidly add up if you've got to add and remove several per issue, over a lot of issues.