Written by: Alan Downie — CEO & Co-Founder of Macropod
Yesterday a few of the Macropod team started working on an adventurous attempt to conceive, build and release and application in 2 days. With a designer, 2 front-end devs, a back-end dev a marketer and this useless CEO, we intend on having something shiny and new for you to play with on Christmas Eve. Here’s hoping anyway!
(For a refresher on what we’re doing, read ‘Part 1 — The Plan’)
One day into the project and the team have already made an amazing amount of progress. We’ve acquired the domain name, the servers are set up, the basic website has been built and development is well underway on the app. There have been a lot of decisions to make, and a lot of disagreements in a very compressed amount of time.
The great thing about this sort of time pressure is that everyone realises that it’s better to just make a call and move on. No time to argue.
The app (and therefore domain name) is a great example of making fast decisions. It would’ve been easy to spend hours brainstorming a name and arguing about the merits of SEO and competitors etc. Instead Chanie shortlisted a dozen names, her and I picked the two we both liked and then agreed that Gitr was the best of the bunch. We did some searching for similar naming apps, and decided that Gitr.io was a reasonably safe option.
Most importantly; we didn’t get the whole team in on it. Decisions that are made based on opinion are the most likely to devolve into argument. We just made the call and moved on to the next task. Job done, domain registered, what’s next?!
Time is of the essence people!
Hopefully speed of action will be a theme over the next day or so. Putting outcomes ahead of personal preference means that a lot of shit just gets done a whole lot quicker. There’s no time to argue about typeface, platform or deployment strategy. There’s one person who is responsible, let them make the call and we can all just get on with it. We always put trust in our team to make decisions, and with this project we’ve turned that up to 11!
So where’s the project up to?
Alan (not me, the other one) has been whipping up an API in Rails ready to be consumed by the React devs. The backend does the sign up and authentication, fetches interesting people you might like to talk to, stores tokens for the client app etc. He’s also set up our continuous deployment pipeline so we can start pushing stuff LIVE asap!
There was some brief discussion around what backend framework to use. Most of our stuff at Macropod is done in Go these days, whilst the older apps are still done in Rails. The decision to go back to Rails for this app basically came down to who was doing what and what was going to be fastest for them! This is the one time where speed of execution wins above all else. Given that Alan put his hand up to do the back end work (leaving Conrad and James to do the front end), it made sense for him to choose what would allow him to get it done quickest. Rails it is! No discussion about performance or scalability please.
Yes, I know if we get a million users Rails will probably suck. But if we do have a million users next week, Rails will be the least of our concerns.
Meanwhile, Conrad has been creating all the data stores and wiring up Flux for the React app, setting up the client side GitHub authentication and creating the interfaces between the Rails API and the shiny UI that James has built. He used our own project template (available on GitHub) as a quick start on the project, and then cannibalised some work we’d done previously an another project to get it all up and running in record time.
We’ve been using React at Macropod now for around a year, and the team absolutely love working with it. Having come from using Backbone previously, React took some adjustment, but now there’s no way we’d choose anything else.
James has been working flat out on the front end UI. There’s a nice swiping interface for skipping through developers (a prototype for touch devices is here). The login and onboarding is almost done and the bare bones of the app are basically there already. There’s plenty of admittedly “SUPER dicey” stuff going on, but in the interest of haste, we’ll live with it!
There’s still a shit-tonne of work to be done on the UI. About all we have right now is some really dodgy wireframes (you can view them here). This where the bulk of the work in the app is really, so Matt will likely jump across to help with the UI tomorrow.
Speaking of Matt, he has built us a website in ultra quick time (not quite finished yet, but close). It’s already responsive, and all wired up and ready to deploy. We just need to get some screenshots of the app itself, and then we’ll be good to go! There won’t be much in the way of content initially, but we’ll add some more detail before launch. Here’s Matt showing off the responsiveness. Getting it right the first time, all hand crafted, no libraries required! Lean and mean.
Our colour palette is a great example of not getting bogged down on the details. Matt chose a blue colour we were happy with (#646C7C) and then found a nice palette featuring that colour over at colourlovers.com as a quick starting point for our app. It’s a great way to get moving during development, and allows for fine tuning as we progress. Like many things, it’s often better to just make a decision and move on than it is to dwell on the details.
So that’s about it for day 1. A pretty decent amount of work got done, even if it doesn’t look it yet. A lot of the early leg work will mean tomorrow we can finish off the app and get ready to deploy!
Part 3 is now up, read on!
