Streety

Website (mobile only) GitHub

The Idea

For our second and final group project at Lewagon, I came up with a web app for finding great, locals recommended, street food. I find that as travelers in a new country, we sometimes hold ourselves back from trying new foods, particularly street food. We may not know what to order, or even how to order which is often the case if we don't speak the local language. I went into this project intending to build as many features as I could in order to learn as much as possible.

Tech Stack

Coding & Challenges

Like with our first project, my group and I spent a lot of time planning our core features, database schema, and designs. Initial features included search, mapped search results, and a menu for each food stall. The menu would have dishes listed in Spanish and descriptions in English. To really stand out (and also to push ourselves), we added in a few more ideas:

• bookmarks
• user's food stall recommendations
• food dish likes
• a "locals recommended" food stall tag
• current location finder for search
• QR code scanner for menus
• walking distances and times
• sound bites for pronouncing each food name. (this and walking distances/times are the features I'm proud of most)

An early challenge was designing our database schema. It took time to figure out what models made sense and how we would create the associations between each one. It forced us to go back and think more about the user journey. To maintain a standard of quality with food descriptions, our database would be set up to include all Mexican food categories and dishes; that is to say, they would not be user generated. For the purposes of this student project, we only included a small number of dishes.

Bookmarks, walking distances and times, and sound bites were the most challenging features to build as they each had several moving pieces.

Bookmarks

Getting bookmarks to work involved learning things I was not familiar with and understanding how each piece connected to the others. To build the feature, I utilized helper methods, the js.erb file format, as well as the respond_to method, and turbolinks. I also learned to load javascript files only on the relevant pages to minimize code breaking.

Walking distances and times

Implementing walking distances and times was an incredibly fun and rewarding experience. I used the geocoder gem to transform food stall addresses into coordinates. I originally planned for users to type in their location, but decided to also include a “get current location” option to simplify the user experience. This was done by using browsers' native navigator.geolocation.getCurrentPosition() method. Lastly, I used Mapbox’s API for calculating walking distance and times.

Sound bites

Sound bites was the final big feature, one that came close to being excluded due to time. I was fortunate to receive help initially from the lead teacher at Lewagon. I felt unsure about the best approach. He provided some guidelines and even suggested I take the opportunity to build a background job with sidekiq (dev) and redis cloud (prod). It was entirely unnecessary at this project’s scale, but I learned a lot. I'm proud to say that I didn’t receive much hand holding when I got to coding as we both agreed it would be better if I tried on my own.

First I tested the Google Text to Speech API in my seed file and once I got the audio file to generate, I manually uploaded it to cloudinary to ensure they supported the audio file. I came to learn that Heroku will periodically and automatically delete files that are not part of the original deployment. That was perfect as I could just save the sound files to a temporary folder before it got uploaded to Cloudinary. I spent a couple days learning about jobs and then made sure I could get that to work in development using sidekiq. The job would run as an after_create action each time a new food category or food item was created. I ran into an error with active storage not being able to upload audio files to Cloudinary, but after lots of troubleshooting, I found out from their technical support that I just needed to update their gem. It was a wonderful moment when finally everything worked. The final task was getting it to work in production with Heroku and understanding their dynos and the need to use redis cloud instead of sidekiq.

Collaborators

• Victor Chiang, lead developer
• T.J. Zuvic, developer
• Rodrigo Sanchez, developer