Hack Reactor

FitRPG: The Gamification of Fitness

An RPG mobile app like no other – get fit and turn your fitness data into skills, experience points, and HP to engage in battles against your friends

Fitness trackers like Fitbit, Nike FuelBand, and Jawbone all work to solve a common problem– motivating users to get fit and stay fit. When I first started using Fitbit, I was inspired by seeing my data every single day. My dashboard was either a blunt reminder that I was not moving very much, or a beautiful screen filled with all the goals I’d accomplished that day. I felt rewarded when I received a badge or passed a fellow Fitbit friend in the rankings. But after a while, the badges were all the same, and I lost motivation to try to surpass my friends.

Screen Shot 2014-06-09 at 12.20.15 PM

Why? Because a fitness tracker is just that–it tracks your fitness, but it doesn’t add any additional features or rewards for motivation. That’s where FitRPG comes in, a mobile app that uses the data from Fitbit and turns it into a fun game that constantly inspires the user to walk more, sleep more, and work out more.

Our team (Amira Anuar, Conor Fennel, and Matt Gutierrez) worked for 2.5 weeks on this Hack Reactor group project. We created an app that allows you to sync your Fitbit and see your steps, sleep, logged workouts, and more become transformed into strength, endurance, HP, dexterity, and other attributes your character can use to battle your friends or go on quests.

   screen1 screen2

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Sleep to revitalize your HP. Log workouts to increase your strength and dexterity. Increase your steps to improve your experience and endurance.  Battle your Fitbit friends to steal their gold. See how you rank against other players in the leaderboard and increase your ranking by battling bosses and leveling up. Go on timed solo quests, which range from walking 5,000 steps to running a marathon. Win gold and experience if you succeed.

To get started, just download the app from the Google Play Store and log in with your Fitbit account. For any further questions, you can view the FAQ here or email our team at fitrpg@gmail.com. iOS version coming soon.

Take fitness to another level, literally.

Mobile Authentication in Ionic with OAuth Through External APIs: Fitbit Pt 1 (Server)

Shameless Plug: The following steps were used in the creation of FitRPG, a fitness gamification mobile app. Download it in the Play Store now!

During a 24 hour Hackathon, I was able to fairly efficiently allow users to authenticate through Fitbit login via a web browser. I primarily used OAuth and passport. However, when I decided to create an Ionic mobile app that allowed users to authenticate client-side through Fitbit/Jawbone (and really any external API that does authentication through OAuth 1.0/2.0), I ran through several issues and could find very little online support. In the end, it’s really not all that complicated–the key is we have to use our server-side to authenticate users, and we need an in app browser client-side.  It’s important to note that every API is a little bit different, and while I cover only Fitbit authentication in this post, the same general concepts can be used for other APIs as well. This post covers the setting up of the back-end, my next post covers the setting up of the friend end. You must do both for this to work as they depend on each other. Make sure you get your consumer key and secret from Fitbit upon registering your app.

Server-Side (Requirements: node.js and express 4.0)

Step 1: Set up Passport  First, we set up Passport, authentication middleware for node. Passport authenticates requests through ‘strategies’ you provide. In other words, we tell Passport what requests to authenticate, and it provides hooks for controlling what happens when authentication succeeds or fails. To do this, we jus require and then initialize it. Screen Shot 2014-06-07 at 12.55.24 PM

 

Step 2: Set Up Your Strategy with Passport Strategies are what Passport uses to authenticate requests. You can use them to verify a username/password combination, for instance, or to delegate authentication to OAuth, which is what we are doing in this situation. Before passport can ‘use’ a strategy, we have to configure it. Usually you do not have to create the strategy yourself–Passport has a pretty comprehensive set of over 140 authentication strategies that cover social networking, API services, and so on. I used the fitbit-passport strategy. On web, the fitbit-passport works fine as is, but on mobile, there is a tweak we want to make so that the login page shows up as mobile-friendly. I ended up having to make a copy of the node module and storing it in the body of my app files. Change the line that assigns options.userAuthorizationURL to:

Screen Shot 2014-06-09 at 2.28.32 PM

 

Step 3: Configure Your Strategy with Passport To configure the strategy, you must create a new strategy and pass in a) an object with your Fitbit consumerKey, consumerSecret, and callbackURL (more on that later), and b) a callback function that occurs once authentication is successful–this function will receive the token, tokenSecret, and profile from passport. Finally, you tell passport that it needs to ‘use’ that strategy.

Screen Shot 2014-06-07 at 2.07.11 PM

Step 4: Create Your Routes I used Express 4.2, and express.Router() to handle my routes. When my site goes to ‘/’ it uses the FitbitRouter. I could have also done “app.use(‘/fitbit’, FitbitRouter)” and that would have handled all of the routes on my site that start with ‘/fitbit’. In this particular case, my authentication page is just at mywebsite.com/auth, so that is where I will direct my mobile app to when I want to authenticate the user (more on that later). Step 5 covers the logic behind lines 4 and 5, but if you just want the code, skip to step 6 for the function in line 6. Screen Shot 2014-06-07 at 2.14.43 PM

Step 5.1: Get the Temporary Access Token The only endpoint we need to write is for that last route, as the first two just use the passport middleware. However, it is important and useful to understand what is going on. First, when we have a route that uses ‘/auth’,  which is the route we direct users to when we want them to authenticate via Fitbit. On our client side, we will be opening an in-app browser that goes to this url (see Pt 2). When we go to this page, we use passport.authenticate(‘fitbit’) as middleware, with ‘fitbit’ referring to the strategy we’ve declared earlier. Passport does work in the background to do the first step of the authentication process. What’s basically happening is passport then sends a post request to Fitbit (taken directly from Fitbit API documentation):

Screen Shot 2014-06-09 at 2.13.08 PM

Fitbit then sends back a response with a temporary OAuth token, which Passport receives and then uses to recreate a redirect url with, which looks like this: https://www.fitbit.com/oauth/authorize?display=touch&oauth_token=47617140d6906e7db65ac71df26290c0. The temporary oauth_token expires upon usage or within a few minutes. So to summarize, the middleware works to create that token and redirects users to a Fitbit login page where they can fill in their username and password.

 

Step 5.2: Get the OAuth Verifier Once the user is successfully signed in, Fitbit will redirect the user to the callback that you have provided, which in this example is the route to ‘authcallback’ (see step 3 above). The callback URL also includes Fitbit’s response, with the temporary OAuth token and a token verifier, which looks like this: http://example.fitbit.com/app/completeAuthorization?oauth_token=c5a8b2ff2a20524381083b1fe172fdc1&oauth_verifier=car3fbtjvralpv4kvba65arls2 With this verifier, passport (which is again included as middleware for that callback route) does another POST request to Fitbit, which looks like this. Screen Shot 2014-06-09 at 7.33.01 PM

Step 6: Save the OAuth token and OAuth token Secret Fitbit’s request comes back with the OAuth token and OAuth token secret, both of which you will need to access the user’s data in the future. Passport sends the token and tokensecret to the callback function shown in step 3. Passport also does additional work of getting the user’s profile for you.  From this point, it’s up to you what you do with that information, but I recommend saving the token and tokensecret, and then using fitbit-node‘s requestResource function to retrieve data for that user. Once you have the token/tokenSecert, it’s pretty straightforward from there.

Step 7: Respond to the Client At this point, our client is waiting for a response from our server, which is the responsibility of our function ‘getOuthToken.’ All that function needs to do is redirect to a url that will basically notify the client that the process has completed, and the in-app browser can be closed. In my example below, we use JSON web tokens, which are tokens generated to ensure the security of our app (the user must make resource calls with this JSON web token). Your app can capture the ‘oauth_token’ in the request, and send that back to the client to save, or your app can merely redirect to any link, as long as you check for that in the client side. My app sends the JSON web token back in the url for the client to capture. Screen Shot 2014-06-09 at 7.59.56 PM
That’s it! 
You’re done (sorta – you need to implement the client side on ionic – see next blog). Once you complete these steps, your user has signed in via Fitbit! As I said before, if you want to make resource requests on behalf of the user, I’d recommend using fitbit-node. Good luck, and please comment if you have any questions.

Which Cohort?

In my interview, I was told the soonest available cohort was in June, so I said that would work great. Turns out, though, that there’s a opening for the April cohort. I’ve been trying to talk myself through the pros and cons of starting earlier vs. later, and I’ve discussed with several people. These are my conclusions thus far.

April

Pros

  • My ultimate goal is to be a software engineer, and this means I can start going for that goal earlier!
  • Spending less time doing tasks I’m not particularly excited about at my current company
  • More time doing something I love
  • Less time earning my current (so-so) salary and more time (hopefully) earning a higher salary post-HR
  • I don’t have to wait as long!!! Super excited to join Hack Reactor.

Cons

  • Won’t have the full tuition saved up yet so I’ll have to defer or take out a loan
  • May feel less prepared because I’ll have less time for the pre-course curriculum
  • Will feel like I’m leaving my company in a time that I am very useful/integral

June

Pros

  • Will have saved up the full tuition amount
  • More time to transition out of current company and see certain projects to completion
  • Due to above, may have more to put on my resume in terms of accomplishments
  • A lot more time to spend going over the pre-course curriculum multiple times = feeling more prepared at HR!

Cons

  • Have to wait longer and drag out tasks at current company
  • Will be programming intensively through the summer (slightly unpleasant due to years of conditioning in school with summer breaks)

Most of my conversations with people have led to my leaning towards April. I’ve emailed asking if a small deferral amount would be possible if i were to do the earlier cohort. I won’t flip a coin, but regardless money is still helping to decide this for me. </cheesy>

Hack Reactor Admissions Decision

My interviewer told me I should hear back within the week, but if not that I could email her and she would reach out to Kristen, the admissions manager. I’d read a lot of other blogs where people had heard back within a few days–some even the next day! So, I had that in mind…

After my interview, I wandered SF and then went to a Women Who Code iOS workshop, which was pretty fun. I thought it’d be cool to learn Objective-C because then I could help the mobile developers at my company. I made my first (very basic) app! The next morning I woke up at 4am to catch a flight to Colorado to go skiing! Every time I had service in the mountains, I checked my email. 5 days of skiing came and went, and I hadn’t heard anything. It was torture! On the other hand, I braved my first Blue, which was initially terrifying and tough but eventually very fun and gratifying. Just goes to show, not much worth having or doing comes easily :)

Finally, a week passed, and I thought–maybe I got rejected. If I’d gotten accepted, wouldn’t they have emailed me earlier? I was getting tired of repressing my anxiety, so I emailed my interviewer a fairly enthusiastic follow-up, that evening. She emailed me back at 3am, letting me know that she had reached out to Kristen, who should be getting back to me soon. Her email was pretty devoid of any emotion or indicator of my admission result (which was probably intentional) so I gritted my teeth and forced myself to go into the office and focus on work. It was an abnormally ridiculously busy day.

One funny thing I should mention–I’m part of the Hack Reactor Meetups group, so I constantly get emails “from Hack Reactor” which always made my heart skip a beat and then I’d realize it was from the meetup group. I kept expecting each email to be my admissions decision.

Finally, in the midst of being really busy in the office and trying to do a million things at once, I got an email from Kristen, and without really thinking about what it was, I opened it.

“Hi Amira, We are excited…”

Stopped reading. Glanced at the email header. My admissions decision! I got in! A second after that my boss started talking to me, so I had to save my mini-celebration for a bit later.

But. So. Excited!

Hack Reactor Interview

Had my technical interview with Hack Reactor!

I think it was one of the most nerve-wracking experiences of my entire (recallable) life. The interview itself, in retrospect, was not that nerve inducing, but I was so anxious/nervous that I gave myself a stomachache from 20 minutes before the interview until about three hours later. Unpleasant feeling. It was my own fault, of course, but it made me realize how much I wanted to be accepted. Even when it came to college acceptances, I was pretty confident I would get into at least one good school, and didn’t have one top pick that I was desperate to get into. At Hack Reactor, I psyched myself out before the interview even started, which definitely affected my performance. I also definitely spent way too much time beforehand studying things that were much more advanced that never got covered in the actual interview–like regular expressions, recursion, etc. I don’t regret studying those things, as I enjoyed it, and would want to study them anyway, but I think I could have prepared for this technical interview a little bit better had I not spent so much time on those concepts. I’m still kicking myself for not getting things as quickly as I normally would, and making some stupid mistakes. That was my first real experience coding under pressure–many more to come I hope? :)

As for the interview itself: My interviewer was a bit late due to catching a train up, which was fine, but then she walked in a bit frazzled and hurried, and then that made me feel frazzled and hurried too, instead of calm, which is what I so desperately wanted to feel at the time. The interview process has since changed, and is now just the preliminary admissions challenge, the coding project, and then one technical interview… so the main majority of your acceptance ends up resting on the interview. My interviewer started out by leading me to an open computer on which she opened up Sublime. She then asked me to describe my background, where I was coming from, etc. This part was easy for me–I could probably talk for 20 minutes about my path and what I’ve experienced and what made me decide I wanted to be a full stack developer (maybe another blog post some other time). I gave her the condensed 5 minute version though, but I’m pretty sure I conveyed the very true fact that I am 100% dedicated to this career goal, I very wholeheartedly would love to do Hack Reactor, and I am willing to jump all sorts of loops and obstacles and difficulties to reach my goals.

The technical part was actually fun, though I was also nervous and my brain betrayed me a few times, so it could have been more fun. However, my interviewer was very patient and walked me through parts I didn’t understand. She gave me hints towards my answer, without ever giving me the direct answer, which I really liked. If I hadn’t felt so much pressure from her watching me, I probably would have just sat and chilled there and just more slowly thought things out before typing, but oh well. I tried to talk out loud too so she could understand my thinking process, but the talking out loud skill is something I have to work on. I usually take a minute to think, and then talk. Instead of just think-talking, which is what I ended up doing. -_-

In any case, the questions themselves weren’t all that complex–I’ve written much more complex algorithms. They were interesting, required a neat way of thinking, and mostly required writing functions/callbacks. I completely understand how they work, even though my versions were usually a bit more complex than they needed to be. It was pretty awesome to see my interviewer turn 4 lines of code into…one. Coderbyte ended up being wholeheartedly useless, but I guess it would have been useful had I had a first interview.

After that, she let me ask her any questions I had, and so I asked her a few, but to be honest there is so much online literature out there in blogs and the HR site that any questions I did have, I’d already done a good bit of research on. I enjoyed speaking to her, but for some weird reason I just kept getting the impression that this part was rushed and like it must be a pretty automatic process for her and she just needed to be somewhere else. Maybe that was all in my head–she was very nice, but she just spoke quickly/hurriedly. In any case, by the end of it I can’t say I really have a clear idea of how the interview went. She basically said that in terms of personality fit, I have no issues. In terms of technical, I think she said I did fine, but I guess I won’t know for sure until I hear back!

I will be checking my email a lot for the next week…

Applying to Hack Reactor

I think I have literally read every single scrap of online information on Hack Reactor–blogs, quora, twitter feeds–you name it. I’ve looked into other dev bootcamps, but so far Hack Reactor fits all my wants/hopes:

  • Intense and immersive
  • They seem to actually care about their students
  • Emphasis on computer science aspects and software engineering–not just making web apps
  • Loving their curriculum and that they give you a TON of pre-course work
  • They don’t start at the beginning — I don’t want to spend the first two weeks re-learning the basics
  • Generally successful job placement
  • I’m fairly new to Javascript, but so far really enjoying the language!!
  • High quality instructors
  • They’re dedicated to selecting the best, so I would be among and learning from the best :)

The application process has made me realize how impatient I can be when I really really want something. I submitted the online application, which was a pretty fast check of whether I know the Javascript basics, and waited impatiently for 5 days. Apparently you’re supposed to get an automated email response, but I never got it, so I had to email admissions and then they sent me the info for the take-home project. Maybe I completely missed something, but reading some others’ blogs and their struggles with the project made me think it was going to be ridiculously hard… It was a fun little project. I finished it in less than a day and sent it in, and then waited another anxious 5 days for another email with a link to sign up for an interview.

And so here I am, waiting impatiently for the interview date, and studying in my free time. :) My goal is to finish ALL the coderbyte problems (hard included) but I still have about 6 of the Mediums left… and the hards look tough. Fun, but tough.