
**_TLDR; How I think the forgotten art of Test Driven Development is the solution to vibe coding at scale._**

2 and half years ago and 27 days BEFORE the release of ChatGPT I wrote this post: [AI & The Future of Game Development](https://mikecann.blog/posts/ai-and-the-future-of-game-development)

In it I predicted that software developers would come to treat their application as a black box. They would neither know nor care how it worked, they would only desire the correct output.

Well fast-forward to 2025 and tools like [Bolt](https://bolt.new/), [Lovable](https://lovable.dev/) and [Chef](https://chef.convex.dev/) have exploded in popularity as we saw the birth of a new way of developing software known as [Vibe Coding](https://en.wikipedia.org/wiki/Vibe_coding).

## Vibes

When you vibe code you are cruise-controlling your way though app development.

You prompt the AI for a new feature or request a change to something existing. You then just sit back as it does its thing. You then just check that your app still works and accept the code changes usually without inspecting them, you are going purely on "vibes".

Doesn't this sound awfully a lot like what I predicted back in 2022?

Yes you may now call me nostra-cann-mus

![alt text](./cannstradarmus.png)

Now in my prophesied post of 2022 I went on to make one more prediction and I think this is one that is ripe to be explored right now.

## Problems

You see the issue with Vibe Coding is that it produces shitty code.

Who cares tho right? So long as you get the output you want who cares what in that black box, just dont look inside.

![alt text](./spaghetti.png)

Well the problem is that it turns out it kind of does matter as I discovered after a 3 day vibe coding binge.

I made a video about it if you want to watch me recount the horrors of that adventure:

<iframe width="560" height="315" src="https://www.youtube.com/embed/IV36_9QNF9w?si=PmG7Mq2I4XEdDoA6" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

If you aint got time for dat then no worries, the TLDR; is that just like human coding, vibe coding falls over beyond a certain point because the AI desperately tries implement whatever half-baked request asked of it without much thought for the architecture or maintainability of the application.

This is one of those key distinctions between Junior and Senior human software developers.

A more senior developer has had enough time to lie in the bed they have pooped in and thus know that you have to spend time thinking about the code structure otherwise you will inevitably run into maintainability issues down the road.

We even have a term for this phenomenon: "technical debt".

## Solving AI Tech Debt

So what has this got to do with my 2022 prediction?

Well right at the end of the article I mentioned this:

> I guess in some aspects this is the ultimate promise of [BDD](https://en.wikipedia.org/wiki/Behavior-driven_development). We specify in written english what the system under test should do and dont care about how it does it so long as it does it.

What I meant by that is that even though you can prompt your way to a solution of some sort the output is only as valid for as long as the LLM remembers or cares to pay attention to your prompt.

The issue everyone is currently facing with vibe coding is that as a codebase grows in size the AI just like a human looses the ability to keep it all in context and thus forgets some of your previous requirements.

This leads to what I sometimes describe as "carpet fitting". You ask the AI to change the thing over here but it ends up breaking the other thing over there.

What we need is a way to make our prompts "verifiably correct" now and in the future. That way as we make subsequent prompts the AI and us are able to verify that our earlier prompts still hold true.

Well fortunately the software industry has just the solution to this conundrum that it has been fine art over decades: **Automated Testing** or more specifically **Test Driven Development** (TDD).

What if instead of writing a prompt asking the LLM to do something for you, you instead:

1. Write a test in plain English
2. Have the AI fill out the test code that would ensure that your requirement passes
3. Have the AI write the implementation to make that pass.
4. Once we know we have a working version then the AI is then safe to go back and tidy up the code to make it more maintainable so long as the tests still pass.

Then you the human can write another set of requirements and the cycle starts all over again.

![alt text](./tdd.png)

_Image borrowed from [this post](https://medium.com/@tunkhine126/red-green-refactor-42b5b643b506)_

It has long been known that this test-first mentality creates better, more maintainable code but then downside has always been cited as a reduction in development speed. It takes time to write all those tests, time that could be spent just implementing features.

Well in the age of AI, speed of development is no longer really an issue, now the issue is one of correctness and confidence.

Writing tests is now painless, what we want is confidence that what LLM has just slopped out is actually going to work and is is going to be maintainable in the future.

## Parallel Benefits

So if we change from a model of prompt-wait prompt-again-and-hope and instead change to a model of Test, Implement, Refactor we can verify that any future changes don't break existing code.

The nice thing about this is that you can treat all those tests as independent entities that can be run in parallel. This means there is room to massively speed up the development process by working on multiple features at once.

You can be working on the next feature (Red) while the AI is still working on the last. So long as at the end of the day everything eventually becomes consistent and merges nicely who cares, its just a black box right?

Sure this might use up quite a lot of compute but as the cost of compute continues to fall I see this really becoming less and less of an issue.

## Conclusion

So this is what I want to see next. I want to see vibe coding start to take inspiration from what the software industry has learnt over the past 50 years around building maintainable code.

I don't think Vibe coding is going away in fact I think eventually its going to become the ONLY way people build apps.

I do think that for us to get to that future though we will have to flip our mental model from a prompt first to a test-first mindset.

What you think?


I have got to be honest, I have never heard of [Web Dev Cody](https://www.youtube.com/@WebDevCody) before but when I saw that he had a [hackathon](https://hackathon.webdevcody.com/) in partnership with [Convex](https://www.convex.dev/) I knew I was going to have to carve off a bit of time from [BattleTabs](https://battletabs.com/) development to have a crack.



# Competition Categories & Ideation

![](./categories.png)

The competition was themed around Collaboration and AI so I racked my brain for a bit before coming up with an idea.

I wont spend too many words explaining what I built, instead ill let the video that I used to demo the project do the talking:

<iframe width="853" height="480" src="https://www.youtube.com/embed/XZ2iCEcW_io" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

# Results

Out of [53 submissions](https://hackathon.webdevcody.com/submissions), I came third in the AI category which im pretty happy with considering I spent less than a day on it.

Watch Cody talk about my project here:

<iframe width="853" height="480" src="https://www.youtube.com/embed/PJjk4Qg_GiU?si=9oUEhACACbj3KxkR&amp;start=186" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

# Conclusion

I had a ball working on this, its pretty astounding that you are able to build this much functionality in such as short time. I was able to implement and iterate as fast as I could go without any boiler-plate bogging me down.

[Convex](https://www.convex.dev/) really is an incredible technology, if you are looking to do a web app you should definitely check it out!

If you are interested in playing with Chatter Craft yourself the demo is here: https://chatter-craft.netlify.app/

If you want to peek under the covers a bit the source is available here: https://github.com/mikecann/chatter-craft

When I was sent a replacement for my broken [Versa 1](https://www.fitbit.com/global/us/products/smartwatches) by Fitbit they decided to upgrade me to a Versa 2. This was great except it meant that the watch face I was using before no longer worked and I was unable to find a good replacement so I thought it was time to get my hands dirty and code one up myself.



# TLDR;

![](./out1.gif)

Check out the clock face: https://gallery.fitbit.com/details/e865d518-7a36-41b2-b3e7-e12789c138a8

# How?

Micro controller development such as the [Arduino or ESP32](https://www.arduino.cc/en/software) tends to involve hacking away in low-level languages such as C. Fortunately Fitbit make things super easy with their Fitbit Studio their online IDE and the language choice (Javascript).

![](./fitbitstudio.jpg)

It was super simple to setup a new project. Define your project and permission requirements in the "package.json" and start coding against their excellent SDK.

![](./package.jpg)

As a (mostly) web developer these days I found it easy-peasy to get started with [their SDK](https://dev.fitbit.com/build/reference/device-api/power/) just import a few things then start reading data from the sensors.

One aspect unique to watch development is the care you have to take around battery. Limiting computation and sensor reads is important to prolong time between charges. Thankfully the SDK has you covered here and provides some handy API's for detecting screen on and off events.

![](./display.jpg)

When it comes time to test your clock face you can either run it on device or via a very handy simulator that Fitbit provide. Connecting from Fitbit Studio is all rather straight forward tho I did have a couple of times where the IDE refused to connect to the watch for some reason.

![](./sim.jpg)

# What?

So what does my Clock Face do? .. Well it can tell the time ... among other things ..

![](./frame1.png)

It also shows the most important sensor readings in each corner; battery, heart rate, steps and stairs climbed.

I decided to get a little fancy with the icons for a couple of them. The battery icon has a bar that changes size depending on the battery level and the heart icon flashes from full to empty at the rate of your BPM.

After getting these basics in there I started to get a little carried away and decided to add some extra info.

![](./frame2.png)

A press of the screen and the user is taken into an auxiliary data mode. The date is replaced by the time the watch was last synced (I have found this useful to know so you don't loose data). This auxiliary data mode also reveals the "battery life estimation" instead of the current battery level.

![](./frame3.png)

The battery estimate feature is a little experimental but it seems to work well enough. When the battery level drops by 3% or more it calculates the time taken to decrease by that amount and interpolates the remaining time for the current battery level.

Last but not least I decided to add one final mode you can access by tapping the screen twice

![](./flashlight.png)

Flashlight mode makes the screen go completely white and is actually super useful for when you get up in the middle of the night and its pitch black and cant see but don't want to turn the light on.

# Conclusion

All in all im happy with how things went. Fitbit put a lot of effort into making the development experience a breeze which made the process fun.

The watch itself works well and does everything the last one did and more.

Its even received a few positive ratings already :)

![](./reviews.jpg)

If you are interested in getting the watch yourself its freely available on the Fitbit Gallery here: https://gallery.fitbit.com/details/e865d518-7a36-41b2-b3e7-e12789c138a8

I also uploaded the source code to Github incase you want to take a closer look at how things work under the hood: https://github.com/mikecann/minimal-mike

I mentioned [in my last post](/machine-learning/a-game-developer-learns-machine-learning-intent/) that the intent is to write an AI to play [Mr Nibbles Forever](http://epicshrimp.com/app/mrnibblesforever/) better an any human. Before we can get anywhere near that goal however we need to get the very basics working first.



# The Series

If you are new to the series I recommend you checkout the previous posts first, here's the whole series:

0. [A Game Developer Learns Machine Learning - Intent](/machine-learning/a-game-developer-learns-machine-learning-intent/)
1. A Game Developer Learns Machine Learning - Getting Started
1. [A Game Developer Learns Machine Learning - A Little Deeper](/machine-learning/a-game-developer-learns-machine-learning-a-little-deeper)
1. [A Game Developer Learns Machine Learning - Mr Nibbles Basics](/machine-learning/a-game-developer-learns-machine-learning-mr-nibbles-basics)

# TLDR;

We will use Reinforcement Learning to train an agent to balance a ball.

<iframe width="853" height="480" src="https://www.youtube.com/embed/ZnBfvARKXeo" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

# Unity ML Agents

I find that when tacking something new for the first time, the best thing to do is take something built by others, then hack around with it for a little bit to understand the very basics. So rather than starting from total scratch im going to look for something that already exists.

As luck would have it, Unity have [just released](https://blogs.unity3d.com/2017/09/19/introducing-unity-machine-learning-agents/) a new set of tools to help game developers use machine learing in their games, perfect!

# Getting Setup

First things first, I clone the Unity ML Agents repo https://github.com/Unity-Technologies/ml-agents.

Then I start following their [Getting Started With Balance Ball](https://github.com/Unity-Technologies/ml-agents/blob/master/docs/Getting-Started-with-Balance-Ball.md) docs.

The first thing I need to do is get my system setup with the neccessary tools for machine learning. I follow this guide to do so: https://unity3d.college/2017/10/25/machine-learning-in-unity3d-setting-up-the-environment-tensorflow-for-agentml-on-windows-10/

This process takes quite a while, make sure you follow the instructions EXACTLY. At the bottom of that page is a video which is helpful.

<iframe width="853" height="480" src="https://www.youtube.com/embed/qxicgknzUG8" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

# Jupyter Notebook

So with my system now setup I return back to the [Balance Ball](https://github.com/Unity-Technologies/ml-agents/blob/master/docs/Getting-Started-with-Balance-Ball.md) doc.

The next step is to open Jupyter Notebook which is a popular tool with ML community for training models.

![](./jupyter-basics.png)

Its actually a pretty aweomse tool. Its sort of like a [REPL](https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop) mixed with word document.

You can write code right inside of the doc without firing up and IDE and then execute it and see the results inline.

# Testing the Bridge

Next up is the "Testing Python API" section of the docs.

In Unity the balance ball scene is compiled into an exe, this is whats known as the "environment".

![](./showing-exe.png)

Python in the notebook talks to the "brain" in the environment. Its a sort of native bridge between the machine learning API in Python and your "game" / "environment".

![](./bridge.png)

When the training session is started from python, the environment exe is executed which opens as a separate window on your computer. This surprised me as I was expecting it to be hidden background process of some sort.

The environment window that opens up is tiny, presumably so your GFX card doesn't have to waste cycles on rendering and can instead focus on ML.

![](./env-window.png)

The "brain" in the environment is able to receive commands which are called "actions". When an action runs, it changes the "state" of the environment which is returned back to Python. That process of `State > Action > New State` is repeated over and over again (along with some other magic) and out pops our agent.

![](./learn-loop.png)

# Training the Model

Now we know our bridge from Pythong to Unity works okay we can move onto actually training the model.

Folling the "Training with PPO" section of the docs we open "TensorBoard" which gives us stats on the the training process as it runs.

![](./tensorboard1.png)

Im not really sure what all those stats mean but thats okay at this stage, we are just tinkering!

The main thing is my model is busy training itself as evidenced by the changing graphs and my pegged CPU ðŸ˜œ

![](./pegged-cpu.png)

# Testing the Model

Once the "cumulative_reward" is above 75 the model is ready to rock. So I stop the training process in Jupyter.

Theres one last step before we can run the model in Unity, we must add support for TensorFlow directly in Unity in the form of the TensorFlowSharp library.

![](./tf-sharp.png)

TensorFlowSharp requires the experimental .Net 4.6 support in Unity. Thats something to note because as my goal is to eventually get this working on Mr Nibbles Forever which is built on the old .Net 3.5

With the library installed we copy over the generated model into the game and huzzah! It works!

![](./it-works.png)

# Adding some Dynamics

Its awesome that it works but its hard to tell if this is actually balancing the ball dynamically or not. I think if we add a dynamism it will make things clear.

Lets add this script to each of the platforms:

```csharp
using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class BallNudger : MonoBehaviour
{
    public Color nudgeColor = Color.red;
    public float forceMultiplier = 5f;
    public float colorChangeTime = 0.5f;

    private bool _isNudging = false;
    private Renderer _renderer;
    private Rigidbody _rigidBody;
    private Color _startingColor;
    private float _colorChangeAge;

    void Awake()
    {
        _renderer = GetComponent<Renderer>();
        _rigidBody = GetComponent<Rigidbody>();
        _startingColor = _renderer.material.color;
        _colorChangeAge = colorChangeTime;
    }

    void OnMouseDown()
    {
        _colorChangeAge = 0;
        var ray = Camera.main.ScreenPointToRay(Input.mousePosition);
        RaycastHit hit;
        if (Physics.Raycast(ray, out hit))
            _rigidBody.AddForceAtPosition(ray.direction * forceMultiplier,
                hit.point, ForceMode.Impulse);
    }

    void Update()
    {
        _colorChangeAge += Time.deltaTime;
        _renderer.material.color = _colorChangeAge < colorChangeTime ?
            nudgeColor : _startingColor;
    }

    private Vector3 GetRandomForce()
    {
        return new Vector3(
            Random.Range(-forceMultiplier, forceMultiplier),
            Random.Range(-forceMultiplier, forceMultiplier),
            Random.Range(-forceMultiplier, forceMultiplier));
    }
}
```

Now when we click the ball, it changes color and gets a little nudge. Lets run it again and yes, indeed the AI is able to balance the ball dynamically as the input changes.

<iframe width="853" height="480" src="https://www.youtube.com/embed/ZnBfvARKXeo" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

# Conclusion

Cool! Well that wasn't as hard as I thought it was going to be.

Sure I haven't actually done any of the hard work or really learnt much about the fundamentals yet but at least I have something working, ready for me to hack with.

So stay tuned, subscribe below as next episode im going to dive a little deeper.

Lately I have spent a considerable amount of time thinking about where I want to go in my career and what sort of things do I want to work on going forward.



# The Series

This is a series of multiple parts, if you liked this post then checkout the others:

0. A Game Developer Learns Machine Learning - Intent
1. [A Game Developer Learns Machine Learning - Getting Started](/machine-learning/a-game-developer-learns-machine-learning-getting-started/)
1. [A Game Developer Learns Machine Learning - A Little Deeper](/machine-learning/a-game-developer-learns-machine-learning-a-little-deeper)
1. [A Game Developer Learns Machine Learning - Mr Nibbles Basics](/machine-learning/a-game-developer-learns-machine-learning-mr-nibbles-basics)

# The History

![](https://www.mikecann.blog/wp-content/uploads/2007/09/Guess.jpg)

Before you think about where you want to go next sometimes it helps to think about where you have come from.

When I was 7 years old I [coded my first game](http://localhost:4500/about/). I loved the thrill of turning a meer figment of my imagination into something I could see on the screen and delight when shown to others.

At 18 I went to University and studied Computer Games Programming and loved every second of it, far surpassing my performance during high school, eventually graduating with a first degree with honours.

For the next 10+ years I proceeded to work in the games industry first starting in the flash games world then social games before moving to mobile.

Games are not the only thing I have been interested in over the years as this blog [certainty can attest to](/all-tags/). However games are definitely my core competency.

# The New Shiny

So when you are in an industry that moves so fast with so many new technologies being released every day, it can be really hard to know where to spend your time, particularly for someone like me who "just cant stop tinkering with things" â„¢.

Machine Learning (ML) is one of the biggest technologies to emerge over the past couple of years. I honestly think that ML has the power to transform every single industry from finance, to agriculture to sports science.

I also think that the games is no different from the others and wont be spared from its transformative effects. Some think that the games industry is safe because its a "creative" industry and thus not susceptible to being replaced by a logic driven machine.

Instead I see a future where an AI is capable of generating an entire game based on your preferences such as "I would like a game that plays like Mario but has the same size and scope as World of Warcraft", the AI then generates variants on that for you to play.

Machine learning opens so many potential possibilities and opportunities for someone with the idea and ability to explore them.

So with that in mind I think that it behove me to at least consider exploring ML a little more.

# The Concern

<div style="width:100%;height:0;padding-bottom:56%;position:relative;"><iframe src="https://giphy.com/embed/rdvtXVH7jDjKU" width="100%" height="100%" style="position:absolute" frameBorder="0" class="giphy-embed" allowFullScreen></iframe></div><p>

But will I enjoy it? This is a major concern of mine. From what I have seen thus far, machine learning is very math heavy, invloves a lot of Python (dynamic programming, _shudders_) and isnt particularly visual. All negatives for someone who isnt great at maths, doesnt really like dynamic languages and is a games programmer.

I am also concerned that this I will basically be starting from scratch again. All my games programming knowledge counts for nothing. Will I be able to adapt to this new set of problems, solutions and tools?

So I think only way to know for sure tho is just to try it and see and the best way to try is to tinker! â„¢

# Learn to Learn

So over the next few months im going to dig deeper into machine learning. Try to understand it how it works and how it applies to game development.

Im going to blog each step of my adventures. This serves two purposes, firstly I find that writing things down really helps me understand things at a deeper level and secondly I hope that if I dont do a terrible job at explaining it will help others to learn too.

Im going to call this series of blog posts <strong>"A Game Developer Learns Machine Learning"</strong>.

# The Series Goal

![](https://www.mikecann.blog/wp-content/uploads/2016/05/MrNibblesForever_Gif_5.gif)

The goal for the series is I want to be able to write an AI that is able to play my game [Mr Nibbles Forever](http://epicshrimp.com/app/mrnibblesforever/) better than any other human player.

I have no idea if thats an achievable goal but I think its a goal that should give me a solid understanding of the fundamentals of reinforcement learning and give me a target with which to focus on and guide me through this dense but wonderful topic.

So if you are interested in following along, either [add this blog to your favourite RSS reader](/atom.xml) or enter your email below to subscribe and get email updates.

I last wrote about Markd [back in September of last year](/posts/portfolio/projects/introducing-markd-pinterest-for-people/) so I think its about time I gave you an update on our latest progress on the project.



# Refresh

Just a quick reminder about Markd; its a super cool project that I worked on for my long-term client and friend [Brandon Wu](https://www.pepwuper.com/).

At its core, its a chrome-extension that lets you "bookmark people". So for example, say you stumble across a cool games developer on Twitter and you want to make a note of him for a project you have planned in the future. You can simply click the Markd icon in Chrome to "mark" them. They are then added to your searchable collection for the future.

## TLDR;

Check out the video below for a quick demonstration:

<iframe width="853" height="480" src="https://www.youtube.com/embed/0TH_JNTOPdg" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

# The Problem

As [mentioned previously](/posts/portfolio/projects/introducing-markd-pinterest-for-people/) the tech stack in Markd 1 was a combination of Aurelia for the extension with Microsoft's ASP.net Core on the backend and hosted on Azure.

The problem was that I was never very happy with the way things were on the code level. There was no sharing between the extension and the client which led to many issues and bugs in conversion from one data format to another. I also had problems building Aurelia as every time I went back to it, everything had changed and I could no longer build. None of the docs matched what I had and it was generally a nightmare.

# The Update

I decided I need a do-over, this time I decided that I wanted the entire thing in the same language so I could share the code between the client, server and extension.

## Typescript

This time I wrote the entire thing using my favourite Javascript alternative: Typescript. I have been a fan of Typescript for many years now and have blogged about it many times so I wont wax on about it much here.

Just a quickly; one of the new Typescript features I took advantage of for Markd2 was "[non-nullable types](https://blog.mariusschulz.com/2016/09/27/typescript-2-0-non-nullable-types)". To be honest this feature is so great it should be in _every_ language, I strongly recommend reading up on it as it totally destroys an entire class of bugs.

## React

I have been using React for years now, and IMO its pretty much how the UI should be done. I wont talk about it here because well.. if you dont know about React yet then you are [doin' it wrong](http://thechive.com/category/humor/doin-it-wrong-funny/).

## MobX State Tree

For state management I started off by using my favourite, [MobX](https://mobx.js.org/) but discovered there was an update on their sister project [MobX State Tree](https://github.com/mobxjs/mobx-state-tree) (MST) that I had been following for a while so decided to give it a whirl and fell in love.

MST is a state management library similar to [Redux](http://redux.js.org) except unlike Redux the properties in your model are reactive. That is you can listen to them and create "computed" variables that react when that property changes.

So for example here is part of the model for a Mark:

```typescript
export const Mark = types
  .model({
    id: "",
    name: "",
    profileImage: types.maybe(MarkdFile),
    importedId: types.maybe(types.number),
    tags: types.optional(types.array(types.string), []),
    links: types.optional(types.array(types.string), []),
    referenceImages: types.optional(types.array(MarkdFile), []),
    description: "",
    notes: "",
    sourceUrl: "",
    createdByUserId: "",
    createdAt: types.maybe(types.Date),
    updatedAt: types.maybe(types.Date),
  })
  .named("Mark")
  .views((self) => ({
    get hasBeenSavedToServer() {
      return self.createdAt != null;
    },
  }))
  .actions((self) => ({
    setName(v: string) {
      self.name = v;
    },
    setProfileImage(v: IMarkdFileSnapshot | null) {
      self.profileImage = v as any;
    },
    setTags(v: string[]) {
      self.tags = v as any;
    },
    setLinks(v: string[]) {
      self.links = v as any;
    },
    setReferenceImages(v: IMarkdFileSnapshot[]) {
      self.referenceImages = v as any;
    },
    setDescription(v: string) {
      self.description = v;
    },
    setNotes(v: string) {
      self.notes = v;
    },
    setSourceUrl(v: string) {
      self.sourceUrl = v;
    },
    setCreatedByUserId(v: string) {
      self.createdByUserId = v;
    },

    load: process(function* load(id: string): any {
      const service = getEnv<IMarkEnv>(self).marksService;
      self.id = id;
      var snapshot = yield service.getMark(id);
      applySnapshot(self, snapshot);
    }),
  }));
```

As you can see we can define a number of properties in a strongly typed manner in the "model", then we can declare computed properties such as `hasBeenSavedToServer` in the "views" then we can define actions that can mutate the model in "actions". Those types are checked at compile time (thanks to Typescript) and runtime (during development) so you can catch even more of those pesky Javavascript typing issues.

Its a nice little system that combines the best of MobX and Redux.

I used MST to great effect in both the client and extension. I was able to reuse a lot of code between the two which made for less bugs.

## Parse Server

For the backend I decided to go with [Parse Server](https://github.com/parse-community/parse-server). Why go with a defunct project I hear you cry? Well since Facebook decided to shut down Parse back in Feb of this year Parse has actually continued to grow in its Open-Source form and is constantly being added to.

I know Parse very well having used it before on many projects. With Parse you get a lot of things right out of the box such as Authentication, Data Storage, REST Endpoints, Live Object Updates and many others. All stuff I would have had to build up myself (and likely gotten wrong).

One of the other benefits of using Parse is you get a pre-built dashboard on your database which I find incredibly helpful:

![](./dashboard-ss.png)

Sure, you could say that editing databases manually is a bad idea but during development it can be quite the godsend.

## Unit Testing with Jest

Im sorry to say that after all my various web based projects over the years this is the first one in which I have employed Unit Testing properly. Previously I have had bad experiences with Unit Testing in Javascript but im very glad to say things seem to have come a long way.

```typescript
test("when loading, snapshot is applied", async () => {
  const markServiceMock = mock(MarksService);
  const marksService = instance(markServiceMock);

  when(markServiceMock.getMark("mid")).thenReturn(
    Promise.resolve({
      id: "mid",
      name: "mike",
      referenceImages: [{ name: "xxx", url: "yyy" }],
    })
  );

  var mark = Mark.create({}, { marksService });

  await mark.load("mid");

  expect(mark.id).toBe("mid");
  expect(mark.name).toBe("mike");
  expect(mark.referenceImages.length).toBe(1);
  expect(mark.referenceImages[0].name).toBe("xxx");
  expect(mark.referenceImages[0].url).toBe("yyy");
});
```

Writing tests is _almost_ as nice as C#. The above example is one test for the Mark model I used above. We are able to mock the return of the service, await the return of an async operation and assert the result, pretty sweet!

# Build Tools

## Yarn Workspaces

Sadly one of the big time-sinks of any Javascript project these days is how you go about building the damn thing. Its so bad that it even has a name [javascript](https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f) / [tool fatigue](https://medium.com/@mrannedev/it-s-not-javascript-tool-fatigue-it-s-javascript-bullsh-t-fatigue-5f90f81423fb).

Unfortunately I suffered from this yet again, spending weeks just trying to get the various projects to compile and work together. One key problem is what happens when your main "solution" has multiple sub-projects in it. Visual Studio solved this years ago with .csproj and .sln files but Javascript still struggles with this.

One solution that has evolved over the yeas is [lerna](https://lernajs.io/). Lerna attempts to manage the dependencies between packages automatically. The idea is that you structure your projects inside the solution directory such as:

![](./lerna-structure.png)

Lerna then manages the dependencies between the packages by using symlinks (`npm link`). This makes me shudder every time. I cant believe this is 2017 and we are using symlinks for dependency management ðŸ˜¢

I had issues when using Lerna. Libraries were getting included twice in my build and other various issues. In the end I ended up using the very new [yarn workspaces](https://yarnpkg.com/blog/2017/08/02/introducing-workspaces/). Yarn workspaces attempts to formalize the concepts in Lerna by baking them into the dependency management tool itself.

Im not sure exactly how or why this worked for me, but it did so im not going to argue with it and spend any more time on it (can you tell im frustrated with this crap?).

## Node Package Scripts (NPS)

Ive got a fair bit to say about this so have moved it out into [its own blog post](/tooling/node-package-scripts/).

## React Scripts

For the "client" (the SPA website https://markd.co) I decided to go with the incredibly popular [create-react-app](https://github.com/facebookincubator/create-react-app) this took away much of the build for dev / build for productuon production headaches that I usually faced with JS build tools.

Because I use typescript I had to use a slight variant on the project, if you want to do the same I reccomend starting with this: https://github.com/Microsoft/TypeScript-React-Starter

# Infrastructure

For this rewrite I decided to go with static hosting using a combination of Route53, Cloudfront and S3 to host the static part of the website (client) then used Heroku backed by mLab for the server and API. That's a fair few moving pieces but in the end it gives us total flexibility with minimal cost.

Because the static part of site is on S3 and Cloudfront CDN its really quick.

# Conclusion

Im really happy with the result of Markd2 the site is considerably faster, thanks to being hosted on Cloudfront and Heroku. Its less bug-prone because there is lots of shared code, plus im using the latest and greatest Typescript features. Its more reliable because its got a bunch of unit tests to ensure changes dont break anything. Its more flexible because we control the entire stack.

It took me quite a bit longer than I had hoped to get to this stage but now its finally there, it should be a solid foundation moving forward.

Well its been exactly [95 days since my last Alpha release](https://www.mikecann.blog/myprojects/mr-nibbles-forever/mr-nibbles-forever-alpha-7/) of my mobile game Mr Nibbles Forever which is far too long. I apologise to people who have been asking me for a new version. I took on a few paid freelance projects a few months ago and they took up a whole bunch of time then I decided to take a full time position up in Perth a month ago which [drastically cut down my Mr Nibbles development time](https://www.mikecann.blog/uncategorized/started-work-at-thebroth-in-perth/) sadly.



If you follow my [public Trello development board](https://trello.com/b/Ic11WQzF/mr-nibbles-forever) however you can see that I have been working in the intervening time, just not as fast as the earlier development:

[![2015-06-18_15-22-50](https://www.mikecann.blog/wp-content/uploads/2015/06/2015-06-18_15-22-50-1024x525.png)](https://www.mikecann.blog/wp-content/uploads/2015/06/2015-06-18_15-22-50.png)

In total there is something like 70 hours worth of my time that has gone into this release:

![2015-06-18_15-21-12](https://www.mikecann.blog/wp-content/uploads/2015/06/2015-06-18_15-21-12.png)

Although 70 hours doesnt sound like all that much I think that this release contains more changes than any other. As hinted in the last release and other posts, I now have an artist on the project, [Woody Stables](https://twitter.com/woodystables) who has helped totally transform the in-game backgrounds, the outfits, the effects and many other aspects of the game:

[![2015-06-19_07-54-53](https://www.mikecann.blog/wp-content/uploads/2015/06/2015-06-19_07-54-53-1024x575.png)](https://www.mikecann.blog/wp-content/uploads/2015/06/2015-06-19_07-54-53.png)
[![2015-06-17_20-46-28](https://www.mikecann.blog/wp-content/uploads/2015/06/2015-06-17_20-46-28-1024x766.jpg)](https://www.mikecann.blog/wp-content/uploads/2015/06/2015-06-17_20-46-28.jpg)
[![2015-06-19_07-54-14](https://www.mikecann.blog/wp-content/uploads/2015/06/2015-06-19_07-54-14-1024x576.jpg)](https://www.mikecann.blog/wp-content/uploads/2015/06/2015-06-19_07-54-14.jpg)
[![2015-06-19_07-54-30](https://www.mikecann.blog/wp-content/uploads/2015/06/2015-06-19_07-54-30-1024x576.jpg)](https://www.mikecann.blog/wp-content/uploads/2015/06/2015-06-19_07-54-30.jpg)

So now there are 13 different outfits in the game which you can win by spinning the wheel. They all look different and awesome but still stick to the same cutesy Mr Nibbles art style. Some of them come with cool and interesting effects as the below video shows:

<iframe width="854" height="510" src="https://www.youtube.com/embed/aN5S0zMux30" frameborder="0" allowfullscreen></iframe>

You will also notice (if you have your sound turned on) that the game also now has a whole bunch more sound effects. That's entirely thanks to [Joe Watkins](https://twitter.com/watkinsonic) who I recruited to help out with the audio on the game. I think the audio really lifts the game up and adds so much more value to the different outfits and is often an overlooked but valuable part of games making.

The game really has started to take its final shape in my opinion but there is the problem. At the moment it has mostly only been my opinion of the game which has shaped its development. I have had a few testers play the game throughout its development and im very grateful for that but now its getting to the point where I need to test in earnest.

I am also very aware of the fact that I need to concentrate on marketing the game much more. At the moment the game is only really visible to a small number of people, people who read this blog, people who are members of the facebook page and people who I have met and talked to about the game. If I want the game to succeed and not get swallowed on the App Store then I need to step up my game in that department.

I have been doing a lot of reading about indie game marketing and have discovered [some valuable resources](https://vgamemarketing.com/). Its a massive daunting task but I have spoken to some other people who have done it and they have given me some great advice which has helped immensely.

So the next few weeks for me will be less about development and more about testing the game and building the things to help promote the game (websites, trailers, presskit etc).

If you would like to try the game out then as usual just [send me an email](mailto:mike.cann@gmail.com) if you are on iOS or [send a request to join this google group](https://plus.google.com/communities/100690884724496136044?gclid=CJSZo8WqgsACFVZwvAodlo0AHQ&dclid=CODB18WqgsACFVQZvAodWV4ATQ) if you are on Android and ill hook you up!

Well I have just finished off the first of [my three prototype games challenge](/posts/the-three-game-challenge/)Â ([part two](/posts/the-three-game-challenge-part-2-a-cunning-plan/), [part three](/posts/the-three-game-challenge-part-3-the-family-jewels/)) that I set myself last week.



For this one I started off with an idea that I wanted to make a time-based puzzle game. Well itÂ didn'tÂ turn out that way, alsoÂ somewhereÂ along the way I discovered an [Ebonics Translator](https://joel.net/EBONICS/Translator) so I decided I wouldÂ incorporateÂ that for a giggle.

[![screenshot_05](https://www.mikecann.blog/wp-content/uploads/2013/04/screenshot_05-300x226.png)](https://www.mikecann.blog/wp-content/uploads/2013/04/screenshot_05.png)[![screenshot_06](https://www.mikecann.blog/wp-content/uploads/2013/04/screenshot_06-300x225.png)](https://www.mikecann.blog/wp-content/uploads/2013/04/screenshot_06.png)

[![screenshot_07](https://www.mikecann.blog/wp-content/uploads/2013/04/screenshot_07-300x226.png)](https://www.mikecann.blog/wp-content/uploads/2013/04/screenshot_07.png)[![screenshot_08](https://www.mikecann.blog/wp-content/uploads/2013/04/screenshot_08-300x226.png)](https://www.mikecann.blog/wp-content/uploads/2013/04/screenshot_08.png)

Anyways see what you think:

[Play Latesha's Crib](/projects/latesha)

In total I spent 31 hours over the last week making this over the past week:

26th March
3pm - 5pm

27th March
10am - 12pm
1pm - 5pm

28th March
10am - 11:30am
3pm - 8pm

29th March
2pm - 5pm

1st April
2pm - 6pm

2nd April
8am - 12pm
2pm - 3pm
5pm - 8pm

3rd April
9:30am - 10:30am
12:pm - 1pm

It was good fun tho I reached a point where I think I had sufficientlyÂ prototypeÂ theÂ game playÂ so it was time to move onto the next game :)

Let me know what you think. If people really like it then I may turn it into a full-blown mobile game!