Creating Tech For The Culture: Working on Side Projects That Have Impact
AfroTech is an event hosted by Blavity that is a platform to highlight black excellence in technology. This year’s conference was held in Oakland, California. This weekend had its fair share of amazing events and activities. The conference featured talks by industry professionals, expo floors were people that looked like me were not only search for positions but hiring for them. Likewise, local organizations such as “The Hidden Genius Project” were showcasing the impact that they are making in the community through their outreach to the broader community.
It was essentially a Black Renaissance of change-makers, visionaries, technologists, and entrepreneurs. It was a contagious environment and I walked out different from when I entered that weekend. One of the talks that touched me on a personal level was my friend and peer Kyle Woumn’s talk called “6 am in Atlanta”. In this brief talk, he highlights his thoughts from ideation to execution as he talks about he creates his famed, “Drakestagram”. An application that allows users to get lyrics for their favorite Drake lyrics and put it on their Instagram as a caption. As Kyle puts it, “It was a simple idea and I decided to just go after it”. His app though, “simple” required a lot of persistence, especially when he had issues trying to work around implementation and when was the right time to bring the MVP to the world. His efforts paid off, his app went viral with a peak of 16,000 organic searches in counting to this day.
After the completion of his talk, the room exploded with applause. Not only was the app visually appealing, but he brought the data that confirmed the impact of “Creating Tech For The Culture”. During the Q & A session, it was a mixed bag of people congratulating him on his success, his ingenuity, along with asking him did he try to monetize.
What I loved about this talk, in particular, was that it had me in a self-reflective mode. Up until this point, all my side projects either solely benefitted me or had no significant value beyond being a portfolio of my ability to code. I took a lot from Kyle’s talk, but the main thing I had laser focus on was finding ways to share or impact my culture, from the very beginning.
With this new flame of conviction, I went ahead and asked Kyle’s permission to emulate his app and create a Travis Scott version called “Cactus Chorus”. He gave me the okay ( I didn’t want to be a biter but I liked the idea) and began designing my own version of his app.
The rest of this blog post will highlight how I used the lessons from his talk and implemented my own version of the “Drakestagram” app.
First, Market Research:
Usually, in the real world, companies pay thousands to gather user research on a low fidelity version before they begin working on a new project. I did not have thousands, so I did the next best thing, I asked my friends, “What they thought about a Travis Scott Lyric app?”. Since the tool didn’t exist, they thought the idea was pretty cool. That was the only validation I needed since the project was so low stakes so I began moving to the next phase.
Second, Designing:
I didn’t want to spend months working on this project, so the interface had to be clean and had to get straight to the point. All I needed people to do was hop on and get some lyrics, nothing more, nothing less. I actually designed an entire ecosystem (which I might implement later), but until then the lyric functionality is what I needed for this base version. I used Figma for the design since it was free and has a smaller learning curve.
Like Kyle, I wanted the rights to the use of images used. So I searched the internet for some dope photographer shots of Travis Scott. Astro World Festival was ironically around the time I began working on this project. This made it easier finding hashtags of artist who had dope work, so I reached out and got in contact with a photographer that had the best shots.
Third, Implementation:
I so badly wanted to ask Kyle for the code to his repo, but that would take the fun out of exploring the technology needed to do this job.
I also wanted to make this project a bit challenging, so instead of making a monolith application, I used a microservice-ish architecture and split the front-end logic from the back-end. I used React for the visuals and used Ruby on Rails API only mode.
I used the Nokogiri gem to scrape the elements off of www.AzLyrics.com. There was an implementation of this that I saw online that was in Python, so I ported it over to Ruby. I created some simple helper methods to do the job of scraping the site. All was well and good, but I was hitting the AZLyrics web server so much they blocked my IP (so much for a simple project). I had to go through the whole routine of downloading the code behind an IP address and rotating the IP address until I could get all the lyrics text. Eventually, I scraped enough lyrics from the website where I was satisfied.
This code is the heart of the lyric parsing off AZLyrics.com, I used an IP Address to seed the DB. I passed in the parameters for the title by using a structured CSV file.
After making a makeshift API using the lyrics on Ruby on Rails, I just fed the data to the React front-end. I wanted this to be true to a single-page application so I made some modifications to only get access to the one route. I referenced this implementation from below.
Be warned that this disables Rails built-in CRS token, which is against convention.
It took a lot of trial and error learning how to work with props and state, but I botched together some responses and some components to force myself to learn the language.
For all of my side projects, I usually host my work on Heroku (because I am a cheapskate). Their basic plan free plan is cool, but the trade-off is that the server shuts off after 30 minutes of inactivity and can be very slow when trying to get a lot of traffic. I didn’t really care so I just stuck with the free plan. Testing in development versus production is always inconsistent, some of the CSS was breaking on the page, so it took about like 17 deployments before I could get my app to work together.
Here is some in-depth tech jargon on why it took so long for my deployments to work — you can skip this explanation if you want.
Heroku only allows one app to run, which required me to think outside of the box on how to serve both the front-end and back-end. Since I want with a microservice, they were two apps in one essentially. Thankfully Heroku allows post-deployment scripts to be run in package.json, so I ran the following script:
Essentially, after the deployment to the Heroku server, this navigates to the front-end client, builds the project, and copies it to the public folder of the Ruby on Rails backend
Last, More Market Research:
After getting the app up and running, now I had to get it out in the public. The two best ways I did that were using Reddit & Twitter. On Reddit, I found a Travis Scott fan page and basically shared my app and what I was up too. As long as you aren’t trying to get people to buy stuff, people are really happy with testing dope apps, especially if it’s their favorite artist. I received a lot of encouraging words on my post and people were generally happy.
After that, I took to Twitter and went under Travis Scott’s site and shared a video of the app in motion. It didn’t take as well as the Reddit post, but people still were interested and retweeted it.
Conclusion:
All in all, creating apps with the intent to help others is one of the many lessons I learned from my exercise of creating the Catcus-Chorus website. I could have just took Kyle’s talk at face value, but going to the motions of doing the project boosted my confidence. Building for the culture does not only give you the same opportunity to learn as a side project does, but you have the ability to make a wider splash when it comes to impact, which is the most important part.
