Nonograms are a simple but sometimes fiendishly difficult puzzle that my partner and I have become slightly addicted to. She is much better at them than me so in a desperate attempt to even the odds I thought it might help give me the edge to make them myself.

Conceptually a lot of the algorithms for a nonogram are quite simple. It actually makes for a nice little interview question because the key lies in breaking down the problem into smaller easy to reason parts. However, I hit a stumbling block when I realised there was an edge case where a random generation might not have just one unique solution. This was a problem because when it was generated it would store the "correct" answer it had in mind. This meant you could correctly solve the puzzle but not be awarded for the win; Disaster!!

After staring down the rabbit hole of having to potentially wrestle with holistic ways of approaching a "P vs NP", I came to a much more sensible solution.

Instead of solving for the difficult case of guaranteeing a unique solution, I could just change how the game checked whether it was in the "won" state. This problem seems difficult at first, especially when you consider the original implementation just compared the user's proposed solution with a stored one... but it actually turned out simple in a really pleasing way!

Each horizontal and vertical line of the puzzle has a list of numbers that represent the number of consecutive blocks of colour in that line, these are like "clues" to help you solve the puzzle. If you want to check any arbitrary proposed solution you can simply generate what the clues would be if the solution was a puzzle itself and then use those as your comparison.

I think there something really pleasing about this solution, and it's a great reminder that sometimes you need to stop and just take a minute to consider problems from a completely different angle.

Working in the environmental sector gave me key insights into the importance of creating tools to help large companies reduce their carbon footprint.

However, this involves a completely different and more corporate language than the broader, more general conversation demands. I created this pollution calculator as a tongue-in-cheek way to explore the UI and language of a simplified consumer-targeted app compared to its more dry corporate counterpart.

Although this satirical tool holds no real value and pokes fun at common tropes of the media's representation of the crisis, it does represent a very real issue in software development. When creating a tool, it is more important to engage with the user in a way that resonates with them. Being 'clever', 'technically better', or 'more accurate' is not always the best way to get engagement and adoption. Just ask Zune, Betamax, or HD-DVDs.

Smiley Slots is a slot machine I built on CodePen. I was intrigued by the challenge of using available tools in unique ways.

The idea of using emojis as graphics came to me, and I decided on a slot machine concept using CSS animations for blurring and motion. I also used the Web Audio API for simple sound effects.

One big challenge was working without the IDE features I'm accustomed to. It was a refreshing return to more basic, vanilla concepts that get abstracted in frameworks and advanced editor functions.

The experiment was a hit with friends and coworkers, and I was surprised by the high scores they achieved.

Dynamic audio always excited me, but I felt overwhelmed about where to start. This CodePen was my simple, fun attempt to explore audio generation.

Focusing on a familiar sound effect - the 'puzzle solved' or 'secret found' from games like Zelda, I broke it down into two simple rules for creating a 'curious' sound: the notes should climb and resolve higher than the first note.

This basic setup yielded surprisingly effective results. It demystified dynamic audio for me, leading to more exploration in the field.

Exploring the web audio API and making my first bleeps and bloops on an oscillator immediately brought me back to my childhood playing with the ringtone composer on my Nokia 3310. I figured that memory would make a great way to explore this API and so I set about making a ringtone composer of my own.

Using the same Ring Tone Text Transfer Language (RTTTL) I had memories of scouring the internet for, I created a simple interface to play them.

Even years later with HD ringtones and the ability to play any song you want, there is something so satisfying about the old school bleeps and bloops of a classic ringtone.

and for extra nostalgia points (bpm 60):

8e2 8e2 8d2 8d2 2c2 8d2 4e2 2a1 8a1 4b1 4g1 4e2 8d2 4c2 8d2 2e2 4- 8e2 8e2 8d2 8d2 2c2 8d2 4f2 2a1 8a1 4b1 4g1 4e2 8d2 2c2

Ring of Fire is a drinking game that has been around for a long time. It's a game with a lot of different rulesets and variations. I wanted to create a place where people could share their unique variants and build, share, and comment.

This was the first project where I really started to dive into front-end development. Although still PHP-based, this was my first personal project that engaged with JS as more than just an AJAX call or a simple form submission. This included a drag-and-drop interface and live previews of the rulesets

Then I Woke Up was a PHP-based website I used as my first foray into web development. Trying to ride on the coat tails of the popular "FML" formula, the site was a place for people to share their weird, bizarre or just plain bad dreams.

Although long dead, the Wayback Machine caught a glimpse of it during testing, naked without any of its styling or interactivity.