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.

When the New World Trading Company pitched their idea to me as "A bit like the sorting hat from Harry Potter," I was in. Realizing that this meant connecting to an HR API, building an admin dashboard, and exporting everything daily to a third party made me a bit more hesitant!

The most important part of the project was helping to strip back the requirements to create a foundation that covered what the client really needed, leaving plenty of room for future additions. I chose Firebase as the backend, allowing me to quickly create and push features. For the front-end, I utilized a React, TypeScript, and Styled Components template I had created for exactly this purpose.

The hardest part of the project was working with live data that needed to be updated and manipulated daily. The key to tackling this was creating logs of performed operations and regular backups for the worst-case scenario. Writing about this project without using more Harry Potter puns was the real challenge.

How would you sell a 3D food printer? What about a biodegradable toothbrush? Or an easy one: a lovely cup of coffee?

In this social card game, you are tasked to do just that, but with a twist. Players take turns to be a "pitcher" and sell a product from their hand to the rest of the group. However, when they finish their pitch, everyone submits a card, which is then shuffled and shown. Everyone must guess which product they think is the pitcher's and will score points for anyone they trick. The pitcher has the most difficult job, as they will not receive any points if everyone guesses their product.

Pitch Please was a board game that could only exist thanks to the iterative powers of software. Creating a React app to design cards allowed me to quickly dial in the look and feel of the game and prototype different rules and mechanics with ease.

Using AI to generate the imagery fit well with the 'startup' premise of the game. It allowed me to easily create any product, no matter how wacky. The biggest challenge with the implementation of AI was in generating a consistent style so that the game felt cohesive.

Odd Topix is a quick party game of talking and deception. The rules are simple: fulfill your prompt and include your given words. If the other players successfully guess any of your words, you're out!

I created Odd Topix as I wanted to explore the physical manufacturing process. One of the advantages in the world of software is speed to market and iteration. Having spent my career in that world, I thought it was important to gain hands-on experience with a practical project. The lead times and costs involved in physical manufacturing really highlighted the advantages of software, and I quickly realized the benefits of using software to prototype and iterate on the game design before manufacturing the final product.

After all the work of development, the final choices of card stock, packaging type, and printing process were much more nerve-wracking and difficult than I had anticipated. Once the game was in my hands, I was so excited by the result and still find it hard to believe that this real physical product was something I created.

The question is... can you guess the Odd Topix I was given for this post?

"Shout 'Em Out" is a re-envisioning of one of my childhood favorite games. The premise is simple: each card contains a category. The opposing team simply needs to try and guess the top 10 answers to that category... the catch? You're not looking for the right answers, you're looking for the ones LLMs circa GPT-3 think are the right answers.

The game was created to explore LLMs and OpenAI's API. Although far from the models we see now, I was blown away by the demos I was seeing and wanted to experiment with it myself. I created a simple app to propose categories and parse the responses into lists of answers. This tool gave me easy access to regenerate or nudge responses, as well as to correct Americanized spelling or remove duplications.

Once I had my categories and answers, I created a React app to generate the cards using print CSS queries, easily printing off the final version. This was the day I learned that I hate styling print media :). The software allowed me to easily generate over 100 cards and iterate on the design and layout with minimal effort.

The final product was a fun game that I could play with friends and family, but also a great learning experience in the power of AI and the benefits of software in the physical world. It also taught me a valuable lesson in the capabilities and dangers of AI, most importantly the subtle (and sometimes not so subtle) biases that these models have and can represent.

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.

Booze bot was a collaborative project with me and Matt. The idea was simple: make a robot that could pour the perfect drink. The execution was a little more complicated. combining software, hardware, and mechanical engineering meant the challenges were near endless. From broken tubes to erratic webpages we battled our way through the obstacles and the resulting pour tasted all the better for it.

Although just a fun project with a friend, Boozebot really taught me about the implications of a cross disciplinary project. Each additional part is an entirely new surface are to go wrong and so the approach needs to be more methodical and considered.

Responsible for upkeep and implementation of new features for the webapp from ideation to implementation.

• Introduced and implemented React hooks across the product.
• set up Cypress.JS as part of Gitlab pipeline to run automated E2E tests

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

When making games, I stumbled across a video talking about making a game feel 'juicy'. The idea was that 80% of the work was in the polish of the game, making things shake, stretch, bounce, pop, and generally feel good to interact with. This concept immediately resonated with me, and I started trying to implement it in my games straight away.

As I saw the fruits of this labor, I started thinking about its application in areas outside game development and realized the same principles applied pretty much anywhere but were obvious in the world of web development. Not everything needed to shake and beep, but crafting a UI that was satisfying to use is the holy grail of UX.

I started looking for libraries I could reach for and documented them in a public Github repo called "Pulp" (despite hating juice with bits, I couldn't resist the pun).

When Hacktoberfest rolled around, I realized it was an excellent, low-pressure candidate for people new to the Git process to collaborate on. Not only could people get a feel for open-source contribution in an easy to implement way, but they would also be encouraged to explore new libraries that might help them in the future.

As the sole representative of the innovation lab, I created software to demonstrate and explore new technologies. From VR to AI I had to assess a technology, build a proof of concept, prove a business case and present to clients.

• I represented the company giving talks to over 400 members of the IAFN and FLA.
• Created a Virtual Reality showroom for use at events and conferences.
• Built an AI powered chatbot development suite to allow clients to easily create their own chatbots.

DXJS is my first ever public library. I made it to help learn the process of publishing to NPM and gain experience with the entire development process from start to finish.

The library allows you to easily roll any arbitrary TTRPG dice, from a common d20 to a bespoke "weather" dice.

By utilizing an intermediary Abstract Syntax Tree (AST), the library can parse a string into individual dice rolls and breakdown the output.

This allows users to perform simple actions like roll("d20") or more complicated ones like roll("2d6+4d4+2") and get the results in a structured format.

Users can even add their own dice: javascript new Dice("weather", ["sun", "rain", "snow", "wind", "fog", "hail", "thunder", "lightning", "clouds", "clear skies"]); roll("weather")

Over the years it had features added including weightings and modifiers and has recently had a complete rewrite in Typescript.

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