DEV Community: Nimmo

A monad is a thing you put things in so you can do things with them.

Nimmo — Sun, 03 Apr 2022 10:15:08 +0000

You can skip reading this post now, if you like - it's all there in the title. But if you want to hear a little more, okay, I won't deprive you.

Think of a time when you've needed to process some inconsistent data. You won't have to think very far before you realise that you've had to do this any time you've had an optional/nullable value somewhere - something in JS that may or may not be truthy, something in Java that may or may not be null, something in Haskell that is a Maybe something.

Let's say in JavaScript, I have an array of values (things) which I know may include undefined values.

const myJsArray = 
  [value1, value2, value3]

Now I want iterate over (do something with) this array.

const double = x => x * 2

const myNewArray = myJsArray.map(double)

You probably don't want to end up with an array that contains a series of NaN values; you already know that that's the first step on many paths that can lead to confusion for your users.

You've got your things, and you want to do something with those things

So what do you need? A thing you put those things in, so you can do something with them. You need a monad!

Earlier I mentioned Haskell's Maybe type. This type can store one of two variants: Just something, or Nothing. This means that even if you can't be sure whether something contains a value or not, you can still perform consistent operations anyway - the operation that you're trying to perform is required to handle what to do in either scenario, and then you can't end up with unexpected junk data somewhere else in your application. Or to put it another way - you know you can do the thing you wanted to on your thing because it was in a thing!

Why did I write this?

I've heard lots of different explanations of monads over the years. People tend to like using fancy words in their explanations, and I've seen lots of people shy away from Functional Programming altogether as soon as someone has mentioned monads to them. In fact, the Elm community doesn't even like to say the word monad (opting for Custom Types instead, which I agree is a simpler term), because it is so commonly linked with unnecessary confusion.

Google "What is a monad?" and you'll probably see the same thing explained in lots of ways, but I bet none are quite as simple as the explanation you read before even reading this post. Although if you happen to get this post in your results...you're now also one step away from understanding recursion.

Elm: A short example of the development experience on a real code change (video)

Nimmo — Wed, 23 Dec 2020 16:46:00 +0000

I love working with Elm, but it can be hard to explain what the development experience is really like compared to JavaScript-based tools. I thought a short video might help.

Take a day off

Nimmo — Sat, 21 Nov 2020 18:12:52 +0000

I'm usually pretty good at knowing what I do and what I do not give a fuck about, but recently the lines have been a little blurred. Far too much of my energy has been spent on things that would ordinarily be in my "don't give a fuck" list.

Why have I found myself with a lack of patience?

Why have I found myself unable to sleep most nights?

Why have I found myself losing motivation?

Maybe the answer to these questions wasn't really important. But having taken a single day off last week to do things I genuinely love doing, I can at least tell you that a little perspective has made all the difference.

Perhaps you are in need of a day off too? My advice to you is: take it.

Deploy every Friday

Nimmo — Mon, 09 Dec 2019 11:07:01 +0000

Every Friday I see people on Twitter shouting about how it's #noDeployFriday. And every Friday, I deploy to production anyway.

Do I hate quiet weekends? Not at all. I moved to full continuous deployment because I wanted quiet days, evenings, and weekends.

I got here by moving to continuous deployment.

I once worked for a company that had a painful release cycle. Everything had to stop once a month, and everyone spent the period immediately afterwards fixing issues.

Once I was in a position to own my own team's pipelines I wanted things to be better.

I started out with continuous integration (CI). Every change that we made was automatically tested and compiled, and the team was automatically notified of the build result.

This saved the team a lot of time, but I wanted more.

Moving to continuous deployment (CD)

How could I be sure that everything was ready to go to production all the time? My work could be categorised in two ways:

1: Changes to pages that were already available to users

Feature flags were enough to ensure that these changes didn't prematurely become accessible to users.

2: Changes to pages that weren't yet available to users

I decided to extend this idea a little further here. I already had a mechanism in the application to denote available pages, so I extended that to enable/disable entire pages easily based on the user's environment.

Now I had everything I needed to turn on automatic deployments.

And everyone lived happily ever after, right?

Well, sort of. There were a couple of things that we hadn't quite accounted for:

1: You can still make mistakes, but now your users can see them

It only took one bug to accidentally put a page live. This taught me that I needed an extra safeguard.

I added automated tests to check the status of each page. This meant a small overhead when making a new page available to users, but eliminated the possibility of users accessing pages before they were ready.

2: Caches can trip you up sometimes

My application is being served by AWS Cloudfront, which is known to cache aggressively. I initially invalidated this cache manually, but this wasn't good enough after moving to CD. This was easily fixed by amending the pipeline to invalidate the cache every time it ran.

I deployed over 70 times last week alone without worrying how close it was to 5pm, or what day it was. It's scary to begin with, but it's worth it.

"#NoDeployFridays"? No thanks.

Things mentioned in this post

Feature flags

Easier paths to accessibility in Elm

Nimmo — Fri, 11 Oct 2019 16:19:45 +0000

Accessibility is a big topic. It covers all sorts of things that affect people in different ways, but it's also something we can improve with some minor changes. For example, take the following element:

Looks fine, right?

Well...not quite. This looks like a normal select input, but it's really a div and a span, both with an onClick handler, as well as a span that has the same onClick handler.

The problem is that neither divs nor spans should have onClick functionality.

When someone types in this field the application suggests booking statuses as they're typing. These appear in a drop-down that looks like a select:

The user is presented with more divs containing suggestions, each with onClick handlers. What happens when you select one of them?

Now we have extra buttons: one for deleting the selected item, and one for deleting all the selected items. Would it surprise you to learn that these aren't buttons either? Spoiler alert: both are also spans.

What if all of the things that are pretending to be buttons right now really were buttons?

This basically looks the same, but it isn't. We've changed the placeholder text to reflect what was previously hidden functionality. The arrow is now a button, which can be understood by screen-readers. Awesome.

I can hear you now: "But I don't use a screen-reader". I'm happy for you and your sightedness. But did you know that making this a button instead of a span gives us keyboard controls for free?

I won't bore you with screenshots of the rest of the states this element can be in, but we've changed all of them to use buttons in the same way. Now every suggestion can be navigated through solely through the keyboard. The remove buttons can be selected in the same way. And it all looks exactly as it did before.

But you can use ARIA to solve this, right?

Yes, you can. But, your application will happily let you forget.

ARIA will help screen-readers understand that your elements are acting as buttons etc., but we should use HTML the way in which it was intended here. This is inherently understood by screen-readers as it has accessibility built-in by default.

That said, surely there's a way we can make this easier for people. Surely we can work towards accessibility being easier to implement. Surely we can make our applications accessible to the widest possible audience?

Enter: Elm's accessible-html module

Tessa Kelly is an engineer at NoRedInk. She has created an Elm module called "accessible-html" to solve this problem.

This module ensures that people can't accidentally write HTML that falls foul of accessibility rules. It achieves this by failing to compile if you accidentally do so, for example:

Here I've tried to call a div with an "onClick", but Elm's compiler has rightly pointed out that this is not possible.

Here's another example:

The compiler is telling me that the "img" function needs a String as its first argument. This is because accessible-html won't allow you to have an image without alternate text. This means that the image will always be described if it doesn't load for any reason, including for people using screen-readers.

Here, our own tooling makes us better engineers by actively teaching us the rules of accessibility.

Since this module extends the core HTML module, it is almost a drop-in replacement. The only things that need attention are where accessible-html's API differs from HTML's, as it does with the "img" function we've already looked at.

As I mentioned at the start of this post, accessibility is a big topic. We need to ensure we're considering it at design and implementation stages. Tools like this make it a lot easier.

Things mentioned in this post:

accessible-html

Tessa Kelly (Twitter)

ARIA

Some basic JS issues, and how Elm avoids them (Video)

Nimmo — Mon, 24 Jun 2019 08:59:33 +0000

State transitions (i.e. Elm messages/React actions etc.): Past or imperative tense?

Nimmo — Fri, 01 Mar 2019 09:41:17 +0000

Do you have an opinion over which helps either you or your colleagues reason about your applications better?

Past tense: DetailsUpdated
Imperative tense: UpdateDetails

Personally I'd always gone with imperative, but I thought about it recently and realised that whenever I'm looking at a list of state transitions things felt a little strange. For example:

Whilst this is easy enough to follow, it's hard to describe it without reverting to past tense anyway: The user started the game, the URL changed, the user changed rooms, the user toggled the inventory...

But this isn't the same when you're writing the code: "When a user opts to start the game, I want the game to start" etc.

So I'm interested: what do you use?

Optional chaining: What is it, and how can you add it to your JavaScript application right now?

Nimmo — Wed, 27 Feb 2019 16:40:51 +0000

This post assumes that you're already transpiling your JS applications with Babel (version 7+). If you're not, then this probably isn't the feature to convince you to add that into your build process, but it's still a proposed language feature that is worth being aware of.

You've seen these errors before, hiding in your logs, in your automated test readouts, in your console, in your devtools: cannot read property "map" of undefined.

You spend time tracking down the error, and find the function in question:

const someFunction =
  someArray => 
    someArray.map(someOtherFunction);

You spend even more time looking at the code that called this function. Sometimes that array really might be undefined. In this scenario you decide that it is someFunction's responsibility to handle that. You update your code, and leave a helpful comment so that no-one else wastes time wondering why you're accounting for this:

const someFunction =
  (someArray) => {
    // Sometimes this is undefined: See [link to bug report]
    if (someArray === undefined) {
      return [];
    }

    return someArray.map(someOtherFunction);
  }

This works. But, you kind of liked the implicit return from the original example. A single expression in a function makes you feel more comfortable. No way anything else can sneak in there and cause problems. I like your thinking.

You try again, with a single expression this time, using a default value:

const someFunction = 
  (someArray = []) => 
    // Sometimes this is undefined: See [link to bug report]
    someArray.map(someOtherFunction);

This works. But, now your helpful comment is a bit weird. Will someone think that the output of this function is undefined, and accidentally account for that possibility elsewhere, even though this will always return an array? You imagine the confusion you've potentially caused, and the accumulated (hypothetical) cost to your company as a result.

You could make your comment clearer, but you want to solve this problem using JavaScript, not boring words.

You could resign yourself to a ternary, but that would mean having to type someArray an extra time. Let's look at a new alternative:

Enter `optional chaining`

With optional chaining, you have a new operator: ?.

You can use ?. on anything that you think might be undefined, which can save you from the most common and the most frustrating issues you see regularly in JS. For example:

const withoutOptionalChaining =
  something
    && something.someOtherThing
    && something.someOtherThing.yetAnotherThing

const withOptionalChaining =
  something
    ?.someOtherThing
    ?.yetAnotherThing

It's crucial to understand that if either someOtherThing or yetAnotherThing are undefined, then the withoutOptionalChaining example will be false, where the withOptionalChaining example will be undefined.

As you're aware if you've written JS for anything more than a day, undefined is not a function. But, what if that didn't matter?

const someValue = 
  someObject.someFunction?.() // returns `undefined` rather than a runtime error if `someFunction` is undefined!

I'm in. But, how?

Fortunately, there's a Babel plugin for this: @babel/plugin-proposal-optional-chaining

Install that plugin with npm, and add it to your babel config via your chosen configuration option.

Depending on the rest of your Babel config, you may also find that you end up with an error about regenerator runtime not being defined. If so, you may need to add the @babel/plugin-transform-runtime as well, and configure it like so:

['@babel/plugin-transform-runtime',
  {
    regenerator: true,        
  },
]

If you're using ESlint, you'll find that it isn't too happy about this new operator. You'll also need to add the babel-eslint plugin to your ESlint config.

And that's it. Now you ought to be able to use optional chaining as much as you want to in your application.

Let's look again at that original code:

const someFunction =
  someArray => 
    someArray 
      // Sometimes this is undefined: See [link to bug report]
      ?.map(someOtherFunction)
      || [];

There we have it, another option for solving our problem. Do you always want to do this? Absolutely not: there are times when you probably do want a runtime error after all. But for the rest of the time, optional chaining is a great addition to your toolkit.

Disclaimer

Optional chaining is currently at Stage 1 in the proposal process, so whether or not you are willing to incorporate it right now is up to you.

Sometimes, in the heat of the moment, it's forgivable to cause a runtime exception.

Nimmo — Thu, 21 Feb 2019 01:32:39 +0000

Runtime errors suck. But when you're working in JS they're difficult to avoid. Fortunately though, our whole deal is problem solving; so avoid them we do.

For client-side JS this seems totally necessary: We shouldn't subject users to runtime exceptions; we should be giving them appropriate feedback in the event of an error.

But do we always want to avoid runtime exceptions at all costs? I'm not convinced.

In a perfect world, we'd have an equivalent to Elm's compiler in every language. But in the real world, we can save ourselves some time when things actually do go wrong.

Take this, as an example:

import someModule from 'someModule';

const {
  someObject: {
    someFunction,
  } = {},
} = someModule;

Let's assume that our code is being transpiled with Babel before it's deployed. In this instance, if someObject didn't exist in someModule, then this would transpile fine. But at runtime, someFunction would be undefined.

Uncaught TypeError: someFunction is not a function.

It seems like this code is destined to fail for one of our users.

Consider if we'd done it this way instead, without the default value in our destructuring:

import someModule from 'someModule';

const {
  someObject: {
    someFunction,
  },
} = someModule;

Now, if someObject doesn't exist in someModule we'll get a runtime error when trying to transpile instead of after it's been deployed.

Uncaught TypeError: Cannot destructure property `someFunction` of 'undefined' or 'null'.

Not only is this feedback much faster, but it's also going to fail on our machine. This particular example can only even happen in one place in any given file, which improves our ability to locate the problem quickly. With any sort of automated build pipeline in place, this error now can't even possibly make it to production any more. Not bad considering that all we did was remove three characters.

This example isn't indicative of every possible problem we can encounter in JS, of course. But this was a real example that I saw recently. It was the direct result of an over-zealous approach to preventing runtime exceptions: something that the original code didn't even do.

TL;DR: We ought to spend a lot more time thinking about how and where our code can fail, and we should be very careful to consider unintended consequences we introduce by trying to protect ourselves from errors.

Bothering people over [communication tool]

Nimmo — Tue, 19 Feb 2019 01:27:17 +0000

I've worked remotely for a couple of years, and I still find myself learning things about the practice.

I recently suggested to a colleague that I didn't like to "bother" people by asking them questions over Slack.

I described how much easier it was when working in an office; I could look and see if people seemed busy, and ask them whatever I needed to if they didn't.

Knowing that my message would result in a notification put me off sending it. I didn't know what that person was doing. I wanted to avoid disturbing them. This led me to "saving up" questions that I wanted to ask people.

My colleague told me that other people's management of their own notifications wasn't my problem. And she was right.

I had been wasting my own time by making a decision about other people's. Even my suggestion that it's easier in an office isn't true; asking "have got a minute?" in person is a much bigger interruption.

Perhaps everyone else has managed to figure this out for themselves, but in case anyone hasn't: Your colleagues are adults. They can manage their own time and alerts.

Ask the question and get on with your day.

"Can't we just...?"

Nimmo — Sat, 22 Dec 2018 16:34:58 +0000

Want to go to the moon? Just fly there.
Want to spend all of your free time doing whatever you like? Just quit your job.
Want to be in a band? Just start a band.
Want to write a blog post? Just write one.
Want to have steak for dinner? Just do it. Two minutes' work, done.

It's easy for most people to see why you can't just fly to the moon, or just quit your job.

But you may be thinking that you can just start a band.

It's reasonable to just write a blog post.

And anyone can cook a steak, right?

People don't like having their achievements trivialised. So why are we quick to trivialise problems that we need to solve?

Perhaps it's misplaced optimism. But the word "just" is a quick way to trivialise someone else's workload, or the tasks you're asking them to complete.

It's easy to accidentally increase someone's stress levels by telling them to "just do x". Consider these two questions:

"Can you just write a blog post on service testing?"

This tells the other person that you don't appreciate what you're asking them to do.

"Can you produce a guide on service testing?"

That's more like it. You'd never have asked Einstein to just prove atomic theory.

===

Further info:

The thing that made me think more seriously about "just" and its over-representation within our language at work was Evan Czaplicki's fantastic Strangeloop talk earlier this year, about the hard parts of open-source. I highly recommend giving it a watch.

A look at a small Elm application

Nimmo — Mon, 19 Nov 2018 22:38:21 +0000

One thing that I've found with Elm is that there are fantastic resources for learning how to start with the language, and there are equally fantastic resources talking you through a more complicated application architecture, but I think it might be useful to give people a more high-level view of what you're likely to find in an Elm application. Or at least, this is something that I think would have helped me, anyway - hopefully it will help someone else!

For anyone with absolutely zero knowledge of Elm: it's a functional language that compiles to JavaScript, and crucially does not allow for runtime errors. Anything that potentially could cause a runtime error has either not been included in the language, or is caught by the compiler, and results in nice friendly compiler messages instead.

Like this:

The Elm Architecture

Before we look at the code for this application, let's take a little detour into how the Elm runtime works.

The Elm Architecture is how application state managed in an Elm application. Your application has an overall model, an update function, and a view function. Your view function is capable of sending messages, which are fed into your update function along with your model, and this returns a new (updated) model, which is then used to render your new view. Diagrams for this make a lot more sense, so:

Anyone who is familiar with Redux ought to recognise this immediately (Redux was heavily influenced by Elm's state management), with some terminology changes. In short:

Elm	Redux
model	state
message	action
update	reducer

The key difference is that this is what the Elm runtime is built on, not something you opt-in to.

The app we're looking at

Project Arklay is a super basic text-adventure game that I've written a few times now in order to test out different tools or ideas or languages. Put simply, you (the player) navigate through various rooms, picking up items and unlocking doors, until you're ultimately met with an abrupt and disappointing ending.

Now that I've saved you the time of actually playing it, let's talk about it.

Application states

The application can be in one of three states (at the time of writing).

Either, you haven't started playing:

Or you have started playing, and the current available directions are being displayed:

Or, you have started playing, and your current inventory is being displayed:

Although these are three separate finite states, it's clear that the second and third are siblings in an overall parent view - so we have two views here. We'll refer to these as the Intro view and the Game view.

Original requirements

The player can: 

  In the Intro view:

  + Start the game

  In the Game view:
    When the state is Displaying Directions:

      + See which directions are available to move in
      + Select a direction to move in
      + Examine the room (this will pick up any items available in the current room, and add them to the inventory)
      + Open the inventory - so long as there are items in the inventory

    When the state is Displaying Inventory: 

      + See which items are available
      + Use an item
      + Close the inventory

How this is looks in the code

Going through this entire application line by line probably isn't going to be super helpful, but looking at the parts that have already been described should give you a decent taste for what working with Elm is like. It is worth knowing at this point though that all Elm applications will have a Main module, which will have a main function, and will be in a file called Main.elm. It's probably also worth knowing that every .elm file is its own module.

First of all, let's look at the application state - remember I said we had two views that made up our overall possible application states? Our overall application model is a record (which is similar to an object in JavaScript), which holds two things:

You don't need to worry about the "key" here - (it exists in order to allow us to navigate between different pages of the application whilst controlling what's displayed in the URL, and is generated by Elm's internals), but the state field is defined here as holding a State, which is a custom type. In this application's case, this looks like:

So the overall application state can be either ViewIntro (in which case it needs something that looks like whatever is defined as Model in the Intro module), or ViewGame (in which case it needs something that looks like whatever is defined as Model in the Game module). That takes care of two of our possible application states, and we said that the there were two possible states of our ViewGame state, so let's have a look at what Game.Model looks like:

Great, no surprises there then - Game.Model also has a state key, which also holds a custom type of State. It's worth noting that this is actually a Game.State, where the "State" that we looked at last was a Main.State.

Custom types can look a bit odd when you see them like this for the first time, so for a very quick clarification - a custom type in Elm is a type that can be enumerated. You could consider the way that Bool works as an example: it is a type that can either be True or False, and if you were to enumerate over it, you'd know in advance that you were going to be dealing with (at most) those two values. Our State here is no different. It could easily be a flag of "displayingDirections" with a boolean value, but I think there is a nice benefit of being able to look at the state here and quickly reason about what the possibilities are, which would be lost if this was a "displayingDirections" flag (since you wouldn't know what that being false would indicate).

How these states are rendered

Earlier I said that the view was rendered based on the Model, and we know that in this application the state is held in the model too, and we also know that State is a custom type, so it shouldn't be a big surprise to see how this all comes together in the code:

If that looks a little confusing, it might be because functions in Elm don't have parentheses around their arguments, every function in Elm has a return value, and every function in Elm is evaluated as a single expression. If the above were in JS, it would look something like this instead:

Although you'd be relying on state in the JS example being either "ViewIntro" or "ViewGame". In our Elm implementation, we know it is one of those two things, as those are the only things it can possibly be - so no need for a default in Elm here, which we would need in the JS version.

In the case of our Game states, only part of the view changes depending on Game.State, but it works in exactly the same way - in the part of the view that changes, there's another case expression:

How updates happen

I have a custom type of Msg which holds the possible message type in any module that has messages (this is something you'll see in basically every Elm app ever - very much the "standard" way of handling messages, since you're always going to be wanting to run a case expression on them).

There is an update function in our Main module, which is the one run by Elm's runtime. My Intro and Game modules also have their own update functions, and whenever an Intro.Msg or Game.Msg is received by the runtime, it gets piped into Intro.update or Game.update, allowing the message to be handled and the model to be updated correctly. This wiring isn't automatic, but it isn't especially complicated either - Main's Msg type looks like this:

The ChangedUrl and ActivatedLink messages are there because I need to supply the runtime with a message to call in the event of either of those things happening, but the things we're interested in here are Intro.Msg and Game.Msg. By this point you probably already know that we're about to look at Main.update to see what's happening:

So in the event of a GameMsg, we unpack the Game.Msg into msgReceived, and then we call Game.update passing in the message along with the current gameModel to get an updatedGameModel, which we then use to update our state to be ViewGame updatedGameModel.

Now if we look at that Game.Msg type, we can see what messages Game.update handles:

You won't be surprised to learn that this is all as you'd expect:

Item and Room are both custom types
ToggleInventory toggles whether the inventory is being displayed or not (by checking the current Game.model.state and switching to the other possibility)
UseItem stores an Item and a Room, and checks to see if the item in question can be used in the room in question (and uses it if it's possible)
ChangeRoom stores a Room and updates the Game.model to have that room stored in its Game.model.room
ExamineRoom may have an Item, and if it does, it adds it to the player's inventory. Otherwise, the inventory remains the same.

Okay, that last one is technically not quite true. It should have been:

ExamineRoom always has a Maybe, and that Maybe either has an Item or it has Nothing.

That might sound like a subtle difference, but this is how we avoid the potential headache of null or undefined - a Maybe can be enumerated with a case expression as well, and just like everything that can be enumerated in Elm, you have to handle all possibilities.

Let's have a look at the ExamineRoom function in Game.update:

If you're not familiar with Elm, this might look confusing to see all at once - remember that you felt the same way about whatever every other language you've ever used at one point too though!

What's happening here is:

I'm first checking to see if there's an item stored in the (Maybe Item) that is passed along with the ExamineRoom message
- if there is, I'm checking to see if the player is either currently holding that item, or if they've already used it.
- In either case, I want their inventory to remain the same, so I'm returning an identical copy* of the list that is stored in Game.model.inventory.
- If the player is neither currently holding the item, and they haven't already used it, then we're creating a new list of the current inventory, plus the new item. And then we're reversing it so that the new item appears at the end rather than the start - items are always added to the start of a list in Elm.
If there was no item to begin with, then I'm returning an identical copy* of the list that is stored in Game.model.inventory.

(*don't worry, the compiled and deployed code is using the value stored at the original memory location - but as every function in Elm returns a value, and values in Elm can't be mutated, we're conceptually returning an identical copy here)

And we can look at the functionality that was described at the start of this post, and see how it relates to the messages in Game.Msg:

Msg	Requirement
ToggleInventory	Player can open inventory
UseItem	Player can use an item
ChangeRoom	Player can select a direction to move in
ExamineRoom	Player can examine the current room

The requirements not covered by these messages are both to do with the player being able to see something (i.e. the available directions or their current items), and that's not a coincidence - things that a user can see are controlled Game.view and not Game.update.

(There is also a sole Intro.Msg of StartGame, which matches up to our other requirement, but it isn't worth talking about that here!)

One thing that I find especially useful with an Elm application is to look at requirements and work out whether something is the responsibility of update, and then add a Msg for it if it is.

Anyway, I hope that someone found this interesting - I know this hasn't been an especially deep dive into the language itself, but I feel like it should give a little flavour of how to look around an application to figure out what's happening with it. Personally, I'm always happy when I end up with something that is this easy to understand:

If you are interested, you can look at the full repo: https://github.com/dnimmo/project-arklay-v3 (things will change after this post is published, so the examples here may well be different in the repo than they are in this post - happy to answer questions on any of it mind, feel free to get in touch)

Or you can play the game itself in its still-could-use-some-styling-tweaks state: http://arklay.surge.sh