DEV Community: Mark Hesketh

Introducing: Write Good, an Obsidian plugin

Mark Hesketh — Mon, 10 Mar 2025 09:40:00 +0000

Last week, I built 'Write Good', an Obsidian plugin to help improve writing style, built on top of a package of the same name, Write Good by Brian Ford.

This week, it got approved by the Obsidian team and is now listed as a community plugin. You can also install it from within Obsidian itself.

It highlights issues and suggests improvements as you type, such as:

Passive voice
Complex phrases
weasel' words
etc

I built it for myself as while a VS Code extension already exists, I use Obsidian for my note-taking and wanted to port these features across.

From a technical standpoint, I built it using TypeScript while leaning heavily on GitHub Copilot's new agent mode to figure out the gritty details of piecing together an Obsidian plugin.

You can install it today by searching for 'Write Good' within Obsidian's community plugins or via Obsidian's plugin website. Its also open source, of course.

Git tips and tricks I use every day

Mark Hesketh — Sun, 09 Mar 2025 12:09:00 +0000

I am by no means an expert, but I've been using Git for years at this point. Over that time I've picked up some tips, tricks and habits I use daily that I think could help you too.

1. Switching back to the previous branch

I swap between main/master, my feature branch and back to main/master constantly. Rather than typing out the name of branch you want to switch to, Git provides a nice alias to switch back to your previous branch:

git switch -

This might look familiar as it mirrors cd - which navigates to your previous directory in the terminal in the same way.

I use this all the time to ping pong between main/master and whatever feature branch I'm working on. For example:

$ git branch
* main

$ git checkout -b feature-branch
Switched to branch 'feature-branch'

$ git switch -
Switched to branch 'main'

$ git switch -
Switched to branch 'feature-branch'

$ git switch -
Switched to branch 'main'

2. Pushing to a remote branch of the same name

When working on a feature branch you'll often need to push your changes to a new remote branch before creating a PR. Typically, the remote branch has the same name as your local.

Its tedious having to copy/paste (or god forbid type out) your branch name. What if there was a better way?

$ git push origin HEAD

It pushes and creates a branch on the remote using the same name as your local branch. It doesn't matter how long or tedious your branch name is. Using the HEAD alias will pick it up from your local branch, like so:

$ git checkout -b feature-branch
Switched to a new branch 'feature-branch'

$ git push origin HEAD
...
To github.com:company-name/project-name.git
 * [new branch]      HEAD -> feature-branch

I find this useful as at work we have conventions for branch names. They're often long and include ticket numbers, for example feature/123456/great-new-feature-that-will-triple-revenue.

By using HEAD I never have to care about the branch name. It works every time. In fact, I use an alias of git poh on all my feature branches when pushing.

Speaking of aliases...

3. Git aliases

Git allows you to specify aliases to effectively create your own Git commands.

You probably have some shell aliases set up already, you might even have some aliases specific to Git. I prefer to use git aliases rather than shell aliases as they're scoped to Git and feel like real Git commands.

To create one open up ~/.gitconfig and add your commands under the [alias] section like so:

...
[alias]
    deploy = push production master
...

This will create a new command git deploy which is as if you wrote git push production master.

I have a bunch of these and I've published my .gitconfig to as a gist if you're looking for some inspiration. Some of my favourites are:

# Cleans your working copy, resetting everything to the previous commit creating a blank slate. Stolen from Jeffrey Way 
nah = "!f() { git clean -d -f; git reset --hard; }; f"

# git status, but shorter
st = status -s

# Removes the last commit, but keeps the changes so you can make any changes or deletions
undo = reset HEAD~1 --mixed

# Unstages any changes
unstage = restore --staged

4. Open the current project in GitHub

A couple of shell aliases (not git aliases) I like are:

gh
ghu

These open up the current directory's project in GitHub in the browser.

gh opens the origin remote and ghu opens the upstream remote, depending on whether I'm working on a fork or not.

I find these useful when I'm working on a project and want to take a look at the GitHub issues or PRs.

If you'd like to use them too, open up your shell's config or alias file (~/.zshrc/~/.bashrc/etc) and add the following:


function gh() {
    local repo_url=`git remote get-url origin | sed -e 's/git@//' -e 's/.git//' -e 's/:/\//'`
    open "https://$repo_url"
}

function ghu() {
    local repo_url=`git remote get-url upstream | sed -e 's/git@//' -e 's/.git//' -e 's/:/\//'`
    open "https://$repo_url"
}

Introducing: rustywind-ruby

Mark Hesketh — Mon, 03 Feb 2025 23:02:00 +0000

I'm thrilled to share my first published Ruby gem: rustywind-ruby.

Its a wrapper for RustyWind, a rust-based CLI utility for sorting Tailwind CSS classes. This makes it easier to use in Ruby and Rails #nobuild projects.

Why I built it

I've been using Tailwind CSS for a while and RustyWind keeps my utility classes predictable.

Unfortunately, RustyWind is not available through RubyGems or bundler. Tailwind CSS itself recommends Prettier, an npm package, to sort CSS classes. Since I've been embracing importmaps and #nobuild recently this was a problem.

As RustyWind is a small standalone binary, I used the bin/setup script to import it. This worked, but it didn't feel great having a dependency outside of my Gemfile.

I decided to follow the lead of the tailwind-ruby project, building a small wrapper around the RustyWind binaries. This allows bundler and your Gemfile to manage it like any other dependency.

It was also the perfect scope for my first gem.

How to use it

via bundler:

bundle add rustywind-ruby

or without:

gem install rustywind-ruby

Then use RustyWind via bundler exec

bundle exec rustywind

Personally, I run RustyWind as part of a bin/check script alongside other actions such as tests, linters, and audits.

Future plans

A future update will be to have GitHub Actions sync with the RustyWind upstream repo to keep versions up to date automatically.

For now though, it works as expected.

If it doesn't for you, let me know in the GitHub Issues.

Switching between multiple PHP versions on macOS

Mark Hesketh — Mon, 10 Feb 2020 16:04:21 +0000

I often need to switch between multiple PHP versions on my macOS environment when working on legacy projects.

As usual, I had forgot how to do this, so I’ve decided to publish the steps for my own and other’s reference.

The instructions below are for use with macOS 10.15 Catalina, and allow installation of PHP 5.6, 7.0, 7.1, 7.2, 7.3 & 7.4.

Using multiple versions of PHP on macOS via homebrew

1. Prerequisites

You’ll need both Xcode Command Line Tools and Homebrew installed.

1.1 Install XCode Command Line Tools

xcode-select --install

1.2 Install Homebrew

Homebrew is a package manager for macOS. It is similar to apt on Ubuntu.

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Check that brew has been installed correctly:

$ brew --version
Homebrew 2.2.5

You can also run brew doctor to check everything is good to go.

2. Install Multiple Versions of PHP

As of writing, only PHP 7.2, 7.3 and 7.4 are actively maintained and officially supported by Homebrew.

To install PHP 5.6, 7.0 & 7.1 we’ll need to ‘tap’ an additional repository:

brew tap exolnet/homebrew-deprecated

Now, we can install all the available PHP versions:

brew install php@5.6
brew install php@7.0
brew install php@7.1
brew install php@7.2
brew install php@7.3
brew install php@7.4

This may take a little time to install. Go make yourself a brew!

3. Switching between PHP versions

Once installed, you can switch between PHP versions by ‘linking’ and ‘unlinking’ in brew:

# Switch from 7.4 to 5.6
brew unlink php@7.4
brew link php@5.6 --force

Switching from PHP 7.4 to 5.6

You can combine brew unlink and brew link to swap between any installed version.

Open Source Alternatives

There are a few open source projects that aim to automate this for you, if you prefer:

Source

Embrace Bin Scripts

Mark Hesketh — Tue, 04 Feb 2020 12:42:09 +0000

I recently watched Matt Stauffer’s talk “Patterns That Pay Off” from Laracon 2018. It’s packed with great advice that I’ve been bringing into my own projects.

One piece of advice I’d like to highlight is the use of project-based bin scripts.

Whats the problem?

Have you ever had a project that hasn’t seen active development in years but now needs a small update.

“Where do I get Bower from these days?”
“What is a PEAR package?”
“How do I deploy to Rackspace?”

That quick CSS fix has become a much bigger headache.

Or, a typical PHP Laravel project a local setup might involve these steps:

Switch to PHP 7.4
Install PHP dependencies via Composer
Switch to Node v12.7
Install frontend dependencies via NPM
Start local PHP web server
Start webpack build system
Start a MySQL service
Copy .env variables
Run database migrations and seeders

Thats a lot of steps to remember or fit into your readme, and thats assuming the developer reads the readme at all!

Whats the solution?

What if all your projects had these steps encapsulated in a single bin/install.sh script.

Running the install script on a new project

This script could perform the installation steps and check for project requirements. It could also handle the nuances between macOS, Linux or Windows dev environments.

It doesn’t matter if you are working on a PHP, Node or static web app – you cd into the project and run ./bin/install.sh.

Once you’re ready to commit, run ./bin/precommit.sh to run your tests, static analysis, and formatting.

Finally, run ./bin/deploy.sh to build production assets, update release notes and deploy. How you deploy that particular project doesn’t matter. Docker? Digital Ocean? Heroku? Who cares!

What are the alternatives? Docker? Composer?

You might be thinking “this is the sort of thing Docker and CI solves!” or “can I not just use composer/npm scripts?”.

Docker can standardise your build steps – but not every project needs Docker. I have several projects where Docker would be overkill. For example, sites built using static site generators.

A Docker-based app can still make use of bin scripts. If only to wrap docker-compose up in the familiar bin/run.sh script.

Similarly, a PHP project may not even use Composer – such as a typical WordPress website.

By embracing bin scripts, it doesn’t matter what an individual project’s tech stack is. The interface to install, run and deploy is the same across all your projects.

Most importantly, shell scripts will run out of the box on macOS, Linux and Windows in almost all cases.

Show me the code!

I have a bin directory in my project root which contains my bin scripts. It looks something like this:

$ tree bin
bin
├── install
├── run
└── precommit

Each script is self-contained and includes everything it needs to run. Because of this, they’ll can work in many years from the first git clone.

For example, one of my PHP Laravel apps has the following bin/install.sh:

#!/usr/bin/env bash

# bin/install
# Install the application

command_exists() {
    command -v "$@" > /dev/null 2>&1
}

if ! command_exists fnm; then
    echo "fnm is not installed"
    echo "Visit https://github.com/Schniz/fnm to install"
    exit
fi

if ! command_exists composer; then
    echo "fnm is not installed"
    echo "Visit https://getcomposer.org/download/ to install"
    exit
fi

if ! command_exists yarn; then
    echo "fnm is not installed"
    echo "Visit https://yarnpkg.com/lang/en/docs/install/ to install"
    exit
fi

echo "Removing existing ./node_modules folder"
rm -rf ./node_modules
echo "Removing existing ./vendor folder"
rm -rf ./vendor

fnm use
composer install
yarn install

cp .env.example .env
php artisan key:generate
php artisan migrate:fresh --seed

The bin/run.sh script as as follows:

#!/usr/bin/env bash

# bin/run
# Run the local development environment

if [["$OSTYPE" == "linux"*]]; then
    sudo service mysql start
fi

php -S 0.0.0.0:8000 -t public/ & yarn run watch

and finally, this is the bin/precommit.sh:

#!/usr/bin/env bash

# bin/precommit
# Tasks to run pre-comment

php ./vendor/bin/phpunit

The scripts do not need overcomplicating, and can simply be a list of commands. The bin/precommit.sh script only runs my test suite and nothing more.

Crucially, it holds up across all my projects spanning years the tech stacks of their time.

Laravel? WordPress? Static? No problem.

Nice!

Creating your own

I can offer some final words of encouragement, if you’re interested in creating your own.

Start small. Don’t worry about adding support for Windows environments if you only ever use macOS. Add as you need.
Not everything needs scripting. A printed message to direct the user could be enough.
Keep it simple. There’s a temptation to create abstractions from your scripts. Resist adding complexity, duplication is not always a bad thing.
Create aliases. I’m a big fan of aliases and saving a keystroke. Once you’ve settled on your script names, you can alias them for even more convenience.

Source

2020: Plans & Goals

Mark Hesketh — Mon, 06 Jan 2020 19:48:44 +0000

Last week I wrote a retrospective on how I felt 2019 went. Today, the Christmas tree came down, the country went back at work and I’m looking ahead to my plans for 2020.

Writing

One of my main takeaways from 2019 was that I simply didn’t write enough even though I’d planned to.

Over the past 5 years I’ve got into an infinite loop with my blog, which goes something like this:

Decide I want to start blogging again
Make a Trello board
Scribble down some topic ideas
Redesign and redeploy blog onto a new platform, infrastructure etc
Become dissatisfied before writing a single post and move onto something else
Repeat 18 months later

I’m taking a pragmatic approach and sticking with WordPress, the theme, the hosting – the lot, and writing some bloody posts.

The plan: Write more, build more, share more. 2017 gonna be a good 'un

— Mark Hesketh (@markahesketh) January 2, 2017

I’ve got some big projects planned for 2020, and I want to share everything I learn, both here and on Twitter. I may also cross-post to communities such as dev.to.

If you want to keep up with my writing on Modern PHP, Laravel, Testing, Developer soft-skills and how I use it all to build web apps in 2020 then subscribe to the RSS feed.

Projects

As mentioned, I’ve got a few personal projects lined up for this year, alongside my day job.

Laravel E-commerce Applications

I’ve embarked on an overly ambitious journey to build a couple of e-commerce applications.

Rather than picking up an off-the-shelf e-commerce platform, I’ll be building them from scratch using Laravel. This has drawn some chuckles and skepticism from some of my colleagues, but I am undeterred! I have quite a few reasons for this which I’ll attempt to justify in a series of posts.

The e-commerce stores are for my girlfriend’s business, selling hand-made jewellery.

I built the original store in 2011 using PrestaShop, a PHP-based e-commerce platform, followed by a 2015 redesign. Now its time for refresh and at least one additional store, armed with everything we’ve learnt since.

This is a nights and weekends project, and for now is built for purpose to minimise the scope – but there’s definitely potential to extract some open-source packages along the way. As mentioned, I will also write about its progress, decisions made and lessons learnt.

Proudly Powered

I registered proudlypowered.com in 2012 while freelancing and primarily building on WordPress.

The name is a reference to “Proudly powered by WordPress” seen in the footers of WordPress-based websites, and I’ve always liked it. However, I moved away from WordPress soon after registering the domain and never did much with it.

I’m not planning a return to WordPress professionally but I am actively using it for this website. In doing so, I expect to open-source any custom themes, plugins and tools that I build under the Proudly Powered name.

In addition to my own work, it may also recommend plugins, themes and techniques by other developers that are of high quality should be highlighted.

Are there any recommended WordPress resources that aren't thinly veiled affiliate link aggregators?

— Mark Hesketh (@markahesketh) December 22, 2019

May be harsh, but my initial search was fruitless.

It could be a single page website, it may be more. I haven’t decided. Regardless, I’d like it to be a legitimate reference for developers who take pride in their work, have an eye for quality and choose to build on WordPress.

Guitar

I’d like to adopt more hobbies outside of programming and computers, revisiting some of the things I enjoyed before getting deep into web development.

I played guitar through my teens, barely above beginner level, but I really enjoyed playing along to bands in my bedroom. Much to my brother’s discomfort.

Before Christmas I dusted off my Epiphone Les Paul that I bought in 2004 with money saved working in a local pub kitchen, and set myself a challenge to learn a full album.

Not a single song, riff or solo, as I’m prone to do – but the full album.

“Coming out of my cage and I’ve been doing just fine”

The album I’ve picked is Killers – Hot Fuss, for a few reasons:

I like every song on the album
It seems achievable at my skill level, with a few tricky ones thrown in to make it a challenge
It gives me an excuse to learn the anthem of my generation

And the rest

Complete ‘Dry January’. Christmas was heavily indulged
Make 2020 the year we buy our first home
Attend at least one PHP / Laravel conference or local meetup
Record a screencast
Watch Burnley FC maintain their Premier League status

Here’s to a great 2020!

Your README Is Important

Mark Hesketh — Wed, 20 Sep 2017 20:57:08 +0000

Good documentation is very important and expected of open-source projects.

We should hold our private projects to the same standard. The README is not a @todo. It should be available and up to date, even if only for our own benefit.

But why?

It might sound like a waste of time to document something you’ve made for yourself but you’d be mistaken.

The faintest ink is more powerful than the strongest memory.

I’ve lost count of the number of times I’ve picked up an old client’s project and been thankful I’d included a README.md. I’d taken the 5 minutes to document the setup steps, and can now onboard myself even several years later. Instead of trying to remember my workflow of years gone by, the instructions are right there.

What seems obvious now, may not be later.

Practice makes perfect

Writing concise documentation is a worthwhile skill and you should practice whenever possible. Using the documentation on your personal projects is the perfect opportunity.

This practice will benefit you and others when documenting public or team projects.

Good documentation can be the difference between a project succeeding or not. Personally, I’ll skip any project that does not have clear and concise documentation.

Hone your documentation skills and give personal projects their best chance to succeed.

Where to start?

Dig into your projects folder, find a project that is missing a README.md and get to work. Your future-self will thank you.

For tips on writing your README, refer to Eric Barnes’ great article on how to write a README that rocks.