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! :)

Just a quick post on my recent attendance of the one-day hackathon "Energy Hack".



# Energy Hack

Its been a while since I have done a hackathon so when I saw Energy Hack from the Ministry of Data popup in my inbox I thought solving energy problems would be interesting so I signed up.

Unlike other events I have participated in this was a one-day event so time was really limited. Starting at 8am you had just a few short hours to form a team, come up with an idea to solve one of the three challenges then present your idea at 5pm.

There was \$4k worth of prizes on offer to help motivate people to attend which is pretty generous for a one-day event.

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

# The Day

I teamed up with two other guys that I met right at the start of the event. Jeremy is a semi-retired engineer, programmer and general all-round technical knowledge-base. Tim is a computer science graduate, ex-management consultant and energy-industry expert.

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

With that combination of expert knowledge and experience I felt like we had a good chance.

So after officially forming our team and coming up with a name (Power Rangers), we set to work coming up with a solution to the three challenge questions.

The theme of Energy Hack was energy in small business so all three challenges revolved around that:

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

I hadnt looked at the challenges before I arrived but Jeremy had and had even come up with an idea to solve Challenge 3 that he was keen to pursue.

The idea was to apply data segmentation techniques to small business categories so that the government or industry could more accurately target their solutions.

We discussed it for a little while and decided to give it a shot. I was a little hesitant because I wasnt sure that it was really "innovative" enough for a hackathon but after some more thought I realised that solving the "targeting" problem was really important as having a great solution for reducing energy consumption was well and good but if you dont know who you should target with your solution then you are just shooting into the dark.

Using my past hackathon experience I decided early on that it was probably best that we didnt even attempt to actually build a solution. A few short hours isnt enough to do anything meaningful and you were more likely to just end up stressed and rushed.

Instead we spent the bulk of the time trying to come up with the most clear way of conveying our idea and why we felt it was important.

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

The result was a well rehersed slide deck that I was pretty happy with. If you are interested then you can find the slides here: [https://docs.google.com/presentation/d/1sLRtkFDUtK7kfE4MyXLUb2mVWYi47mWn1qUgw_7E_s4/edit?usp=sharing](https://docs.google.com/presentation/d/1sLRtkFDUtK7kfE4MyXLUb2mVWYi47mWn1qUgw_7E_s4/edit?usp=sharing).

So 5pm rolled around and it was time for all 8 teams to present.

I decided not to present this time. Tim is a far better orator than me and he did a great job giving the 3 minute presentation. Jeremy and I went up to join him for the two minutes of questions.

[![](./watching-pres.jpg)](./watching-pres.jpg)

# Results

So sadly we didnt win a prize. I just think we didnt do anything innovative enough. Basically we were pitching a consultancy who's product is a report. So even though I think we did a great job with putting together the slides and presenting ultimately it wasnt what the judges were looking for.

# Conclusion

I had a great time again and met some really interesting people that I hope to keep in contact with. Thats one of the main reasons for going to events like this, build your network up because as they say "Its not what you know but who you know".

This one has been quite a while in the making but im proud to announce this innovative new game we have been working on.



# TLDR;

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

# History

I have been building chrome extensions for [quite some time](/posts/my-first-chrome-extension-post-to-tumblr/) and have always considered them a powerful and often overlooked medium.

When I came across the [Tabby Cat](https://chrome.google.com/webstore/detail/tabby-cat/mefhakmgclhhfbdadeojlkbllmecialg) extension a few years back I realized that the New Tab page is a powerful space for content that gets short but frequent attention (every new tab thats opened). It got my brain-juices flowing and I began to wonder what else we could use the new-tab page for.

Obviously as a game developer my mind quickly turned to what games could be played there. It needed to be asynchronous and quick to take your turn so you can continue on with what you were doing. I thought about classic board games and the first one I thought about was Battleships.

I half-started to implement what would become "BattleTabs" some years ago but never completed it.

When I mentioned the idea to my partner-in-crime Brandon he agreed that its an interesting idea and so we started to explore the idea a little more.

We decided to enlist the skills of my ex-colleague and artist extraordinaire [Alan Macfarlane](http://www.melbournemonsters.com/alan-macfarlane). A month or so of development later and BattleTabs was born!

# How It Works

So what is BattleTabs? Well its "An Asyncronous New Tab Chrome Extension Game", a descriptive but mouthful of a name. I like to think of it as a "Nano Game". That is you can dip into the game for a second (or less) at a time.

You start the game by going to the Chrome Webstore and installing an extension: https://chrome.google.com/webstore/detail/battle-tabs/mjcklhnhfiepmofggcoegkmkokbljmjd

Once installed the extension will replace your current new-tab page. The first time you open it you will immediately be asked to start placing your ships for your first match:

[![](./first-match.png)](./first-match.png)

You can drag and rotate the ships to whatever you think are good positions or you can randomize the positions for quick action.

Once ready you give yourself a name and avatar (clicking the avatar changes it):

[![](./create-user.png)](./create-user.png)

And then you are straight into the action:

[![](./waiting-for-opponent.png)](./waiting-for-opponent.png)

If theres another player that is waiting for an opponent too you will instantly be matched up against them.

You can then start taking turns trying to sink each others ships.

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

Because the game is designed for quick bursts of gameplay you can close the window at any time and the game will continue to periodically check in the background for turns from your opponent. It will let you know via a notification if they took a turn.

You can start a new match at any time, but you can only have 5 active matches at any one time.

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

You have one day to take your turn otherwise you forfeit your turn. If you forfeit your turn three times in a row you automatically loose the match.

Scoring is pretty simple for now with a point ranking based on the number of games you have won or lost, but we plan on improving that later (see Future Plans).

[![](./simple-scoring.png)](./simple-scoring.png)

# Development

Development was quite an involved process as it often is with games. We first had to decide how we wanted to present the game, should it be 3D, topdown, isometric or something more exotic?

[![](./playing areas.png)](./playing areas.png)

We ended up with a simple isometric layout. We felt like it gave us the right combination of aesthetic and simplicity on art requirements as you can simply horizontal flip the sprite to make it look like its going in a different direction.

Once we had the general layout down we moved on to how do we present the ships. The talented Alan knocked out a bunch of different options for us to choose from:

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

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

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

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

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

We decided that the Vikings theme would be best for the first release but we liked the idea some of the others so much we thought about future upgrades where the player can choose from different "themes" they can play with.

I got to work developing the actual game in isometric. I had built a few isometric games before and one effect I like from block based isometric is seeing the blocks move independently, it gives a sort of rippley water effect so I had a go at implementing that.

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

I was originally using React to do all of this but I discovered that react is a little too slow to animate this many objects so I reluctantly changed over to using Phaser3 for the game engine. I really didnt enjoy using Phaser tho, I think I would probably just roll my own solution in the future for more control.

Talking about isometric we had some issues with the length of the ships and isometric depth sorting.

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

The issue is that isometric doesnt work too well when you have long sprites. After much discussion and experimentation (and fighting with Phaser) we decided on a solution that split the sprites up so they could be depth sorted individually

[![](./depth-sorting-masks.png)](./depth-sorting-masks.png)

This finally solved the issue.

One other thing we fiddled around with for a while was how to indicate the various states that cells could be in.

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

For example when you click a cell to make a guess, it first enters the "guessing" state to indicate that its waiting for a response from the server. It then transitions to either a "hit" or "miss" state depending on if there is a ship there or not. Then finally there is a the "destroyed" state to make it clear that you have destroyed a ship at that cell so you dont need to explore any more.

# Future Plans

So its obviously very early days for the project and to be honest we are really just testing the idea out at this stage. Is the new-tab page a good medium for games? We arent sure. We think it is but time will tell.

If people are interested in the game then we have a bunch of future plans for things we want to work on to improve the game.

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

Our public [Trello Board](https://trello.com/b/EoQS8Hq2/battle-tabs) lists a bunch of the things we have planned. This lets people see what we want to work on next and they can vote on their favorite's or add a comment to suggest something thats not on the list.

One of our favorite upcoming features is per-match-chat. You can use it to send quick messages to your opponent. We are considering making it emoji only chat which would be rather novel. If they are only emoji-based then theres no real way to send abuse thus we dont have to spend time moderating it.

Currently the game is totally free but obviously we will need a way to pay for continued development so we are thinking that we could sell new "themes", "skins" and other content to enhance the game.

Anyways let us know what you think of the game, is it interesting? What do you think we could do to improve it?

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

Todays post is a little different from my usual technical or business related posts, its a tale of search and discovery..



# TLDR;

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

I was contacted to give an interview by Dariya Salmin of ABC's South West Radio show "Mornings" about the found iPhone, give it a listen if you dont do readin' :)

# The Discovery

A few weekends ago it was an unusually hot spring day here in Western Australia and we were on a weekend break at the seaside town of Busselton. As it was so warm I decided to head down the beach for an early-season swim under the famous Jetty.

[![](./The Sheds of the Jetty Afar.jpg)](./The Sheds of the Jetty Afar.jpg)

I had a fantastic swim, there wasn't anyone else down there and the water was full of fish hiding under the jetty.

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

So there I was happily swimming along when I noticed something sticking out of the sand. I swam over and to my surprise it was an iPhone..

[![](./discovery.png)](./discovery.png)
(An artists impression of the discovery)

Now this actually wasnt the first time I had found a phone under the Jetty. I had previously found one further down towards the end of the jetty that had obviously been there for some time and was heavily corroded.

This one looked pretty new however so I surfaced and looked up at the jetty to see if I could see anyone looking down as if they had just dropped it, but there was no one up there. Expecting it to be broken anyways I just put it in my pocket and continued by swim.

It wasnt until I returned to the beach that I took a closer look at it and to my surprise it was still on but incredibly glitchy, the screen wasnt really comprehensible.

[![](./the-phone.png)](./the-phone.png)
(this was taken some time much later and looked far worse than this at the time)

Fearing the damage I was doing to its internals with it on I decided to quickly turn it off.

# Repair

After getting it home I put it in a glass of rice for a day to hopefully dry it off as much as possible. I then plugged it in with fingers crossed that it would still turn on. Sadly not, it wouldnt charge.

Expecting the worst I decided to take it to a mobile phone repair shop and see if anything could be done. If I could get it working again I would try to find the owners and return it, otherwise I would see if I could sell it and repair my own broken iphone.

After a \$40 inspection the phone repair shop declared it "buggered" (or a word to that effect). It was totally salt damaged inside with salt corroding all the contacts and components. Dejected I returned home.

A week or two later I found it in my drawer and thought to myself why not just try plugging it in one more time, not expecting anything I attached the cable and returned to work. About 5 minutes later to my great surprise I saw the screen light up and turn on!

[![](./lock-screen.jpg)](./lock-screen.jpg)
(faces blurred for privacy)

The screen was on but unfortunately it appeared as if the touch part of the display had been corroded and no longer functioned. Fortunately it was an iPhone 8 and so had a physical home button. Pressing the button revealed a very cute picture of a couple and child, I bet they had tons of more pictures on there that unless they had a backup, they would dearly want back, I had to find a way to return it.

# The Hunt

I thought I would try doing a reverse image search for the picture of the couple to see if I could find them that way.

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

Nope, but if you ever wandered what love looks like, this is it apparently!

So it looked like they had either cancelled their contract or the sim card was broken. I knew that if I could get it connected to the internet somehow then they may have set a lost message via iTunes.

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

So I took another trip out to the mobile phone repair shop and see if there was anything I could do. They took it apart again and found that replacing the screen would make it touch again, so that was an option.

The other thing I could do was put my sim in it an see if that worked. If it did then the sim tray wasnt broken, it was just the original owners had cancelled their contract for the phone.

So I did just just. After a few minutes it connected to Optus and then to my surprise a bunch of notifications turned up on the phone and they weren't obscured!

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

So I now had an instagram, ebay and fb messenger notification to go on. I thought that the FB message might be my best bet so I quickly searched for all the people with the the name mentioned in the message asking them if one of their friends had lost an iPhone.

I then thought hang on no, that instagram message was replying to a comment left by whoever had lost the phone so the person being replied to with the @ is the owner of the phone!

I quickly looked them up on instagram.

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

Huzzah! I had found the person! But the account is private, where do I go from here? There is no way to contact them.

[![](./insta-no-message.png)](./insta-no-message.png)

Then I remembered that Instagram in their infinite wisdom only allows a small subset of functionality on their website, so I fired up Instagram on my iphone and looked the person up and yep sure enough I could send them a private message.

# The Return

I sent them a prive message letting them know that I think I had found their phone and asking them to call me. About 5 minutes later I received a call, and relayed the whole saga back to them. They were incredibly grateful as they weren't sure if the photos were backed up or not.

They came over that afternoon to collect the phone, paying me the $40 that it cost me for the inspection and $10 on top to say thanks. Not enough to get the screen repaired on my phone but thats okay, im glad they got their phone back with all their valuable pictures on it :)

# Conclusion

Im really surprised that the phone still worked after sitting at the bottom of the sea for a while. Im even more surprised that it turned on again with all that salt build up inside of the phone. Im even more surprised that the owners didnt have obscured notifications on the lock screen and they they hadnt remotely locked the phone.

Its this fortunate series of surprises however that allowed me to work out who the phone belonged to and eventually return it!

Its been a little while since I have done a pure tech focused blog post but I discovered an issue with React Hooks and Chrome Extensions for which I could find no mention of anywhere on the internet so I thought I would share the issue and my solution.



# The Issue

So the problem is; if you build a chrome extension with a background page and try to use a `useEffect` hook on that page, you will notice that the handler of the effect doesn't trigger.

```typescript
import * as React from "react"
import { render } from "react-dom"
import { useEffect } from "react"

function App() {
  console.log("Execution reaches here..")

  useEffect(() => {
    console.log("..but this never gets triggered.")
  }, [])

  return <div />
}

render(<App />, document.getElementById("root"))
```

This is obviously not quite right.

I put together a demo app for this here: https://github.com/mikecann/bgpage-hooks-issue

# The Workaround

It appears as if this issue started happening somewhere between 16.8 and 16.9 so you could just downgrade your react version.

I also discovered that you can workaround the issue with this little hack:

```typescript
function useBackgroundKeepaliveHack() {
  const [tick, setTick] = useState(0)
  useLayoutEffect(() => {
    setTick(1)
    setInterval(() => setTick(prev => prev + 1), 1000)
  }, [])
}
```

If you add that into your component tree then hte effect now triggers as expected, very curious. Perhaps it has something to do with the fact that background pages aren't actually rendered to the screen thus perhaps React can detect that and prevent effect updates?

I have reported the issue to the React github page so hopefully it will be looked into and fixed at some point: https://github.com/facebook/react/issues/16629

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!

Wow its taken a little longer than we would have liked but finally we have finally released the completely redesigned and rewritten [Markd](https://markd.co) website, extension and server!



# Design

So we teamed up with an old colleague of mine [Alan Macfarlane](https://www.melbournemonsters.com/) to help us with the designs and branding. We wanted to go for something that would make our brand stand out, not feel too formal and perhaps have a little "gamey" feel to it as both Brandon and I are long time game developers.

Alan went away and came up with a bunch of awesome ideas for characters which we then used as the basis for many of the pages.

![](./different characters.png)

In the end we went with a very simple and stylized version that we thought suits the brand we want, is easily extensible and hopefully easy to animate in the future should we wish to.

![](./login-page.png)

Alan also was responsible for our new logo which I think looks awesome when shown off in its animated form:

<img alt="markd logo animated large" style="box-shadow: none !important; margin-bottom: 20px" src="./markd-logo-animated-large.gif" />

For this version of Markd we decided to split the website up into two parts;

"Static" pages live on https://markd.co and are designed in Webflow for fast tweaking and A / B testing by Brandon.

![](./markd.co.png)

"App" pages live on https://app.markd.co and is Typescript / React / Single Page Application (SPA) and is where I have spent most of my time.

![](./marks-page.png)

So thanks to Alans awesome designs and after a lot of hard work I think we have ended up with a really good looking and easy to use site for collecting and organizing marks.

Heres a short video showing some of the main features:

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

# Tech

Behind the scenes a lot of work has gone into ensuring the tech is in a good stable position for us to build future features on.

I decided that our [Parse-Server](https://github.com/parse-community/parse-server) based server that we have been using up till now just wasnt going to cut it for some of the future features we had planned.

So right at the start of the project we took (not lightly) the decision to completely rip out our backend and start again, then migrate the old database over.

Due to the highly document-orientated nature of our data we decided to stick with the no-sql database MongoDb and then interface with it via node. For the Client to Server querying and mutating we decided to depart from my usual choice of REST based API and instead decided to go with GraphQL.

GraphQL should in theory be much better for us in the long term, allowing us to develop APIs that can grow with us and be compatible without a huge parameter or endpoint explosion you might end up with REST. For now I am yet to be convinced, there is definitely some benefits but also quite a bit of extra overhead to deal with when using GraphQL, im just hoping that over time as things mature some of those issues will go away.

# Testing

As we are just a small 2-man team I knew testing such a large set of changes was going to be a challenge particularly when we had added a whole bunch of new features in the process.

Our strategy with testing is to test in depth. So firstly we have the automated unit and integration testing for the server-side code.

![](./server-integration-tests.png)

These tests hammer the actual API from the outside which then hits a local database. This gives us a high level of confidence that when the client uses the same API to call the server will get the expected results.

On the client side I actually have very few "unit" tests and instead opt for a few high-level End-To-End (E2E) tests which use [Google Puppeteer](https://github.com/GoogleChrome/puppeteer) to spin up an actual browser which then clicks on actual elements on the screen and observes the results match the expected results.

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

I run these E2E tests twice, once for desktop sized resolutions and once for mobile sized resolutions.

All these automated tests are run on every single code push by the CI server which gives us a good level of confidence that the core functionality is working after every change.

Following that however we do a smoke-testing pass on our "staging" environment before we merge any new changes into the "master" environment.

For very large updates such as this complete redesign we knew we needed a little more testing so we contracted a freelance QA tester Seb to help us get the confidence up that everything works on a number of platforms.

# Conclusion

Time will tell if this was worth all the effort. Personally I think we have done a great job and im proud of the results. Im feeling much better about the foundations we have now to go ahead and build the next round of exciting features, so stay tuned more more!

Its been almost 2 years since I had to change anything with my blog but unfortunately 2 years is a long time in web development, and my blog needed some love.



# The Problem

So a few days ago I sat down to write a post on how we had just converted the entire backend of Markd over from Parse to GraphQL. I had recently upgraded my machine and thus I checked out the source from the [repo](https://github.com/mikecann/mikecann.blog) and started to build.

To my incredible frustration, no matter what I did, I couldn't get the project t build. I spent 2 hours wrestling with npm, hexo, gulp, grunt, saas, node-gyp and windows native compilation. Eventually I threw my hands in the air and decided enough was enough. Im just going to rebuild the site myself so I know exactly how everything works.

# Gatsby

I knew from my [last migration](http://mikecann.blog/blog/the-static-blog) that the key to a good performing blog was a staticly generated site. With that in mind I had heard much about [GatsbyJs](https://www.gatsbyjs.org/) the static site generator with a large following and so I decided to give it a shot.

One of the awesome things about Gatsby is the documentation is very thorough and there are plenty of third party tutorials so I found it pretty easy to do just about everything that I needed to do. 

I replicated pretty much everything from my old hexo-based blog and added a few other nice things.

I love it that my site is now all written in Typescript and React so I can very easily create custom components and things such as the Algolia powered search feature (see top right of this page).

# Conclusion

There are definitely going to be some minor things not working so if you see something please do contact me and let me know.

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)

2019

Archive

2019

Archive

2019

Archive