Skip to content

Instantly share code, notes, and snippets.

@olizilla

olizilla/how-to-build-an-awesome.md

Last active December 20, 2015 11:49
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save olizilla/6126539 to your computer and use it in GitHub Desktop.
Save olizilla/6126539 to your computer and use it in GitHub Desktop.
Download ZIP
Notes on tracking ships. IN THE FUTURE.
Raw
how-to-build-an-awesome.md

How I'd build an awesome thing, if I were me, today.

  • Realtimey push of async events to all clients - We track ships. Ships move. The client should be informed of each position report, as they happen. I strongly believe that this should be at the core of all our apps. This expands to a generic async event notification system. Consider WebSockets via Engine IO or push as a service via http://pusher.com
  • DOM templates. This isn't just a bunch of strings dammit, it's chunks of HTML. The templates should be HTML too.
  • Client side DB. Structured APIs over localStorage & indexDB are sufficiently advanced that we can sync subsets of the server data with a client side DB-like structure. User interactions manipulate the local data, and just those diffs are communicated to the server. If the client maliciously force-violates the front-end validators, then the server simply rejects the change, and sends back the relevant diff to patch their database state back to match it's view of the world.
  • Client/Server state sync. An extension of the above idea. The client subscribes to some subset of the servers data. Subsequent updates are just diffs of changes that occurred server side since last request. See SLEEP - http://www.dataprotocols.org/en/latest/sleep.html & https://gist.github.com/maxogden/1246804
  • Better Telemetry for all the things - we should be able to give projections on where a ship will be in 1 hour, and alerts on time to entering a restricted zone, like an incoming missile warning in the films.
  • App metrics We should know the time to first byte for all clients, have a big graph of what browsers our users are actually using (a la http://browpie.meteor.com) and all that jazz. Metrics help decisions, decisions are hard.
  • Ship icons that look like the actual ship at sensible zoom levels. We have the data. Let's render them. Command&Conquer was doing this on my 486 in 1998.
  • Mobile first responsive design. - An established best practice. Think about the mobile experience first. Figure out what the critical, core function of the app is. Design for that. All other features must justify their existence to a group of busy people who actually have a requirement to track ships. Read this, http://seriouspony.com/blog/2013/7/24/your-app-makes-me-fat and now read it again, and now read it until you have fully understood the ramifications of it. If you still don't care then you may have a problem and should seek help.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment