Blog

  • It’s a (Bash) Trap!

    It’s a (Bash) Trap!

    Let me tell you about a little command in Bash that’s saved my backside more times than Git stash has saved half-finished Friday night code commits: it’s called trap. Sounds like something Indiana Jones might fall into, and honestly, it behaves a bit like that too. Except instead of spikes and dramatic theme music, it just helps your shell scripts not explode in a pile of silent errors and broken dreams.

    So what is trap, exactly?

    In simple terms: trap lets you catch signals (like CTRL+C, aka SIGINT) or errors (like when you forget to check if a directory exists before deleting it… not that I’ve ever done that), and respond to them with grace. Or at least mild dignity.

    Imagine you’re running a script that backs up files, renames a few things, syncs to Dropbox, sacrifices a goat to the cloud gods, and deletes some temp stuff. Then your cat walks across your keyboard mid-script and hits CTRL+C. Without trap, your script bails halfway through, leaving you with half a goat, no backup, and a strong desire to rethink your life choices.

    With trap, you can catch that interruption and say, “Oi! Clean up first!” before exiting.

    Example time

    #!/bin/bash

    cleanup() {
    echo "Tidying up... don't mind me."
    rm -f /tmp/my_temp_file
    }

    trap cleanup EXIT

    touch /tmp/my_temp_file
    echo "Doing important things..."
    sleep 10

    This lil’ script touches a temp file, then chills out for 10 seconds. If you interrupt it with CTRL+C, or it finishes naturally, it runs the cleanup function before exiting.

    This is like finally learning to leave the pub with your coat, wallet, and dignity intact. Rare, but possible.


    But I Use Laravel, Not Shell Scripts?

    Same, mate. But here’s the thing — you probably run shell scripts more than you think:

    • You’re deploying with Envoyer? There’s a Bash script hiding in there.
    • Running artisan queue:work as a daemon?
    • Doing artisan migrate --force in CI/CD?
    • Building a custom Laravel Forge deploy script?
    • Using Bash to run scheduled Laravel commands in Docker or Cron?

    All Bash. All potential chaos. All candidates for a cheeky trap.

    Picture this:

    You’ve got a deploy.sh script. It pulls the latest code, runs migrations, clears caches, warms up some views, maybe restarts the queue worker. It all works. Until someone hits CTRL+C halfway through. Now your queue workers are still running code from the old release, but the database schema has changed. Good luck debugging that one at 2am.

    Instead, slap in a trap:

    cleanup() {
    echo "Rolling back deployment..."
    # Remove symlink to new release
    # Re-point to previous release
    # Maybe alert yourself on Slack
    }
    trap cleanup INT TERM

    Now when your deploy dies mid-flight, it at least leaves things in a state where you don’t have to swear at Redis.

    Or maybe you’re running tests locally with a custom script — database seeded, environment booted — then halfway through, you realise you forgot to --filter the test you actually wanted. CTRL+C to cancel. But wait — your local DB is now full of test garbage. Again, trap can step in and handle cleanup, like dropping your test database or rolling back transactions.

    Final thoughts

    trap is like that one reliable friend who turns off the oven when you fall asleep during Bake Off. Underappreciated. Uncool. But essential.

    Laravel might live in PHP, but the ecosystem around it runs on Bash. So next time you’re scripting anything remotely important — a deploy script, a Docker entrypoint, a CI/CD step — use trap. Your future self (and your database) will thank you.

    Now if only we could trap bugs in Laravel before they hit production…

  • Mechanics and their own cars

    Mechanics and their own cars

    I often think of web developers and their websites like mechanics and their cars, or chefs and their home-cooking habits – when you spend a lot of time building web applications as part of your dayjob, it’s easy to neglect your own online presence. Many developers opt for a GitHub Pages site or a very simple CV-style one-pager.

    I decided that it was about time I reinstated my own website for a few reasons:

    • I haven’t had a real personal home online since around 2012, when I was but a young green junior with a lot more ambition than practical knowledge;
    • Having a place to write has a few potential benefits: it’s therapeutic to get your thoughts out sometimes, it’s nice to be able to reflect on past learning experiences and see how far you’ve come, and just maybe, on the off chance, someone else will find my inane babble useful too;
    • Whilst I love project work, one of my favourite aspects of this career is the fact that it moves so fast, there is always something new to learn – and what better place to experiment with new technologies than my own site, where the only person irked by any downtime is myself?

    So with that in mind, I set myself a few goals for this self-initiated mini-project.

    Firstly, I should use some technology that’s new to me.

    Having spent the last few years of my development career primarily focused on backend technologies like Laravel, I felt it would be good to get my head stuck into the fast-paced world that is the current javascript ecosystem.

    Of course I’m no stranger to JS by any means (remember Mootools, anyone?), but I’m definitely not as up-to-date with that side of the web as I’d like to be. There’s a lot of really cool stuff going on with NextJS at the moment, so that seemed like a great place to start.

    Secondly, I’d like to manage content through a familiar interface.

    I know, you hate WordPress. It’s almost like a badge of honour for serious web developers to hate WordPress. I totally understand the multitude of reasons – we’ve all experienced client sites with more plugins installed than should ever be considered reasonable, and the fact that the WP Foundation is led by a borderline sociopath doesn’t really give it any good publicity.

    The fact of the matter is though – as a content management system, it’s actually pretty damn good.

    I played with Sanity.io for a day or two on a side project six months or so ago, and whilst I totally appreciate how powerful it is as a content management system, for a lot of use cases (this one firmly included) it’s just a sledgehammer to crack a walnut. I need posts, I need pages, I need taxonomies, and that’s pretty much it. WordPress gives me all of that all within the “famous” 5 minute install.

    Thirdly, can I do this at a reasonably professional level for no cost at all?

    I just want to preface this by saying it’s not because I’m tight. Far from it – I’m actually terribly frivolous with money. I wanted to try and do this for free because, well… why not? Can a web developer in 2025 build a CMS-powered, well-hosted, extensible, fast and performant website on the same budget as those spinning up a static page on GitHub Pages?

    As it turns out, the answer is: “yes!” Pretty easily in fact. This site is up and running, with a NextJS frontend and a WordPress backend, for the total budget of £0.

    I’d tell you how I did it right now, but then I wouldn’t have much to write about in my next blog post, so you’ll just have to wait and see.

    I know, what a cliffhanger!