Stop Planning Start Coding — Day 3 Final Project

testing in Angular(missing you Rspec), overplanning, overcomplicating and rejigging

Kevin McCarthy
kevins daily makers academy blog
3 min readMay 6, 2016

--

As a group of 3 we spent the morning with two trying to figure out the Spotify API calls and how to get the random song out and one working out how to test for $state.

Too Much Diagramming

We had a lot of diagrams and plans and discussions about how we could possibly test drive our controllers and factories and services and mocks and just all the things.

our magical diagrams which really did diddly squat

I’m a huge fan of diagrams, love understanding conceptually what’s going on, the fabulous ideal state on the page.

However they are also a great way of procrastinating diving in to figuring out the really hard messy task of creating tests and figuring out angular syntax. Also clearly this isn’t super agile planning out so many steps ahead. We lost about an hour I’d say by not picking something to do and instead looking too many steps ahead and trying to put everything together.

Overcomplicating by trying to simplify

We eventually got stuck in trying to mock a Spotify Wrapper module for a unit test. We were injecting this into a service which our controller would call on. The wrapper function was called SpotifyWebApi. This caused us all kinds of bothers. Re-reading the above sentence we clearly were not doing the absolute minimum to move forward.

After a couple frustrating hours we decided figuring out how to mock a service injected into another service was not the goal of the project and we would try just making the API call ourselves. This was something we’d done before and got us moving forward. Sometimes if something is incredibly complicated then maybe its not the most appropriate solution.

Rethinking design

Beyond that we made some good progress on our design. Previously we planned that the first screen would return a random track from an album of your choosing.

As we discussed how the game would actually worked we discovered that we don’t want someone to here the same song twice, its just not fun. Therefore once you’ve chosen an album should be option to keep going with that album once first song answer has been revealed. Therefore we need to remove listened to tracks from a list, therefore we need a list (or in this case an array).

New plan, when you choose an album it calls on Spotify API getting all details of the album in a JSON object. We iterate through the track details and pop the bits we need (track name, artist and preview_url) into an array. We then shuffle the array so the tracks are in a random order. We then play and pop off the last track each time till there are none left. This means we only need to do the API call once per album and only need to shuffle once.

All the above now seems blindingly obvious but its only when you get into the flow of things that they come up.

Plan for tomorrow

Refactor our API call and our iteration through the JSON. Red Green Refactor! Then create our shuffle method (I must find out why Javascript doesn’t have all these seemingly useful methods by default, there must be a good reason right?).

This is part of my daily blog series while I attend Makers Academy coding bootcamp. If you’d like to read more you can find them here.

Makers Academy Week10 Day3

--

--