What I Worked On Summer 2020

COVID-19 upended my second semester of college. After two months without a break, I awaited spring break like a child waits in line for the bathroom - desparately and impatiently. When I returned, however, I realized that my spring break would be six weeks longer than expected. Since I was stuck inside, I decided to focus on the things I’d always wanted to do.

Web Development

I followed a Youtube series by Corey Schafer to learn how to create a website. If you’re interested, Corey teaches viewers how to make a blog using Python’s Flask framework. My father had promised to send me food while I was in college if I created an app to order it from him. I figured a web app counts too. I built out a user interface, cobbling together skills I learned from Corey Schafer’s tutorial and from Google searches.

Here’s what I learnt.

  • Learning how to find information on Google is a skill
  • Watching someone else code and then trying to emulate them is the best way to learn how to code
  • Making mistakes and solving them yourself is the best and most rewarding way to get better at something

I was watching something come together before my eyes, and this feeling is the best part of front-end development. A happy distraction followed. A few friends from Georgia Tech and I decided to enter the EGHI/GT Hackathon to hack COVID-19. Our group lead suggested that it would be valuable for people to gauge their individual risk from COVID-19. He called it a risk-o-meter.

Machine Learning

After developing a web app for the past week, I started to envision what it would look like. I also remember reading about and unsuccessfully implementing a type of machine learning model in high school called the naive bayes algorithm. The “bayes” part of this algorithm comes from Bayes’ Rule for calculating the probability of an event, and the “naive” part comes from the algorithm’s assumption that different attributes are independent (that is, we can multiply them together).

Bayes Rule

I don’t want to get too much into how it works here, but if you’re interested there’s many great examples online, such as this one. After scouring the plethora of resources that have emerged to visualize the spread of COVID-19 (including this fantastic one by Johns Hopkins), I found a set of probabilities that would help me create the model at the CDC website.

This data gave me an individual’s risk of COVID-19 based on their pre-existing health conditions. I combined this data with age-based data I found on the Lancet journal and finally integrated this model with hospitalizations by state found on a public API. I wrote the model in Python and connected it to my barebones user interface with a Flask server. Finally, I hosted it on Heroku and sent it to my friends. If you’re interested, it can be found here.

Mobile App Development

It became clear to me, however, that the best way to promote usage of the app and facilitate widespread engagement was a mobile app. I choose to use React Native. After recently starting to develop mobile apps natively in Swift however, I realized I made the wrong decision.

A major benefit of React Native is that it is cross-platform, so developers can deploy to the App Store and the Google Play Store from a single codebase. What followed was furious Youtube-tutorial watching and practice using Facebook’s React Native API. Software development (or whatever you would call what I was doing) is a harrowing experience. Oftentimes watching my app in the simulator felt like holding a newborn baby. What’s in the balance is something beautiful, and I’m constantly afraid of losing what I’ve worked so hard for.

Everyday I added a new feature. I used React state to manage my age, zip code, and pre-existing health condition fields. I had to reconfigure and deploy my COVID API multiple times to account for these changes. I also built a separate API to validate zip codes. I integrated Google’s MapView into the app and after days of tinkering and frustration I finally moved towards deployment.

Deployment

Unfortunately, deployment was the most painful part of the process. Apple needs screenshots for every iPhone device, so I needed to run the simulator with a different deployment target 10 times. Afterwards, I needed to provide a privacy policy and terms and conditions. Luckily, I found auto-generators for these online and managed to host this information for free on Flycricket. Flycricket also allowed to me create these sweet screenshots of my app.

I glued together two screenshots for this image and probably could have done a better job.

Xcode took my app and generated a binary that it could push to the App Store. Finally, I could submit my app for review. Only a few hours after submission however it turned out that because my application collected user’s medical data I needed an organization account to submit my app. Now, there are numerous hurdles to obtain an organization Apple Developer license which you can read about online. My dream of being a published app developer would have to wait.

The next few days, my mind burned with my defeat. I had wanted to be an iOS developer since middle school and to come so close but not go all the way hurt. I thought of new avenues I could pursue.

Over these next few months, I will focus on learning machine learning and becoming Tensorflow Developer certified. I will start and stick to a training and fitness program, and I will make it onto the App store.

Stay tuned for updates on how these challenges are going!