#group coding

So I've fallen behind on the weekly blog posts, in part because we've moved into the final phases of working on group projects and breakable toys. I've gotten an unbelievable amount out of both, and thought I'd write a quick summary of what I did and what I learned on the group project.

First of all, here it is!

We worked in groups of four, and the assignment was to create a review sites of some kind that hit certain technical requirements (basic CRUD, authentication, image uploading with AWS, etc). We chose to review food trucks around the Boston area. Figuring out how to split up tasks while using Git workflow was challenging initially, as in the early stages of a rails app every feature you could implement depends on so many different files in the app that it's almost impossible to avoid merge conflicts. This turned out to be a good thing in some respects, as we got an intensive crash-course in using Git and after a few snags, could work together and separately very smoothly.

Once we had basic CRUD actions working, we split up more ambitious tasks amongst the group. I had the idea of populating our database with data from an API, and found Street Food App. The API was pretty easy to use and has scheduling information available as well, but I was left with the problem of keeping our website up to date without constantly hitting the API with requests. I ended up using Sidekiq to make scheduled asynchronous calls to the API, without slowing down our site or overloading theirs. That was fun to implement, and I ended up writing a lot cleaner code along the way, as I was introduced to the idea of helper objects. 

Testing API integration approved to be a particularly difficult challenge. You run into the same problem as with the regular app, but intensified - how do I test this without overloading the API and bogging down my test suite? I thought the VCR gem's method of recording a successful HTTP call once and playing it back to you after that in the testing suite was pretty clever, but a speaker from Pivotal labs today pointed out that it's not a great way to test how your app handles failed API calls. I originally considered writing a whole separate app that could spoof the actual API, and then having my test make calls to that (which apparently people do sometimes!), but that seemed excessive for our purposes. I'm definitely interested in API integration testing though; it's a problem with so many angles and a lot of potential for efficient, slick solutions.