
It's been 6 months since [I last wrote about BattleTabs](/posts/battletabs-ships-and-fleets-update) and so much has happened and so many things have changed I felt it was time to do an update.

# 6 Months Ago..

.. We had [just released](/posts/battletabs-ships-and-fleets-update) the ships and fleets update which was by far our biggest update to that point. For the first time we introduced the concept of ships that have abilities and are grouped into fleets. This fundamentally changed the game from what was essentially just Battleships into its own unique experience.

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

In the same update we added a proper tutorial and gave a UI a much needed overhaul.

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

# Whats New

Since then we released a whole heap of new features and improvements over a total of 35 updates!

Some of the biggest new features include:

- New version for web (https://battletabs.io)
- Battle Club, our paid subscription feature giving the player access to exclusive ships fleets, avatars backgrounds and lots more.
- BattleTabs Live, a discord bot that announces major events in the game.
- A user profile modal for viewing states and auth data
- A new authentication system so you can signup and login with socials
- A new "Update Available" / auto update feature
- Private proposals so you can send invites to each other via links
- A bunch of new fleets and ships

[![](./fleets-list.jpg)](./fleets-list.jpg)

# Some Numbers

Players seem to enjoy the regular updates and improvements. The number of matches created per week has steadily increased to the point where almost 70,000 matches are created per week:

[![](./matches-created.png)](./matches-created.png)

Thats over 300,000 turns taken per day!

[![](./turns-taken.png)](./turns-taken.png)

# Discord

We also launched a [Discord Server](https://discord.com/invite/kvJKXsu) in the last 6 months which has seen surprising growth to over 8,000 members.

[![](./discord-memberships.png)](./discord-memberships.png)

At any one time we have hundreds of members online chatting away in the various channels. Its awesome to see such a fantastic community grow around our little game.

Brandon, my co-founder, has been busy running community tournaments which have proved incredibly popular garnering far more sign-ups than there is space for.

[![](./tourny.png)](./tourny.png)

# Under The Hood

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

As you can imagine with all this growth comes some technical challenges.

## Scaling

In the past 6 months we have had our work cut our for us scaling the backend. Its a challenge as the game uses stateful sockets for communication which complicates the usual "stateless" servers mantra.

Our solution has been to use a combination of careful horizontal scaling of client facing nodes which communicate via a shared custom redis pub-sub mechanism.

Since launch we have run most of our infrastructure on Heroku which has been great for for rapidly getting us to were we are today but its scaling is a little lacking. For now it works but theres plenty room for improvement in the future.

## Client State

Recently we also changed the way state is managed in the client over from [MobX State Tree](https://github.com/mobxjs/mobx-state-tree) (MST) to just [MobX](https://mobx.js.org/README.html). Although [I am a fan of MST](https://mikecann.blog/posts/mst-libs) we have found that it unfortunately doesn't play very well with Typescript once your store reaches a certain size.

MST relies on a lot of type inference and union types and if you have been around Typescript for a while you will know that this specific combination of characteristics can quickly lead to a combinatorial explosion of types causing slow compile times and a poor IDE experience.

With MobX things are simpler as state is split between multiple stores defined as classes. This means Typescript doesn't have to work so hard calculating what the type of something should be at any given time.

We do give up some nice MST features such as time travel debugging, undo-redo and state managed purely in the background page but we either weren't using those features or we would have had to stop using them for [manifest v3](https://developer.chrome.com/docs/extensions/mv3/intro/) regardless.

## Monorepo

[![](./monorepo.png)](./monorepo.png)

We changed the way we code to move from a multi-repo approach to a single monorepo approach. This was done to simplify dependency management between the various parts of the system and simplify the versioning story.

This definitely makes things much simpler to understand when you have more than one person working on the codebase at once.

# Future

Theres so much more we have planned both from a feature standpoint and technically. I cant share too much right now but its super exciting so stay tuned!

If you want to play the game you can [download the extension](https://chrome.google.com/webstore/detail/battletabs/mjcklhnhfiepmofggcoegkmkokbljmjd) or play right now on http://battletabs.io/


A couple of months ago my [Markd](https://markd.ltd/) co-founder [Brandon](https://www.linkedin.com/in/theBrandonWu) came up with an great idea for a new app, we mulled it over, ran a few experiments and decided to build it, thus [Howdy](https://howdy.page/) was born.



# TLDR;

Howdy is a service for sending short personalized video messages to one another.

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

# Concept & Testing

[Brandon](https://www.linkedin.com/in/theBrandonWu) pitched the idea to me a couple of months ago as a service for people who get too many emails. The idea is that those people can sign up to our service, put a link to their own private "page" in their email footer or auto-responder and have others send them personalized video rather than more emails.

One of the key concepts for the service was that the messages should be personal and so shouldn't be pre-recorded, that is they must be recorded on the spot and must be short (no more than 1 minute in length).

[![](./record-60.png)](./record-60.png)

We were unsure if the idea was good enough to spend the time on development so we decided to run some ad tests. This is a process that Brandon knows a great deal about more than me but the general-jist is that you spend a small amount of money on ads that point to a targeted landing page. You then analyse the resulting analytics to determine if the pitch is good and which target market might respond the best.

After we ran a bunch of different ads we had enough data to confirm that the idea was good enough to spend the 3-4 weeks of development on to get an MVP launched.

# Development

Although we tested the idea with ads we knew that we didn't want to spend too long coming up with the "perfect" technical architecture for something that still might not work in practice.

So I chose my preferred weapons of choice at the moment for rapid iteration; a Typescript-React frontend hosted on Netlify with Postgres-Node backend hosted on Heroku.

[![](./heroku.png)](./heroku.png)

Development was swift and within a week or so I had a working prototype up on our "staging" server where we could send messages to each other.

We decided that for this product we wanted to have payments in from the beginning. We chose Stripe as our payments platform and it took me a week or so to get that implemented into the app with tiered subscription levels. I hadn't used Stripe before so it took me longer than I would have liked but its a really nice API and platform so I think we will definitely use it again for other projects.

[![](./sub.png)](./sub.png)

We spent another week or two polishing, adding some extra features and making sure everything worked on mobile.

One of the trickiest hurdles was (and usually is these days) the lagging support for modern web technologies by Apple on the Safari browser. We use WebRTC to record video from the user's webcam which we then stream to S3, then do some processing on our servers before delivering to the user.

Unfortunately WebRTC isnt supported on Safari yet so as a workaround we implemented a input-file-picker for video on iOS. This works okay and doesnt allow users to select a pre-recorded video from their camera-roll thankfully but it would be nice if we had a unified video recording system.

[![](./ios.png)](./ios.png)

# Conclusion

Its still very early days for the project but we have had a number of signups already and some messages sent. We are still unsure if the service will work or not but its a positive sign that while we were developing the large company Typeform released a very similar product named [VideoAsk](https://www.videoask.com/) although competition might seem bad, to us it validates the concept.

Im happy with the amount of time we have spend on it relative to the potential for the project. Im really happy that we managed to get the payments system in from the start too and we definitely learnt a whole bunch from working with the excellent Strip API. Theres definitely a ton more we can do but its a good start.

If you would like to check out Howdy head over to [https://howdy.page](https://howdy.page) and signup for free now and tell your friends! :)

Lately we (Markd Ltd) have been working on a few different projects, today we are announcing another of those projects; [Post To Google Photos](https://chrome.google.com/webstore/detail/post-to-google-photos/lafpnfnchohhamoidohgmljijeafebbf).



# TLDR;

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

The above is a demo of it in action, should give you an indication of what its all about.

# What?

[Post To Google Photos](https://chrome.google.com/webstore/detail/post-to-google-photos/lafpnfnchohhamoidohgmljijeafebbf) is a Chrome Extension similar in concept to to [Post To Tumblr](https://chrome.google.com/webstore/detail/post-to-tumblr/dbpicbbcpanckagpdjflgojlknomoiah). Once installed you can right click on any image (even content that technically isnt a HTML Image) and then immediately post it to a Google Photos album.

# Why?

We noticed that there were a bunch of dissatisfied users with the current state of Google Photos uploading chrome extensions we thought we could quickly remedy that by producing a Chrome Extensions for it.

# Next

We dont currently have any monetization in the extension but there is already 1,500+ users of the extension so there is clearly a demand there. So once we have time we plan to go back and add a bunch more features, some paid and some free.

If you are interested in what we have planned you can checkout the community Trello board here where we have them detailed: https://trello.com/b/sFPJYO2G/post-to-google-photos-community

Lately we (Markd Ltd) have been working on a few different projects, today we are happy to announce one of those new projects, [LinkedIn Notes](https://chrome.google.com/webstore/detail/linkedin-notes/efjjkjipkkciokjblkmmfbihellibile).



# TLDR;

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

The above is a demo of it in action, should give you an indication of what its all about.

# What?

[LinkedIn Notes](https://chrome.google.com/webstore/detail/linkedin-notes/efjjkjipkkciokjblkmmfbihellibile) is a Chrome Extension that makes it easy to add tags and notes to LinkedIn Connections then gather them together for later processing.

Once installed you can simply visit any LinkedIn Connection page and you will see a sidebar open on the right hand side of the screen.

[![](./ss0.png)](./ss0.png)

You can add tags and notes to that Connection. If you want to hide the sidebar you just have to click the logo on the sidebar tab.

You can easily move that tab up and down so it wont get in the way of other UI elements or extensions below it.

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

Collecting custom notes and tags is all well and good but once you have done that what can you do with them?

Well we didnt know but instead of building a bunch of complex controls we decided to allow simple exporting of the data out to a Google Sheet. That way the data can be copied, chopped and cut up however the user wants.

To enable syncing to a Google Sheet you must enable Premium Membership in the extension options.

[![](./ss1.png)](./ss1.png)

Once enabled the user can then connect to Google and create a sheet to sync to.

[![](./ss3.png)](./ss3.png)

Then thats it. From now on any new notes or tags will automatically be added to the Google Sheet. The user can then do with the data whatever they like.

# Why?

So why have we decided to spend some time working on this? Well we noticed when working on [Markd.co](https://markd.co/) that quite a lot of the users were simply using Markd for adding notes to LinkedIn Contacts.

So when looking for other potential projects to work on we thought of a "Markd Lite" like product might do well, we could monetize it immediately and it shouldnt take too long to build with all our past experience.

# Next

For now we are going to see what users think of the product. If there is demand for it then we will work on other features.

So let us know if the comments below if you like this and want to see more. If you have a bug, or other feature suggestion you can leave it on our community Trello board: https://trello.com/b/AuDEewtt/linkedin-notes

Just a quick update today about a new feature for [Markd](https://markd.co): Import from LinkedIn



# What?

I mentioned in my [last post](/markd/markd-import-from-google-contacts) that we were working on imports other than just Google Contacts and today im proud to announce that we have added LinkedIn imports to Markd.

# How?

Because LinkedIn doesnt have an API that we can use to import the connections we have to rely on the user providing a zip file from LI's export feature.

![](./file-upload.png)

Once uploaded the server extracts the connections export tehn converts them into Marks.

For now we dont have any de-duplication feature so you might have to manually merge marks that are duplicates.

# Next

We are just debating what to work on next, if you have a suggestion for a feature you would like to see implemented please do [leave some feedback](https://markd.public.makerkit.co/).

Its taken us a little while to get this right but we are proud to announce the latest feature for [Markd](https://markd.co): Import from Google Contacts.



# What?

[Markd](https://markd.co) is a SAAS product myself and my co-founder Brandon [have been working on](/personal/farewell-bamboo-hello-markd/) for most of this year. Simply put, its a tool for managing your professional network.

Since the beginning we have had a [chrome extension](https://chrome.google.com/webstore/detail/markd-bookmarks-for-peopl/beaalofkiocejchbpaocbbjhobmambpp) that lets you quickly create Marks from a given LinkedIn, Facebook, Twitter or a number of other sources. Although the process is quick, just two click in most cases, we have found that some users want to Mark a great many more people.

For this reason (and because of numerous requests from users) we decided to implement a feature that lets you import contacts from other sources too.

# First Attempt

Although a great many of our users Mark from LinkedIn we decided that we would implement importing from Google Contacts first. Mainly because it has a well defined API (unlike LinkedIn) and already have some features involving Google.

Importing seems quite simple on the surface but due to the differences between a "Google Person" and a "Mark" there were some complications, but before I get to the details of that, the general algorithm for importing looks like:

1. Call the appropriate API endpoint to pull in as many contacts as desired (in our case we limited it to 2000 for now)
2. Split the contacts up into "new" contacts and "existing" ones. Because you can import multiple times there may be contacts that you have already imported.
3. For all the new contacts go through each and convert them to Marks.
4. For all the existing marks go through each and update it if it needs updating or skip it if it doesnt.
5. Gather the results of the following steps and "apply" the changes.

Although the above is fairly simple there is a subtle issue. If you remember back from [my previous post](/posts/markd-custom-fields/) on our custom fields feature we decided to implement a system where all fields on all Marks must have a "definition" first. This definition describes its "kind", its "name" and a few other properties. The idea here was that marks could share common fields which would be really useful.

The problem with this system is that it complicated the above algorithm, it forced us to load those definitions from the database then compare them in a way to determine if we needed a new definition when importing the fields from a [Google Person](https://developers.google.com/people/api/rest/v1/people#Person). Not only that if you take a look at the API for a Google Person you will notice that many of the fields have a "type", such as [EmailAddress](https://developers.google.com/people/api/rest/v1/people#Person.EmailAddress).

```
{
  "metadata": {
    object (FieldMetadata)
  },
  "value": string,
  "type": string,
  "formattedType": string,
  "displayName": string
}
```

This "type" makes sense because you might want to add multiple email addresses to your Google Person then set one as "Home" and one as "Work" etc. The issue is that the kinds of fields that Markd supports doesn't accommodate a "type" this is because the "type" was expected to be encoded into the "name" of the field definition. So for example you might attach an "email" field to a Mark and then name it a "Work Email" and then attach another "Home Email":

![](./ss-home-work-email-fields.png)

All Markd fields must have a definition that is shared between Marks whereas a Google Person field can have a differently named "type" for every field. There is a fundamental difference here between how Google structures its fields and Markd does.

The problem stems from the fact that we were planning ahead with the ability to "share" fields between Marks. Unfortunately this structure appears to be too rigid as it makes it tricky to "rename" fields. Because the name is part of the definition which is shared between all fields, if you rename the field on one mark then it forces the name to change on all Marks. This might be great for some fields but its not great for others.

After much discussion we decided to add "label" properties to some of our field kinds. So for example now an "email" kind would have the following value:

```
{
  "email": "mike.cann@gmail.com",
  "label: "Home"
}
```

Values are unique to each "field" which is attached to a Mark, they just share the same "definition".

This solved the "renaming problem" as each field could change its "label" value without affecting all the other fields. Unfortunately it also made the name of the field kind of pointless; you would add an "email" field definition to your Mark, name it "home email" then you would set the "email" and have to set the "label" to "home" too. You data was now duplicated and confusing... not ideal for Markd which prides itself on being simple and fun.

# Second Attempt

So we had a fundamental issue with field structures between Markd and Google. After having spent the best part of a week designing and implementing imports around our current structure of fields we were reluctant to go back to the drawing board. In the end however we decided that it was important enough to our core principles that we spend the time now to get it right.

The main issue was around our field structure. We wanted the ability to share definitions between fields for future features but in actual fact right now we weren't using it for anything, it was kind of getting in the way and adding "accidental complexity" to the system. We didn't need it. So we reluctantly decided to remove it.

Instead of all fields having a shared definition we decided to change fields so the definition is embedded right alongside the field. This meant that every field on every mark had its own embedded definition. This ensured that each field could be renamed without it affecting all the other Marks.

We could loose those "label" properties we added and simply have the name of the embedded definition become the "label". So for example when we import an EmailAddress field from a Google Person the "type", "Home", would create a new field that has an embedded definition with a name of "Home Email Address".

It took us a few days to re-architect the whole system to use this concept of embedded definitions instead of linked ones then migrate all the old fields over to the new type. Another day or two was spent changing the import code to use the new fields system.

# Conclusion

It took a bit longer than I would have liked to complete the feature but in the end I am really happy with what we ended up with. Everything is considerably simpler and easier to reason about than before. IMO this is super critical when trying to build systems that you want to iterate on.

# Future Plans

One thing that the old system of fields gave us was a quick way to add fields that you have added before to a Mark, so say you have created an "Home Email" definition, you could with one-click re-add that to another Mark without having to type out "Home Email" again.

We realized that this could be implement in the new system in very much the same way we do with tags, we simply query the database to see which fields are commonly used on your marks and present those as "Common Fields" to add. For now we have left this addition as a "phase 2" for future development while we move onto other things.

We also plan on layering on "linked" definitions once more at a later date once we have a use-case that we want to support.

Now we have a good flexible system of fields you can expect other import sources such as LinkedIn to come soon, stay tuned!

Thick and fast on the heels of our last new feature [Custom Fields](/markd/markd-custom-fields) today we are happy to announce our latest feature: Notes.



# TLDR;

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

# Why?

Brandon [mentioned in our official announcement](https://blog.markd.co/2019/06/06/adding-meeting-notes-to-a-person-on-the-activity-timeline.html) blog post on the topic, we felt that we needed a way for users to be able to take notes from a meeting and attach them to a given mark. So far the only ability we have for this is either to use the notes field on the mark or attach a file directly to the mark:

![](./showing-existing-notes.png)

Those might be okay for static data that you want to record about someone but it doesn't reflect the the temporal nature of other bits of data you might want to record about someone such as meeting notes, scheduled calls or dates of trips away.

For that reason we felt that we needed a way to attach data to a mark that would then be fed into an "Activity Feed" that represents information about the person that changes over time.

The first of these temporal data attachments are notes which can be used to quickly record meetings or anything else you want to say about someone in a given instant.

# Two takes

Just like with the [custom fields](/markd/markd-custom-fields) feature it took us a couple of attempts to get to the current design.

The first iteration we had it look more like a list of documents rather than a list of "comment" like notes in an activity feed. Although this was functional it felt a little too "worky" and against our philosophy for the product: "Fast, Simple and **Fun**"

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

The second attempt is the one you see on [https://app.markd.co](https://app.markd.co) now and better aligns with how we want notes to feel and sets the stage for future item types into the "activity feed".

# Simple Search

As part of the feature we implemented a way to search your notes. This will be super important once people start amassing lots of notes over time about someone.

The implementation of the search is a simple regex based search on the "searchable" content of a note. I felt like although I could go the full-text search route based on "text" indices in mongo or even Lucine / Algolia it was overkill given that we are narrowly searching for notes on a given mark by a given user only.

On a personal note; im working hard to temper my desire to "over-engineer" the technical solution to the problems faced by these new features. Its more important for us to get something out there and see what works and what doesn't before architecting the perfect high-performance solution.

# Conclusion

Im happy with how this feature turned out. Im glad we took the extra time to do a second iteration on the feature to get it right. Its going to be great once we have a bunch more items populating that feed.

# P.S.

This is a little bonus announcement not related to notes but we also added 4 new custom field types..

![](./markd-new-custom-fields.jpg)

These will be needed for our upcoming Google and LinkedIn import feature, so stay tuned for those!

Now we have our [new designs](/markd/markd-v3) in place for [Markd](https://markd.co) things can start moving again on new features. This has been an oft-requested one, Custom Fields!



# TLDR;

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

# Reasoning

As Brandon [mentioned in our announcement](https://blog.markd.co/2019/05/29/adding-custom-fields-to-your-contacts.html) blog post on the topic, we have had quite a few requests from users to have the ability to add their own data to a given mark. This lets you have multiple contact email addresses or have a dedicated field to remember the name of their spouse or pet.

This customization is the first in many that we will start to roll out that will unlock some of the rigidity of the current design, allowing users to customize Markd to their own requirements.

We also needed this feature in before we started working on importing data from other platforms such as Google or LinkedIn as those contacts will be imported with a whole bunch of custom bits of information that the old design just didnt accommodate.

# More Complicated Than Expected

Although this feature seems quite simple on the outside it actually turned out to be more complex that we had anticipated when it came time to actually implement it.

Originally it was planned that we would have a "templates" like system that a user would be able to select

![](./templates-1.png)
![](./templates-2.png)
![](./templates-3.png)

But we decided that this was probably too complex both for a user to understand and for us to implement as a first draft.

So we went back to the drawing board and wrote down the requirements and use-cases for what what we felt we needed from this feature.

![](./drawingboard.png)

We then came up with a solution that involved a multi-phase implementation. This is crucial because with only two of us in the company resources are extremely tight, so deciding what to work on and when is really tricky.

By breaking the feature up into phases we could get done what is needed for now to unlock the next major feature then come back to it later and add to it if it becomes popular.

![](./phases.png)

# Conclusion

Im happy with this feature and although it took a few design passes and a little bit of wasted time I think the process we took and the result we ended up with was successful. Im looking forward to the next set of upcoming features in [Markd](https://markd.co) so stay tuned for those coming soon!

Its been an adventurous month of travel, activities and hard work on our exciting new venture [Markd](https://markd.co).



# Trip to Europe

Late Jan and early Feb I took a much overdue trip back to the UK to visit family that I hadnt seen for over 2.5 years. It was great to catch up with everyone again, particularly awesome to see my cousins youngest considerably older than I saw him last time.

While in Europe I spent a week with my parents in the Alps on a rather excellent Skiing adventure in Morzine. Its been over 6 years since I last went skiing and although I hadnt forgotten the snowplow I had forgotten how much you ache after a hard day on the slopes.. either that or im getting old!

I even snuck in a day of snowboarding for the first time at the end of the trip:

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

# Above and Below the Water

When I returned to Australia in early Feb I ditched the snow for the heat of the the Perth Summer. Before leaving I had begun my adventures in Kite Surfing and was keen to continue when I returned.

So I have been out a number of times, whenever the wind will allow basically. Its been awesome, I cant believe I haven't been doing it sooner. As one fellow POM put it the other day; "Not kite surfing in WA its like going to Chamoix and not skiing"

[![](./kiting.jpg)](./kiting.jpg)

To round off my favorite Australian past times, this month I have also been doing a fair bit of snorkeling / free diving around Perth and Busselton. I put tohether this short movie of one of my Busso dives:

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

# Markd

Last but certainty not least I have been working hard on [Markd](https://markd.co). I [spoke about Markd in my last post](/personal/farewell-bamboo-hello-markd/), its a chrome extension and website that aims to make remembering and organizing people fast, simple and fun.

We have been doing a lot behind the scenes, planning out what features we want and what priorities we should give them. We setup a [centre so that users can leave us feedback](https://markd.public.makerkit.co/) which has already been useful.

Our first major new feature, Lists, went live last week. I wont go into it too much as my co-founder Brandon already did an excellent job describing it in this post: https://blog.markd.co/2019/02/21/new-feature-add-to-lists.html

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

We are working hard on a number of other features including a major re-design of the site which im really excited about and cant wait to share once its ready.

Hopefully over the next month or two ill be able to share some more Markd updates as we progress, so stay tuned!

So Friday marks what could be a very important day for me. It was my last day in the employ of Bamboo but was my first day in the employ of myself for Markd!



# Bamboo

It seems hard to believe that it was [only 6 months](/posts/started-at-bamboo/) ago that I joined Bamboo the company building a cryptocurrency investment app.

It's been a wild 6 month ride. Intense long hours with highly motivated and incredibly talented individuals. Pretty much exactly what you expect & want out of a startup.

We made awesome progress in a short time. I was instrumental in setting up the initial Typescript and React-Native based mobile app before switching to building out the Typescript and Serverless backend for a [closed beta launch](https://medium.com/bambooblockchain/announcing-bamboos-closed-beta-173980918983).

Since closed beta we were working hard on the new bank-grade event-sourced backend.

Bamboo has been great to me and developed a ton there but I always felt like I was missing something, something that fed my entrepreneurial ambitions. So when I received a call from my long-time business partner [Brandon](https://brandonwu.co/) about an exciting potential business opportunity I was all ears.

# Markd

I [first wrote about](/posts/portfolio/projects/introducing-markd-pinterest-for-people/) Markd back in September of 2016. Its a service that aims to make remembering and organizing people fast, simple and fun.

Back in 2016 Brandon approached me looking for a a developer to build out an MVP for him. After a short while we completed that. I continued to work on it on and off over the next year or two.

Unbeknownst to me, Brandon had been demoing the MVP to investors and one became excited about the potential of the product and wanted to invest. Thats when Brandon contacted me to see if I wanted to work on Markd full time.

I was excited. Its not often you get the opportunity to work on a project you are excited about and are able to secure funding to cover the costs of living in a [rather expensive country](https://www.numbeo.com/cost-of-living/country_result.jsp?country=Australia) so I said yes.

# Conclusion

So im going to be working on Markd here in Perth Australia for the forseeable future with Brandon in Cambridge England. Im really excited about the future, we have a huge number of ideas and features we want to implement. Im sure ill be blogging about some of the technology and progress we make.

If you want to checkout what Markd is all about you can head to the website: https://markd.co. Dont forget tho it is very much an MVP at this stage but if you want to give us some feedback you can email me: mike@markd.co.

I also just want to say a massive thanks to the Bamboo crew, as mentioned above it was an absolute joy, im sorry it had to be cut short but im sure you guys will do just fine without me :)

[![](./bamboo-crew.jpg)](./bamboo-crew.jpg)

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)](./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-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.