With this project, I decided to go with a tool that allows a podcast host to create & manage guest interviews. From the get-go, I wanted to build it using test-driven development; I’ve been reading rspec tests my entire time at Flatiron School, so I wanted the experience of writing tests first and writing code to pass them (more on this later).
The ideation of this project went through a couple phases. At first, I wanted to build an app in which you could enter the make & model of your major appliances, get their rated kilowatt-hours, and calculate how many solar panels would be required to fulfill their power requirements. After doing a bit of research, I learned that I would have to integrate with a number of API’s (one for web search, one to convert zip code into latitude-longitude, and one to calculate the solar energy at your location), and as of yet, integrating with API’s hasn’t been a part of the curriculum. Considering that I’m using a new building strategy, this felt like a big ask for the time that I had available. I had no doubt that I would be able to build it, but not within the time constraints. I’ve filed this away as a future side-project, as I think it would be a useful application.
So I was back at square zero, and had difficulty coming up with another project idea. With every project, I want to build something of personal significance, and the only other subject that came to mind was podcasting. I attended a “show and tell” of other students’ projects, and that spurned the idea to create the Podcast Interview Manager.
So I got started on writing the tests. I definitely enjoyed the process, it forced me to think on a very granular level about what needs to happen. I started with the model tests (what’s known as unit tests in the industry), and I was able to knock them out relatively easily. The feature tests proved to be more problematic and took more time to write-out. The process of writing tests first really helped form a mental picture of the design & path a user would take; this definitely helped when utilizing Ruby on Rails, which has more moving parts than Sinatra.
I got the model tests passing relatively quickly, but ran into some roadblocks when I started working on passing the feature tests. I realized that I was debugging the tests more so than actually building the app, so I decided to put the tests aside & just build, then run the tests later. Then I realized I was testing for validations of foreign keys’ presence in the join tables, which a user would never enter or interact with directly, and this made creating the interview & guest objects a hair-pulling experience. So I threw out the thought of running feature tests all together; making the necessary edits wouldn’t have been difficult, but it would take away valuable time. As I built, I kept it open in my browser, so the failing tests are more due to poorly-written tests than bad code.
Another challenge I had was creating the forms; this was due, in part, to needing 2 nested routes and the aforementioned foreign key validations. I discovered my error in creating validations for the foreign keys when I created the interview form, which required building the guest objects simultaneously. Having two nested routes required having multiple records & options specified in the arguments, in addition to accepting nested attributes.
Lastly, integrating oauth (otherwise known as single sign-on) was a bit of a challenge. I had no interest in using Google or Facebook due to their policies regarding personal data. I was considering Twitter due to its wide usage, but after some research, I learned that their system doesn’t return the user’s email. I used email as a login requirement, so I eventually went with GitHub; I don’t know how many podcast hosts utilize GitHub, but it returns the information I needed and provides a smooth oauth integration experience.
The app was definitely functional, but it was ugly! So I looked around for some CSS that gave it the visual pop that I wanted; normally, I like getting into the nitty-gritty & tinkering, but I was on a limited timeline, and why not stand on the shoulders of giants? I tried out site.css from mergerecords.com, then added a couple lines to center the content, as well as a color gradient, and it provided the look that I was going for.
While taking a test-driven development approach didn’t quite turn-out the way that I wanted, it strongly encourages a design strategy that I enjoy, and revealed flaws in my thinking in a way that I didn’t have to just throw everything away & start over.
Podcast Interview Manager is released under GPL v3, and available on GitHub: https://github.com/kerneltux0/podcast_interview_manager