New Beginnings 🌱


Welcome to my tech blog!

For those of you who’ve been here before, welcome back ☺️

I originally started this blog to document my journey into the wild world that is the tech space 🚀It was a lot of fun, and I loved coming up with ideas for new posts, but at some point (about 2 years ago) life got busy and I stopped writing. I was still spending time in cafes, working on different devsign projects, but it wasn’t quite the same as when I was publishing regular updates.

A couple very different stars aligned in the last months to put me back on the right track.

  • 📦I moved, to an inspiring and cozy apartment, reminiscent of the place I lived when I started the blog. Like clockwork, moving always makes me question my life choices, and introspect in ways that I’m not used to. I also started taking long walks! 🥾
  • 💔I’m recently single. At first I thought this was an off-topic thing to mention, but as a result I now have way more time on my hands. This of course means more introspection, and just generally being able to reorganize my life in a way that focusses fully on myself for a while.
  • 🐍Michelle Akin🦡, my life coach from years ago when I was still in college, started a new accountability program around creative projects. Well, guess who has some creative projects that just happen to be stalled? 😄

As a result of all that, but especially the third point, I’m now rebooting the blog, with the objective of writing a post a day, for the next 13 days. Short-term, my primary goal is to revive a vehicle to keep my projects moving. The cafes are closed and will likely stay that way for quite some time. I need to build new, more resilient habits.

I had a hard time picking a creative project for Michelle’s program, but in the end I looked back on some planning I did last fall for this year. My overarching goal for 2020 was, and I quote:

Finish what you’ve started. This gives future commitments and goals more power.

Hahahahhahahahaha :’) Goals in 2020? How cute 😂

But more seriously, I have this problem where I start bringing new ideas to life before wrapping up the old ones. It’s a common form of self-sabotage, and I think my life will be significantly better once I overcome it. Instead of just picking one half-baked project from the bin-of-partially-executed-ideas, I’d rather try to fix the issues that are causing that bin to fill in the first place.

I want to use this blog as a medium for some of my different creative outlets, namely design, programming, and drawing. The bulk of the content will be devsign based, with some of my illustrations sprinkled into the mix. Making content means emptying that idea bin. 🙌

My secondary goalis to show the more human side of the world of tech. I think it’s important to break the stereotype of the “nerd in the basement who stares at a screen all day”. The people in this industry who I respect the most are, above all, people. They have lives, hobbies, feelings, and passions, and they aren’t afraid to let that show because it’s not “on brand” or whatever.

I don’t think that daily blogging is sustainable in the long run, but for the sake of this challenge I’m going to jump-start things, then switch gears to a more reasonable pace later ⚡

So yeah, stay tuned, there’s going to be something new here tomorrow!

sprout emerging from the ground
coloured shapes

Meet Logike 🔵🔺🔶

This fall, I started building a puzzle app called Logike. It’s a game that focuses on building logic skills, and from a programming and design perspective, it’s also the most challenging project I’ve ever brought to fruition. There’s a lot to talk about, so I broke it down into a few parts 😉

TLDR: If you just want to try Logike, you can here!

The story

With few exceptions, most of the memories from when I was very young are faint at best. One such exception relates to when I was in Kindergarten. We had a lot of “free play” time, as you do when you’re 5 years old, and during that time we could chose from a whole bunch of different activities. Actual examples include: making necklaces with beads, taking apart old broken motherboards using pliers and hammers, or in the more educational department, puzzle games to develop logic skills.

My favourite game involved placing coloured shapes on a grid in order to satisfy a logical conditions on the supplied cards. They’d start out really easy and get progressively more difficult, to the point where they were no longer feasible for the average 5 year old. It was a lot like Sudoku, but the difference was that this game mixed and matched and layered many different and nuanced types of logic. Sudoku games can be solved with the same algorithm each time, whereas the one to solve this game was far more complex and varied.

child playing with legos

Here’s a picture of a kid playing with legos, which will be replaced with a picture of ME playing with legos, once my mom finds it 😂  
photo by Kelly Sikkema

Fast forward twenty years and I’m looking for a project idea to help me learn front-end. I don’t remember what made me think of the puzzle game I played as a kid, but it popped into my mind and I went with it! No-one seemed to have digitized the game, and I realized that through code there were ways to take it even further.

What it looks like

There are two major things that the app lets you do: solve puzzles, and build them. Lets start with the part where the fun happens!

Solving Puzzles

an easy puzzle

Logike’s tutorial puzzle.

Solving puzzles is pretty straightforward: each puzzle consists of a set of logical conditions, and it’s up to you to move coloured blocks onto the board so that all of the conditions will be true.

However, the conditions can become quite complex

The logical conditions for a moderately difficult puzzle.

The logical conditions for a moderately difficult puzzle.

Or downright difficult, like this one…

The logical conditions for a difficult puzzle

The logical conditions for a difficult puzzle

Instead of telling you where specific entities (the coloured shapes in this case) need to be, this difficult puzzle only tells you about entity properties (colours, shapes) that could apply to a slew of different entities!

For now, the logical conditions are:

  • Some entity or property is here.
  • Some entity or property is not here.
  • Some entity or property could be here.
  • Some entity or property is/isn’t/could be here relative to some other entity or property.

Additionally, the grids for the logical conditions can also be smaller than the puzzle board itself, meaning that a 2×2 condition could theoretically apply to one of 4 places of a 3×3 board.

Building Puzzles

As for the puzzle builder, it’s a lot less mature than the rest of Logike, but functionally it does what it needs to. Initially, I wrote all the puzzles by hand in one massive JavaScript class. It was great for prototyping, but it wasn’t ideal for production, so I refactored all of the puzzles into JSON files. This is what one logical condition looks like in JSON now:

one logical condition, in JSON

one logical condition, in JSON

Imagine writing dozens of chunks of code like this by hand, and trying to visualize a puzzle with them. It just isn’t pleasant, so I made a GUI (Graphical User Interface) that writes the JSON for you! 🎉

The builder puzzle

The puzzle builder.

I talked about entities and properties a bit earlier, but it’s really in the builder that they start to shine! By abstracting the different parts of the puzzles above, I realized that the code I was writing could be applied to far more than just coloured shapes.

In the first part of the builder, you can chose a different set of entities than the classic shapes, and you get to chose the size of the puzzle as well! Technically, there’s no maximum size for the puzzle, but it’s currently limited to a 5×5 grid until I smooth out the design to accommodate larger ones.

The logical condition builder.

The logical condition builder, being used with the “animals” entity set.

The most important part of the builder is the part that writes the logical conditions. Each one is comprised of a selector (the entity or property you’re referring to in the logical condition) and a grid filled with conditions. The tool lets you visually build each grid, and see the puzzle as it will appear when someone’s trying to solve it.

When you’re done building a puzzle, it’s time to name it and download it!

When you’re done, you come up with a clever name, rank the difficulty of the puzzle, and the download the resulting JSON. There’s currently no user accounts, or database to deal with storing user-generated puzzles, but this is a good first step. A teacher could technically build a bunch of puzzles and send them to their students, who can load them up on the puzzle selection screen.

Under the hood

In the past, I would go into a programming project head-first, and start coding immediately. While this would be great for my short term motivation (features being built, and fast), in the long run it led to depressingly messy code, and made for unsustainable projects. Logike was the first project where I actually took some time to work on the architecture, and boy did that pay off!

Part of the architecture for Logike.

Part of the architecture for Logike.

This planning allowed me to build the app in the most efficient way possible, given my current skill level. It also made it possible to shrink my puzzle files down to sizes measurable in bytes!

The whole thing is built in React, so it’s a mix of HTML, CSS, and JavaScript. Additionally, anything that isn’t part of the core application logic is JSON. All of this lives on a free Heroku server, at least for now.

As far as technologies go, there’s not much fancy programming witchcraft going on, but that doesn’t mean that the project itself is simple. There were a bunch of technical challenges that had very little to do with the tech used, the biggest one was making the code sufficiently generic.

I could have taken a bunch of shortcuts and just hard-coded everything based on the coloured shapes and left it at that, but then I’d be missing out on the chance to make a much more powerful too. So I ended up with a bunch of classes like this one:

// an Entity is the main element that is manipulated in the puzzle.
// it has properties, a name based on the properties,
// a common name which may differ from the name, and an image
// ex: red square, potato, JK Rowling

class Entity {
    constructor(commonName, properties, img) { = properties; // an array; = Object.values( => {
        this.commonName = commonName; // for display purposes ONLY
        this.img = img;

export default Entity;

With all this abstraction, consistent and meaningful naming becomes super important, and at a certain point collisions can occur between your app’s logic and the programming language’s reserved keywords and pattern names.

  • Entities could have been called objects, but Object is a pretty important keyword that’s part of JavaScript.
  • Properties could have been called parameters, or attributes, but parameters are found in JavaScript functions, and attributes are found in HTML tags. Technically, in React, props stands for properties, but no-one writes it out the long way, even in their code, so this was the safer option.
  • Selectors are used in CSS, but at least they behave the exact same way in Logike’s logical conditions, and it wasn’t a reserved keyword.

The second biggest challenge was validating the pure logic found in the puzzles.

This is a bit of code that validates whether an individual logic cell in the logical condition is being respected.

// returns false if the selector is found in a place it's not supposed to be. Otherwise returns true
    const validateLogicCell = (selector, ansCell, logicCell) => {

        var matchesSelector = false;
        // checks to see if the answer matches the selector
        if (selector === ansCell) {
            matchesSelector = true;
        } else if (selectorIsPartial(selector, entities)
        ) {
            matchesSelector = true;

        var selectorCanBeHere = false;
        if (logicCell == null || logicCell === "empty") {
            selectorCanBeHere = true;
        var selectorIsHere = false;
        if (logicCell === true) {
            selectorIsHere = true;

        if ((matchesSelector
                (selectorCanBeHere || selectorIsHere))
            // matches selector in specific cell, therefore the cell needs to contain true or null
                (!selectorIsHere || typeof logicCell === "string")))
        // doesn't match selector, therefore the cell must contain false or another selector
            return true;
        else {
            return false;

Does your head hurt? 😂

Validating that a blue circle is in the top-right cell is easy. Validating that and every other thing I’ve mentioned is a whole other story, and likely makes a terrifying looking flowchart!

How to try it

The puzzle app lives at and eventually at once I figure out how SSL works.

It works on desktop or mobile, though there’s some features that are restricted in the puzzle builder on iOS for the moment.

Let me know what you think, and if you make some cool puzzles be sure to share them with me! 😄

What’s next

What I’ve made so far is just the tip of the iceberg. I see a lot of potential with Logike, so I’d like to keep developing it.

Here’s the current to-do list, more or less in order:

  • Puzzle Builder design improvements
  • enable editing logical conditions
  • enable reordering logical conditions
  • Persistent save state after end of browser session (accounts + database?, Cookie?)
  • Ability to share puzzles without downloading/uploading.
  • JSON V2 (remove ALL duplicate data and add IDs to entities and properties instead)
  • more robust entity validation (unique names that aren’t based on properties)
  • Creating new puzzles
  • Tweaking old puzzles
  • improving entity set images
  • Fixing nasty iOS bugs
  • Fixing toast jitters
  • Improve test suite
  • Validation improvements (duplicate entities, more robust property selection)
  • Puzzle builder validation (to give feedback preventing impossible puzzles)
  • Ghost images to fix sizing issues
  • Design improvements to support large puzzles
  • Shuffle-able logical conditions
  • Onboarding flow
  • Entity set builder
  • URLs that lead to specific parts of the app (builder, specific puzzles, etc)
  • SSL

For now I’m taking a bit of a break from the puzzle app to work on Compass, but I plan on alternating between the two projects until I feel like Logike is pretty mature.

Phew! 😌 That was a lot!

Thanks for taking the time to give this a read, and I’ll keep posting updates here whenever I start chipping away at the next next Logike release 😊

Until then, keep being awesome! 🌠



So I was trying to add SSL to, because you need to use SSL to make the new .app domains work, and I accidentally added SSL to the blog! 

Hurray, I guess! 🎉


Web dev 1.0 – The Process 🌱✨👨🏼‍💻✨🌱

For the last 3 years or so, I’ve been immersed in the world of code. What started as a simple workshop to help me build an MVP for an app turned into a full fledged rabbit hole, and before I knew it, I was working for a kick-ass EdTech company and spending my weekends sipping and writing Java. I’ve learned a ton, but the journey definitely hasn’t been linear.

Learning to code during evenings and weekends is great, and got me a working prototype of my Android app, but it has it’s limits. No amount of passion or drive can replace putting in the time, and I wanted to find a way to learn more, faster, without necessarily going back to school.

It just so happened that at the same time that I was feeling this urge, Les Pitonneux, a non profit that helps people learn to code, had a new cohort for their Lab12 program that was about to start. I’d already done a series of Android workshops with them, and I’d gotten a lot out of it, so I figured it was worth a shot.

Lab12 is twelve week “un-bootcamp” for self learners. There are no classrooms, no lectures, and certainly no fixed curriculums. You start out with a goal, usually a specific project, and with the help of mentors and your peers you work towards it for the duration of the program. It’s good to have a sizeable amount of time to dedicate to learning each week as well.

In my case, I wanted to make an interactive logic puzzle, while using modern web development tools that are similar to what’s being used where I work. The puzzle is something that could be integrated into Netmath, but more importantly, the whole process would help me become more familiar with the possibilities and constraints that come with building web apps. Design that’s informed by development is more robust, so I asked to be able to dedicate some time in my usual work-week to learning JavaScript and React.

A mural near Notman House that I like. It’s kind of chaotic, just like that front-end programming landscape!

Lab12 was divided into 3 parts for me: ideation, knowledge acquisition, and building. First I needed to figure out what exactly I wanted to do. Yes, I wanted to build a puzzle app, mais encore? I needed to scope the project into something that was achievable in 12 weeks, and also map out how all of it would be organized and what technologies I needed to learn.

The learning part is tricky, because I found that this is where motivation can take a bit of a dip. Optimal learning happens when you build onto prior knowledge bit by bit, applying what you learn as you go along, but it can be tempting to just go out on a limb and keep learning a bunch of things that you aren’t going to use right away.

One of the resources I was using, Eloquent JavaScript, had some particularly thorny bits that, while fascinating, were utterly useless for the first development phase of my project. I read on a bit further than I had to, and during that week where the puzzle app wasn’t moving forward I felt a big dip in my energy. It’s a tricky dance to balance learning and progress, but when you get the mix right it feels almost magical!

Dance magic dance!✨🕺✨👨🏻‍🎤✨💃✨

I spent a little over a month learning quite intensely, then came the building phase. There isn’t a ton to say about it other than the fact that it’s one of the most rewarding phase of any project. It’s when your planning and learning finally come to fruition, and you prove to yourself that you can do more than just follow along with a tutorial or copy/paste Stack Overflow. This is where I usually show off what I can do on Twitter. 😂

(By the way does anyone know the proper punctuation of emoji in a sentence? Do they replace the period, or go before/after it?)

At the end of the 12 weeks, I had a working prototype that was actually pretty fun to use. There were a few bugs in it, as is the case with most software, but nothing particularly worrisome. Setting aside the extra time to code made a huge difference and gave me a nice boost of momentum for my learning goals. I’ve taken the puzzle app even further as well, by making a puzzle builder, but that’s a whole story in itself!

I guess the takeaway is that if you feel like you’re in a bit of a rut or you’ve hit a plateau, there’s probably a way to fix that and take your game to the next level. In the immortal words of Enrique Iglesias, Baillamos! 💃


Something wonderful has begun 🚀

After a few months making puzzles, I’ve officially started working on Compass again! This time however, I decided to do things right and actually plan a bit before I code! 😅

post-its mapping out the inner workings of compass

Mapping out the inner workings of my app.

When I was building the puzzle app, having a clear map🗺 was invaluable. Instead of wasting time questioning my architecture, I was coding it, and checking off boxes in my diagrams as I went along.

I could also show others how my app worked, without diving into the code itself and being like “see this function? It does X… that class lets you talk to Y… what do you mean you don’t understand?! THERE ARE COMMENTS!

the architecture of the Logike app, mapped out with sticky notes

The architecture behind the Logike app

I currently have a love/hate relationship with code architecture. On one hand, I just want to hunker down, learn Typescript, and spit out my gem💎 in the making! On the other, it feels a lot like a game of Risk or Ticket to Ride, and I love a good strategy game.

By mapping out your project, you can be very strategic about the code you write and avoid going back and changing the same lines every couple weeks. Obviously no path is perfect, but it feels really cool to be able to make and educated guess about which one is best, something I definitely wasn’t able to do a year ago! 🎉