Conceiving, Building and Launching an app in just 2 days.

BugHerd
5 min readDec 23, 2014

Part 3— The harsh reality of day two

Written by: Alan Downie — CEO & Co-Founder of Macropod

If day 1 was the day of optimism and excitement, day 2 was the day of crashing back to earth. The day of “holy shit, there’s no way this is ever getting released. Why did we let Alan talk us into this!? We could have been playing Mario Kart!!!

(If you’re not yet ready for the heaviness contained in this post, perhaps take a look at Day 1 instead)

Things were going pretty well this morning; we finished off the API and starting wiring up the bulk of the react app. When someone put “Funky Town” on the Sonos, it should’ve been a clear sign that things were about to go downhill…

The depressing, lonely reality of the North end of the office on Day 2… #nofilter

At some point today we realised that we needed to build a chat app. I mean, we knew we needed to build a chat app, but today was the day when we realised that we had about 4 hours to build a fully functional chat application with all the bells and whistles that users would expect. WhatsApp sold for $22 billion, and we basically have to rebuild that. In an afternoon. Many LOLs! Then, a little crying.

Today’s blog post is brought to you by Swiper!

Oh and then there’s the whole swiping with your finger thing. James found a really neat swipe library for React (http://jed.github.io/react-swipe/demo/ — give it a go on your phone! Awesome cool!). But due to some weirdness with React dependencies and versions and issues which honestly I don’t understand, it just wasn’t working for us. About halfway through the day it looked like our swipe-dependant app would have to launch with no swiping! There was plenty of scratching of heads and also heads meeting desks. Fortunately, Conrad had a minute to jump on the problem and worked out we could get away with a couple of minor modifications to the library.

We forked it, updated it, and now swiping is a thing!

Server things spinning and doing computery things

The other issue causing quite a bit of consternation over the past 24 hrs has been authentication. There are a bunch of ways to do this, and we went through a few different iterations before settling on our chosen method. Iteration is normally good, but not when you’re in a hurry! Originally, the client app was just going to get the OAuth token from GitHub, but doing this requires us to store the secret key in the app which is obviously a bad idea!

We then went to having the server app get the OAuth code (which is swapped for a token for the client) which got passed back and forth. This worked, but made development a hassle because we had to use production’s callback url which made development from phones near impossible… gah!

In the end, we ended up having the client redirect to the backend, the backend does the GitHub thing, it then redirects to where the client wanted to go and passes along a json web token to authenticate. Phew… that’s a mouthful, but it was much quicker to implement and everyone seems happy!

This is the first conversation ever had on Gitr. It took less than 30 seconds to become an HR issue.

Once that was resolved we started to get down to knocking out the chat app. James had already put together a pretty hasty UI, it was then just a matter of making it…you know…work.

There was some brief discussion around making our own client/server tools to make the chat app work, but it was quickly decided that PubNub would give us 99% of what we needed. They even have a tutorial app that does most of this in 10 lines of code! For the super lazy, here’s the gist. Crisis averted! The day is saved! We might just get there yet!

We don’t have the most robust chat interface at the moment, and there’s no Emojis, you can’t upload images or code snippets…it’s really very basic at the moment. If this thing gets some use, this will be the first part of the app that gets some more attention.

But not every solution came to us so quickly….

The Yin and Yang, the beard and no-beard

We’ve been using a slightly older version of React-router in our other apps. When we upgraded React to do this project we discovered there had been a change to the way routers work which tripped us up for a short while. For the technical minded, parameters used to be passed in via ‘properties’, so they could be accessed like this.props.params.whatever. Now we have to use the ‘Router.State’ mixin and use this.getParameters().whatever. Not much else has changed, but that one difference escaped us for long enough to confuse us and really slow us down. On a longer project these sorts of hiccups are usually a non-issue, but when an hour or two is the difference between launching and not launching, these slow-downs can be disastrous!

So we’re very nearly there. We’ve not quite got the UI sorted, and we’re not showing all the data about users that we’d like. There’s no links back to look at github repos, there’s no notifications and we obviously won’t have time to make this a Cordova app or anything like that. If feedback is positive, I’m pretty sure the team will be keen to add to the app post-release. Time will tell what gets done before release!

Rather than seeing photos of Conrad in a bikini, you’ll be able to check out the highlights of his work. Much nicer for everyone!

At the time of posting this, it’s 7am in Melbourne, Australia on Christmas Eve. The devs are coming into work this morning to have one last push to the finish line. Everything is “feature complete”, just some polishing to be done! Servers are running, the app is so close to done! So, no matter what it looks like we’ll be putting it online at midday (that’s 5PM PST for those over the pond)!

--

--

BugHerd

The visual feedback tool for websites. It’s like using sticky-notes to capture and pin client feedback directly onto a page.