building a trivia app – continuation

This is a continuation of my post series on Building a Trivia App. In the previous post, I talked about:

  • Database design
  • Getting a simple API going to build a proof of concept
  • A very brief mention of possible game design (pyramid style)
  • Getting started with React Native

Despite wanting to create a fairly simple app, there are still some pretty significant holes in my knowledge base. To combat that, did some searching around and decided on some Udemy courses.

Here’s how I’ve progressed so far:

You’ll notice I didn’t just jump right into React Native, because I wanted to make sure I had a good handle on using Redux in the context of React before diving into that effort. It’s been a slow and steady climb, but a real joy completing each course and all of the example work that goes with it. I’m currently in the process of doing a deeper dive into React/Redux, and next I plan to immerse myself in the world of AWS Serverless apps.

As I’ve researched further, I’ve decided that given the needs of this app, going with something like AWS Lambda is probably the best route forward (plus, it’s pretty bad-ass). Rather than hosting my own clunky API on a server (and everything that entails) with a single-point-of-failure database, Lambda will let take care of the “server” side of things for me, and let me just maintain functions and endpoints. Functions and endpoints that scale from 0 to the hypothetical forever, no less. That’s right — an API (and database) that won’t crunch under the stress like I’ve experienced in the past.

What led me down the path of AWS Lambda is reading the first few chapters of Serverless Apps with Node and Claudia.js, which I could write a completely separate post about (since it’s apparently broken, even though I shelled out about $40 for it), but was interesting enough to get me to try a few things and learn about Lambda through the lens of creating a scalable API in a close-to-real-world application.

To make a long story short, I’ve been putting lots of hours into filling in the list of holes in my knowledge-base for just deploying a simple app that won’t fail out of the gate. Along the way, I’ve built a couple of really simple iOS apps — one being a SpaceX app that lists upcoming and past launches from the company. I was feeling pretty good about it until a coworker of mine pointed out the existence of Launch Library, which would mean making a much, much cooler version of the same iOS app. But again, I digress. The point here is that I have a decent idea about how to build the interface of the app. I’ll have a pretty decent idea about how to build a scalable API. Afterward, I just have to fill in the following knowledge gaps:

  • Designing a game I’d want to play (more on that next)
  • Building a secure interface to manage the quiz questions and other administration tasks (pretty simple, actually)
  • Actually deploying the React Native-generated app to the Apple app store (and beyond!)
    • Releasing updates without breaking previous versions
  • Handling user feedback
  • Making it accessible (this is 2018, people.)
  • Handling in-game purchases (later. Like, way later.)
  • In-game tutorial? (Even more later-er.)

After I complete my course work on more advanced React/Redux along with AWS Lambda, I’ll have done most of the heavy lifting for building out the back-end of the game. The question at that point becomes, “what is the game?” Odd, you’d think that would have been the first question asked and answered, but that’s not how I do things apparently.

Designing a Game I’d Want to Play

Ah, the crux. Because the insanity of building such a simple app is that even after I’ve done all the coursework in preparation for building the minimum-viable-product version of the game, I still have to come up with a very simple beta version of this thing with at least an aim toward a future version that won’t suck.

In the previous post, I was thinking of building out a pyramid style game, but after more consideration, I think that’s a bit too complex for the early version. My wife recommended I go with something more like Trivia Crack or Trivial Pursuit, where you basically just answer questions in different categories to fill in pie slices to win. This presents its own set of unique hurdles, none really insurmountable. I wouldn’t want to copy their game either, because I don’t necessarily need people to compete against each other (yet) but there are things I would like to, uh, borrow:

  • The quiz interface (generic to all quiz apps)
  • The category spinner (although, this still takes some thought)
  • General structure (New Game > Answer X Questions w/ 3 Lives > Get a score or lose)
  • Interstitial ads and action-based ads (Part of me really doesn’t want to use ads for anything, but then again I’d like to get paid for something I’m putting so much time and effort into.)

So the first game, simple as it might be in concept, will still take some fairly involved designing. I can always iterate on it later or even release a separate version that utilizes the same questions API. Clearly, the next step (after completing the coursework mentioned earlier) is to create a full sort of storyboard of the game from A to Z. Once that’s done, I can start developing some simple artwork and a theme for the UI/buttons/etc.

Really glad I didn’t get stuck in the conception phase, but here’s hoping I don’t get stuck in the early stages of the inception phase.

$_

Just a quick note about using the $_ C-shell short-cut (available in Bash and ZSH!).

Firstly, if you’re not aware, here’s the man page entry on it:

$_ Substitutes the command line of the last command executed.

In other words, it takes the last argument from the last command you entered, and substitutes it in.

Here’s a quick example usage:

$ cat npm-debug.log
...
$ tail -f $_
...

In this example, the npm-debug.log gets substitutes into the tail command and we are now following the output of said log.

Another nice usage is when you’re just listing directory contents but don’t want to have to type the same path in. Yes, you could use !! and just edit the command but that’s not always the quickest way. In ZSH, you can just use $_ without even typing cd and it will take you to the desired directory.

Most commonly, I use this command on long file names to avoid re-typing them.

git branch shortcut in shell

Just a really quick post about a Git branch shortcut that has been saving me some keystrokes (and therefore, time):

git push origin $(gitbranch)

The idea here is to automatically find the current Git branch, substitute it into the command and use that rather than typing out the branch name, which, as we know, can get quite long:

git push origin 300-fix_some_bug_with_descriptive_branch

We can fix this by putting a simple alias in our ~/.aliases file or the aliases section in our ~/.zshrc file:

alias gitbranch="git rev-parse --abbrev-ref HEAD"

Close your terminal and come back in and it should work straight away.

No more typing out really long branch names or haphazardly going through Bash history in hopes to get the right branch name.