We were suffering from slow integration tests on our server when I discovered something that sped up performance by 15 times!



# TLDR;

Set `fsync=off` in your postgres config.

# The Problem

For our game [BattleTabs](http://battletabs.com/) run a custom sockets based API server. To ensure that the server is working as intended I like to write integration tests that hit the database. This gives a good level of confidence that calling that endpoint from the game client is going to work as expected.

The issue is that the tests were taking quite a while to run:

![](./before.png)

I narrowed the issue down to where most of the time was being spent:

![](./trunc-before.png)

We must truncate the database before each test runs so that there is no state from the previous test that can affect the results. The problem is that this truncate seems to be taking an inordinate amount of time.

# The Solution

After some googling I came across [this post](https://dev.to/thejessleigh/speed-up-your-postgresql-unit-tests-with-one-weird-trick-364p#:~:text=fsync,are%20physically%20written%20to%20disk.) which seemed to suggest that there was a magical config value `fsync` that I could disable which would speed things up.

So I set `fsync=false` in my postgres config and restarted my docker container and..

![](./trunc-after.png)

Wow! Thats a 15x speedup! Incredible.

So whats the downside? Well `fsync` ensures that changes are written (synced) to disk when Postgres makes a transaction. So by disabling it you are disabling protection from crashes power-cuts and whatnot so its [definitely not recommended in production](https://www.2ndquadrant.com/en/blog/postgresql-fsync-off-warning-in-config-file/) but when running tests we dont really care about data integrity so its safe to disable it.

# Github Actions

I wondered if it was possible to apply this sort of speedup to the CI which runs all the integration tests on each push.

To cut a long story short it appears you [cant supply config params to the standard postgres image while running in Github Actions](https://stackoverflow.com/questions/65438055/how-to-add-config-args-to-postgres-service-container-in-github-action/65444387?noredirect=1#comment115705280_65444387) but fortunately we can use another postgres image from Bitnami which does let us disable fsync.

```yaml
jobs:
  test-and-build-pr:
    runs-on: ubuntu-latest

    services:
      postgres:
        image: "bitnami/postgresql:latest"
        env:
          POSTGRESQL_DATABASE: postgres
          POSTGRESQL_USERNAME: postgres
          POSTGRESQL_PASSWORD: postgres
          POSTGRESQL_FSYNC: "off"
        options: >-
          --health-cmd "pg_isready -d postgres -U postgres -p 5432"
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
        ports:
          - 5432:5432
```

The result is a speedup of 3x, not quite as dramatic as the local speedup (probably because im running postgres in a linux docker container on windows locally and Github is running it on linux) but an impressive performance boost nonetheless!

We were having serious memory issues on the Heroku hosted NodeJS backend for our game [BattleTabs](https://battletabs.com) when we decided to apply "this one little trick"...



# TLDR;

Use [Jemalloc](https://github.com/jemalloc/jemalloc).

# The Problem

For those that aren't regular readers of this blog, for the past year my main focus has been a chrome extension game called [BattleTabs](https://battletabs.com). The game is based around the classic board-game BattleShips except you can play it in a Chrome Extension. This makes it rather unique as the game is immediately available every time you open a new tab in your browser. You can take a turn and move on with what you were doing or you can sit and play a longer session.

Because of the way the game works we keep a persistent socket open to our backend at all times. This allows us to keep the user's state in sync by pushing down updates from the server.

The game has grown considerably over the past 12 months and as a result the demands on the server have continued to grown. That coupled with the increased feature set has seen more and more open sockets and more required memory per socket.

# Vertical to Horizontal

We follow a pragmatic development strategy for the game, meaning that we only spend the time working on improving the infrastructure if its necessary. This meant that for 9 months we weren't really worried about server scaling or performance. We knew the issue was there in the background but whenever we needed more capacity we just bumped up the server size in Heroku:

![](./heroku-dyno-sizes.png)

Well unfortunately the day game when we were up to the largest size dyno and we were starting to see some issues again, it was time to do something about it.

The issue wasn't really that of memory at this stage, instead it was the number of simultaneous open sockets to a dyno instance. As far as I am aware there is no docs on what the max number of sockets is per dyno but [this](https://stackoverflow.com/questions/25118381/websocket-concurrent-connections-limit-on-heroku) stack overflow answer seems to suggest 6000.

We were definitely right up against that but at the same time because we are on node we are single threaded so we were also up against a CPU bottleneck trying to handle all the requests when the dynos go through their daily restart.

The time had come to go from a horizontal scale strategy to a vertical one.

We had been putting this off because horizontally scaling a websocket server isn't trivial. Fortunately we didn't have that much local-state and we were using [Socket.io](https://socket.io/) which has some good plugins to help with scaling. I wont detail everything we did here, feel free to contact me if you want details.

![](./socketio.jpg)

# Memory Issues

Now we could horizontally scale our server out to as many dynos as we wanted we should in theory be able to drop our dyno size back down to the smallest size (512mb RAM) and then just add more dynos as we grew.

The problem is, we seemed to still be using far more memory than we should have been given we were only running less than 1000 sockets per dyno. Worse still the memory seemed to be increasing over time indicating that there might be a memory leak somewhere.

After days of experiments and searching I decided to look a little closer at what socket-io was doing, thats when I came across this Github issue: https://github.com/socketio/socket.io/issues/3477

![](./mem-leak.png)

Others on the issue had done the hard work for me and instead of a memory leak they suggest memory fragmentation was the root cause of the problem.

This was a big "Ahhh!" moment for me as memory fragmentation would look a lot like a memory leak as your available memory over time would decrease as the memory became more and more fragmented.

There were two suggested solutions on the thread. I tried the first which was to disable "perMessageDeflate" on SocketIO. This had some effect but still we seemed to be using far more memory than we should have been.

So I decided to try the second solution too which was something I would never have considered; replace the system memory allocator in Node.

# Jemalloc

The other users on the Github Issue suggested trying [Jemalloc](https://github.com/jemalloc/jemalloc). I personally had never heard of it before but apparently its well known and popular with 5,500+ stars on Github. It describes itself as:

> jemalloc is a general purpose malloc(3) implementation that emphasizes fragmentation avoidance and scalable concurrency support.

Sounds like its exactly what we need, but how do I get node to use that? As with most things Heroku, someone has thankfully trodden this path before me and written a "Buildpack" which I can just plug into my app: https://elements.heroku.com/buildpacks/gaffneyc/heroku-buildpack-jemalloc

And the effect?

![](./half-mem.png)

Wow! It halved our memory usage! Incredible!

# Conclusion

We were able to scale our heroku server out horizontally and overcome a memory fragmentation issue in socket-io by replacing the memory allocator with Jemalloc.

We have been running like this for a couple of weeks now and have yet to see any issues.

I haven't tested this on non-SocketIO servers but I suspect so I cant say for sure but I suspect it would have a similar magical effect. I would be very interested to hear your results if you tried this!

After months of hard work we are excited to announce that our latest and largest ever update to [BattleTabs](https://www.battletabs.com/) is finally live! Read on to find out about some of the gory details.



# TLDR;

The video below gives you a taste of whats changed.

<iframe width="100%" height="400" src="https://www.youtube.com/embed/JNCD3PhP08w" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

# Ships and Fleets

The most important change in this update is the addition of Ships and Fleets to the game.

Previously the game was pretty much just [standard battleships](<https://en.wikipedia.org/wiki/Battleship_(game)>) except perhaps with the addition of the distance indicators on the cells if you miss:

<iframe src='https://gfycat.com/ifr/DesertedHonoredFluke?hd=1' frameborder='0' scrolling='no' width='100%' height='450px'  allowfullscreen></iframe>

<iframe src='https://gfycat.com/ifr/BlackandwhiteLoathsomeDairycow?hd=1' frameborder='0' scrolling='no' height='450px' width='100%'   allowfullscreen></iframe>

This was enjoyable enough but we always felt it lacked a little depth so after a lot of brainstorming and hard work from our designers we came up with the concept of fleets.

![](./select-a-fleet.png)

A fleet contains 4 ships which each have a [special ability](https://www.battletabs.com/how-to-play-battletabs-v2/) that they can use.

Some ships live in multiple fleets but they are carefully tuned so that each fleet has an play style.

For example the "Reveal & Snipe" fleet is high risk vs high reward fleet that revolves around discovering the location of the enemy ships with "Reveal" abilities then taking them out in one hit with the Coracle.

![](./reveal-and-snipe.png)

This adds some much needed diversity to the battles as you learn how each fleet works and what its strengths and weaknesses are against other fleets.

![](./example-battle.png)

One other strong part of this design is that it is an obvious point of extension where we can add more fleets and ships as time goes on, keeping the game interesting to loyal players.

# Tutorial

Because the Ships and Fleets is now quite a bit more complex we also decided to take the time and build a proper tutorial into the game.

![](./tutorial.png)

Previously we simply popped up a modal with a couple of short gif animations that gave you the general gist of how to play but we always knew that was a temporary measure.

The tutorial now guides you step by step through how to play the game.

<div style='position:relative; padding-bottom:calc(50.42% + 44px)'><iframe src='https://gfycat.com/ifr/ValuableIncomparableAfricangoldencat' frameborder='0' scrolling='no' width='100%' height='100%' style='position:absolute;top:0;left:0;' allowfullscreen></iframe></div>

# Sidebar

We know from our analytics that a large percentage of our users are playing on chromebooks or small windows laptops both of which have very limited vertical height. This meant that the play area they had was small and made smaller thanks to a bunch of vertical space eaten by our UI at the bottom of the screen:

![](./old-sidebar.png)

So we decided as a part of this update to overhaul the UI and move all of this to a bar on the left hand side of the screen instead:

![](./new-sidebar.png)

This not only looks a whole lot better but it frees up vertical space so that the thing thats most important (the game) can take up as much space as possible and thus isnt scaled down.

# Other Stuff

We added a whole bunch of other stuff as part of this update that I wont detail but some of which includes:

- New avatars for players
- Larger maps
- New emote UI
- New Logo
- New info modal on pinning the extension
- Screen shake effects
- Better in-game UI
- Some nice CSS animations
- Faster load times
- Better ship placement and rotation
- Countdown sound effect and better UI

# Conclusion

We are really proud of this update as we think it brings some much needed depth and polish to the game. Hopefully it also sets us up nicely for a bunch of future features we have planned so stay tuned!

If you want to checkout the game head over to: [https://www.battletabs.com/](https://www.battletabs.com/)

This is a technique my girlfriend I have have been practicing every day for years now so I thought I would share.



[Kelsie is a wellness coach](https://www.abetterme.com.au/) and so she knows a thing or two about good routines and techniques for being happy and productive. So when, a few years back, she proposed a routine to strengthen our relationship and make us happier, I thought "sure why not?".

The idea is pretty simple: at the end of the day you take it in turns to say one thing you have been grateful for during the day.

Its simple but quite powerful because it forces you to go through your day in your head and appreciate all of the awesome that happened. It sets you up in a positive mood before going to bed because there is nothing worse than trying to sleep when you are in a bad mood.

Its not a new technique by any means and "Gratitude Journal"'ing is often written about.

I have tried to start journals quite a few times before but always struggle with keeping the routine going. This technique however seems to have stuck with us.

Since starting however we have tweaked the formula a little. Instead of saying one thing we are grateful for we say "What was your highlight of the day?" and then we also say "What was your relationship highlight?". We call this our "Highlight Reel".

Adding the relationship highlight in there has been a great way to let the other person know that something they did or said during the day was very much appreciated even if it was only something small.

So thats it. I hope others find this useful like we do :)

Its no secret that im a fan of MobX and have been using it for many years now. I have even [written a couple of libraries](/projects/mst-libs) for its sister project MobX State Tree. So when I encountered [MobX Keystone](https://mobx-keystone.js.org/) I was intrigued..



## MobX State Tree

[MobX State Tree](https://mobx-state-tree.js.org/intro/philosophy) is a fantastic library that I have been using for some time to simplify state management in my various web projects. Its main premise is that all the state for your app should be contained in a single hierarchical "tree".

Although this sounds pretty much exactly like [Redux](https://github.com/reduxjs/redux) there is one major difference from Redux in that the state lives close to the code that modifies it and this state is is modified in a "mutable" manner.

Although you change state by assigning to variables and pushing into arrays you aren't actually mutating data. The underlying state is maintained as an immutable "snapshot" of the entire tree. Actions that modify the state produce new snapshots.

The benefits of having this "layer of indirection" from you and your state is that you can have functionality such as transparent references. References allow one part of the state to reference another part of the state but hide that underlying reference in the API. Its only when a snapshot is created or restored is that reference converted into a serializable "id" reference.

There are many other benefits of this way of working but I wont enumerate them all, the docs do a pretty good job of explaining that: https://mobx-state-tree.js.org/concepts/trees

## MST Problems

MST although awesome is not without its issues. [This](https://medium.com/@xaviergonz/mobx-keystone-an-alternative-to-mobx-state-tree-without-some-of-its-pains-8140767a3aa1) excellent blog post by Javier Gonzalez does a great job at detailing those points but ill summarize here:

1. Typescript in MST is "best effort" ([according to the official MST docs](https://mobx-state-tree.js.org/tips/typescript)). So although it does mostly work there are really frustrating situations where you can loose typing particularly when you have types that reference other types that then reference the first type again (circular references). MST really struggles to handle this case because it relies heavily upon type inference. This inference also leads to rather slow Typescript compile times and large declaration files.

2. Snapshots and Instances can get confusing because they are used interchangeably, this also is another source of problems when using Typescript.

3. "this" and "self" within MST models. You have to choose which one you need depending on the situation. This is again another Typescript issue due to the way that MST types its modular models via type inference.

4. MST's lifecycle hooks are temperamental. MST has a [number of life cycle hooks](https://mobx-state-tree.js.org/overview/hooks) that allow a model to run code when a model is attached or detached from a tree. Unfortunately these dont always function in the way you expect particularly when you throw references into the mix.

## MobX Keystone

[MobX Keystone](https://mobx-keystone.js.org/) is very similar to MST conceptually but it implementation differs in some key ways allowing it to overcome many of the problems encountered in MST.

1. Keystone's [models are classes](https://mobx-keystone.js.org/classModels) rather than modular functional "chunks". Typescript has great support for classes even in recursive or circular scenarios. This is great for building complex interconnected models. It also solves the "this or self" problem listed above as its always just "this".

2. Keystone's [references](https://mobx-keystone.js.org/references) are objects in themselves rather than direct instances of another model. This indirection allows for more flexibility in how models reference each other. This opens up lots more possibilities when you have multiple trees for example.

3. Runtime type checking is optional. In MST you were forced to use the "types" object to enforce types in your model, in Keystone is this optional. This can make things a good deal simpler if you are happy just to rely on the Typescript compiler and don't want the overhead of type-checking at runtime too.

## Keystone Problems

1. Keystone's [snapshots](https://mobx-keystone.js.org/snapshots) contain some "meta" information such as the "type" of the model and the "id" of the instance. I understand the reason for this requirement having worked with generic serialization libraries in C# and other languages before, its necessary that the system know the type of object so it can correctly construct an instance of it.

MST doesn't have this issue because it enforces the runtime types and the precise structure of the tree thus in most (not unions) situations it knows what the type the data represents.

I haven't played with them much but the [functional models](https://mobx-keystone.js.org/functionalModels) that Keystone offers may help if this is a big problem for you.

2. Immutability / Mutability.. This is a tricky one and a problem that both MST and Keystone have and I guess all OO based state management suffer from. When working with MST or Keystone I find that the models tend to pollute my immutable data models. You can construct an object using a property from an MST or Keystone model but you must be very careful because those models by their nature are mutable thus the newly constructed object too becomes mutable. This another with another [issue](https://github.com/xaviergonz/mobx-keystone/issues/170) has bit me in the past so you have to be super careful when mixing immutable and mutable data, always snapshot!

Im proud to announce my latest project: Joshua Christopher Cann :)



<iframe width="853" height="480" src="https://www.youtube.com/embed/dYXdt841q1Q" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

He was born yesterday at King Edwards hospital in Perth Western Australia. It was a planned c-section birth and everything went smoothly and without problems.

The mother and my girlfriend Kelsie was incredible throughout it all and despite having some pretty bad nausea from the cocktail of drugs she was able to feed him and make it through the day just fine, I couldn't be more proud of her.

![](./kelsie-me-baby.png)

They will be hospital for 3-5 days while she recovers from the major surgery, then finally home to start our family life together, I cant wait :)

[![](./josh.jpg)](././josh.jpg)

I have generally steered away from building open-source libraries mainly for selfish reasons (I didn't want to spend the time maintaining them) but I decided that the current work I was doing would benefit from input and improvement from others and so I decided to release two things as libraries and im really happy with how things went.



Both libraries are for MobX State Tree (MST) [which I have been using for quite some time](/posts/markd-2-total-re-write-using-react-mobx-state-tree-and-parse-server/) now. Its a fantastic library for managing your state in a clear and concise way tho there are some gotchas with parts of it. These libraries try to help with some of those gotchas and thus increase reliability when using MST.

# MST Flow Pipe

https://github.com/mikecann/mst-flow-pipe

This is a helper library for writing type-safe async code in MobX State Tree.

I wont go into all the details of how this one works, you can click the link above to read the readme. Briefly tho I felt that MST's async story was a little lacking when combined with Typescript so set out to improve it with this library.

I first talked about it on [this issue](https://github.com/mobxjs/mobx-state-tree/issues/1516) which prompted me to release the lib.

My first version had some corner cases that didn't work quite right but thankfully [@lorefnon](https://github.com/lorefnon) picked up from where I left off and submitted [a PR](https://github.com/mikecann/mst-flow-pipe/pull/1) which greatly improved the library. Now it works fantastically, is infinitely expandable and handles errors in an elegant way.

Im really happy with the state of the library and I think the concepts could be borrowed and used in other libraries that use JS-generators instead of JS-promises such as [redux-saga](https://redux-saga.js.org/).

# MST Log

![](./mst-log-screenshot01.png)

A console logging middleware for MobX State Tree

This one came about after some work with Redux and [redux-logger](https://github.com/LogRocket/redux-logger) which beautifully shows actions and state changes as groups in the console window. I thought this was really cool and couldn't find anything comparable in the MobX State Tree world so [I posted on the Spectrum group](https://spectrum.chat/mobx-state-tree/general/a-good-logger~206ccd36-527b-4f09-b7f0-fcbef90b407d) about it to see if anyone else was interested in it.

MST has some conceptual differences from Redux so some of the choices I made around nesting and grouping async calls may not be 100% correct. Im hoping that others will point out issues and help contribute to make it better. So far tho I am using it on our [BattleTabs](http://battletabs.com/) project to great effect.

After months and months its finally done! My 6-sided 24,576 LED self-contained cube project is finally complete!



Instead of writing a massive blog post for this one I instead have decided to experiment and have produced a Youtube video instead. I think it probably works best for this particularly visual project.

So without further ado, sit back and enjoy the next 22 minutes of me talking about this; my most complex hardware project yet!

<iframe width="853" height="480" src="https://www.youtube.com/embed/l_GSGFhnWwo" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

This blog has been going for a long time and in the early days it was a mixture of Personal updates and technical updates.



Lately tho its become more technical and less personal as I have usually contained my personal updates to my [Facebook Profile](https://facebook.com/mikeysee) and my [Instagram Account](https://www.instagram.com/mikeysee/).

But I thought its okay to do a personal update every now and then and theres been some major milestones happening in the life of Mike Cann of late..

# Mike The Australian

Well I cant remember if I ever actually blogged about this but 6 years ago I moved to Australia to be with my beautiful girlfriend Kelsie who lives here. Well a lot has happened in the intervening years and as of a few months ago I am now official Australian Citizen :)

![](./citizenship.jpg)

# Mike The Outdoors Enthusiast

I have fully embraced the Australian lifestyle and now make the most of every opportunity I can to get outside and do various activities.

My current passions are Kitesurfing, Freediving and Electric Skateboarding :)

https://www.instagram.com/mikeysee/

<iframe src="https://www.facebook.com/plugins/video.php?href=https%3A%2F%2Fwww.facebook.com%2Fmikeysee%2Fvideos%2F10157700052541031%2F&show_text=0&width=560" width="560" height="315" style="border:none;overflow:hidden" scrolling="no" frameborder="0" allowTransparency="true" allowFullScreen="true"></iframe>

<iframe width="560" height="315" src="https://www.youtube.com/embed/eU--BOB6owA" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

<iframe src="https://www.facebook.com/plugins/video.php?href=https%3A%2F%2Fwww.facebook.com%2Fmikeysee%2Fvideos%2F10158156960906031%2F&show_text=0&width=476" width="476" height="476" style="border:none;overflow:hidden" scrolling="no" frameborder="0" allowTransparency="true" allowFullScreen="true"></iframe>

# Mike The Father (to be)

Last but not least in December we had some incredibly special news that I am to become a father for the first time.

Its a boy and its due in early June and I couldn't be more excited / apprehensive :)

![](./baby.png)

Ever since I [built my own smart mirror](/posts/mikes-mirror-the-talk) back in 2018 I have been keen to do another hardware project...



# TLDR;

This is what I ended up building:

<iframe width="853" height="480" src="https://www.youtube.com/embed/PWc4lJeD_T4" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

# 31st October 2019

I started looking around for other cool electronic projects I would like to work on. Theres tons of cool project ideas on https://hackaday.io/ and https://www.adafruit.com/. I recorded all my favorites on a Trello board:

![](./potential-projects.png)

I wanted to do something really ambitious but decided to be safe I should probably start with something a little smaller then if it goes well try the larger thing (more on that later).

So the final choice was this awesome LED Matrix toy project from Adafruit: https://learn.adafruit.com/matrix-led-sand/overview

I liked it because it looked cool and had a good guide and all the components were easy to get hold of.

# 1st November 2019

I ordered the parts from various places. Most of the Adafruit stuff I bought from [Core Electronics](https://core-electronics.com.au/brands/adafruit-australia) who are the official retailers of Adafruit components.

Unfortunately Core Electronics didnt have the LED Matrix so I decided to source that myself from a [Ali Express](https://www.aliexpress.com/). It turns out there are tons of different versions from lots of different manufacturers. In the end I chose [this one](https://www.aliexpress.com/item/32650789975.html?spm=a2g0s.9042311.0.0.e86c4c4dfwYIzu) as it looked close to the Adafruit one, had good reviews and was priced okay.

![](./matrix-purchase.png)

# 4th December 2019

The LED Matrix finally arrived from China. This was the last item I needed so I could start the build.

![](./matrix-arrived.png)

# 10th December 2019

I started following [the Adafruit guide](https://learn.adafruit.com/matrix-led-sand/overview), I first got the software running on the Raspberry Pi Zero W.

Because I thought I needed to see the screen to setup the Pi, I bought a cheap \$50 monitor from Gumtree then plugged in a spare keyboard and mouse. It turns out I neednt have bothered but more on that laters.

![](./installing-software.jpg)

The software process was rather simple thanks to the scripts provided by Adafruit.

# 13th December 2019

I started to solder some of the components together roughly so I could test the hardware. As before I followed the Adafruit guide which provides this very handy circuit diagram:

![](./circuit-diagram.jpg)

It was at this point I realized I had made a mistake. I had ordered the [Adafruit Powerboost Basic](https://www.adafruit.com/product/2030) rather than the [Adafruit Powerboost Charge](https://www.adafruit.com/product/2465).

The only different between the two I think is that the Charge is able to charge the Lipo battery as well as output the power at the correct voltage.

The wiring was a little different between the two however and I was worried about blowing something up. Instead I decided to order a Charge from Core Electronics.

Fortunately I could continue for now as I had a power supply that would work directly with the Adafruit RGB Matrix Bonnet. The whole thing would just have to be tethered to the power socket for now.

So after getting everything connected and powered on to my surprise it actually worked!

<iframe width="853" height="480" src="https://www.youtube.com/embed/h4k6GrrQxe4" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

I couldn't believe it. I was totally expecting it just to not power up or the matrix not to light up or something but it just worked. Awesome!

# 14th December 2019

I wanted to see if I could get the handles and other mounting brackets 3D printed.

![](./3d-parts.jpg)

I downloaded the SDL files supplied by Adafruit and went over to a mates place who owned a 3D printer.

![](./json-print.png)

Unfortunately we couldnt get his printer to print correctly so I gave up on that and instead decided to try to print using a third party printing service.

# 7th January 2020

I joined [Thingiverse](https://www.thingiverse.com/thing:2808127) and found a third party company that could print my parts relatively cheaply.

# 26th January 2020

I received an email from my printer saying they couldn't do it for the price they had originally quoted. Sigh.

# 29th January 2020

I decided to contact a few local 3D printers here in perth using Gumtree. I got a good quote from someone within an hour and they immediately started printing.

# 30th January 2020

My 3D print was ready to collect already! I drove over picked them up, they looked great.

![](./printed-parts.png)

There was one small issue however... If you remember back to the start, I decided to buy an LED matrix myself from a different supplier than Adafruit. Well it turns out that the spacing for the screw holes on the back of the matrix are 10mm wider on mine than the Adafruit one.

![](./spacing.png)

So unfortunately none of the holes lined up.. Sigh!

# 8th February 2020

I tried to edit the 3D printing files but I didnt really know what I was doing in Blender so instead I had an idea. Instead of spending ages learning how to use a 3D package and then paying to get them reprinted I could instead bodge it!

So I went off to Bunnings and bought a drill and some 3mm MDF.

![](./mdf.png)

I then proceeded to do a bit of sawing, sanding and drilling..

![](./sawing-sanding.png)

Then hey presto I had a working bodge!

![](./bodge.png)

So now all that was left was to assemble everything together.. Or so I thought..

![](./snapped-sd.png)

Somehow I had managed to snap the SD card while I was doing all this. Fortunately I had a spare one but it was rather annoying.

This time around however rather than getting the monitor, keyboard and mouse out again I found the IP address for the Pi using a very handy iOS app called [Fing](https://apps.apple.com/au/app/fing-network-scanner/id430921107). Once I had the IP address it was just a simple matter of SSH-ing in and running a few scripts provided by Adafruit once again.

After testing everything once more I was happy to get everything assembled.

![](./assembled.jpg)

Huzzah! It all worked! (See the start of this post for a demo video)

# Conclusion

I am really happy with the final result despite a bodge or two. The only thing that is kind of annoying is that somewhere along the line a small strip of the LEDs decided to stop functioning :(

![](./oops.png)

Oh well, its not a big deal, im just happy that I managed to finish it. I can replace the matrix later if I want to.

I think over the next few weeks I might have a go at writing a game or something for it, would be cool to take advantage of those buttons for something other than changing the demo.

I mentioned earlier in this post that I had a more ambitious project planned.. Well I think this project went well enough that I think im going to tackle it so stay tuned for that!

Back in August 2019 I have a talk at the local [Front End Web Developers (Fenders)](https://www.meetup.com/Front-End-Web-Developers-Perth/) meetup group here in Perth. Its taken them a little while but the talk is finally up on Youtube!



# The Talk

<iframe width="853" height="480" src="https://www.youtube.com/embed/OFKYo8lvS7E" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

As you could probably guess if you had looked at my past few years worth of posts on this blog I have been using Typescript on a daily basis and I am really impressed with the power of the type system so I thought I would try to share some of that fascination with others in Perth.

I was really nervous about giving the talk even though it was only short and only to a small (~150 people) local meetup.

![](./us.jpg)

Despite doing it all as a live-coding with audience participation I think it went okay tho im not sure how many people followed along as it it was quite dense.

Everyone seemed to enjoy the game at the end though so perhaps I should have made that the focus of the talk, what do you think?

2020

Archive

2020

Archive

2020

Archive