Refactoring Artist Management in MyRockinApp Part 1

Adding artists has been an ongoing pain in my ass during the entire lifetime of this project for many reasons. All of those reasons have one root reason — when I want to get something done, I tell myself I don’t have time to learn how to do it better … and I spent all that time learning how to do it the way it is now … I want to keep practicing that …

TL;DR — I am taking the time to completely refactor (as well as redesign) the entire app so it is more efficient, elegant, and easier to use.

The horrifying current state of affairs

I add artistIDs to a new array. Usually, they’re artists I have yet to add, artists I’ve realized I didn’t have, or there’s a new class of Rock and Roll Hall of Fame nominees.

nominees.png

Then use the Spotify WebAPI to get their data and insert rows into the artists table of my database. I do this the most stupid way possible — by changing the value of a variable in a PHP file and then going to that URL in a browser.

Then, I … don’t judge me! … I’ve been manually adding lines like this …

artistInstances.png
Yes, I know my camelCase wasn’t consistent. That’s why I’m doing and writing this.

So that … um … I can … well … manually add them to the “Choose Artist” menu like this:

artistMenu.png

Needless to say, I’ve often remembered to update one of those files and not the other. Or mismatch artistIDs and artistNames.

Because my albums table has a foreign key for artistID (from the artists table) and the tracks table has a foreign key for albumID from the albums table … sometimes forgetting to add things in order of artist, albums, tracks is another pain in the ass.

Also, I have separate files and functions for each little task and purpose — and not in the good way you’re probably picturing in your mind. They’re all redundant and overlap in countless ways.

I’ve know there was a better way for a long time but I’m always busy and always in a hurry. But I’m fixing that now. I’m forcing myself to. There’s a growing list of things like adding genres and grouping artists i.e. Dio, Ronnie James Dio, Elf, Rainbow, Black Sabbath, etc. that — to keep my sanity intact — require me to create some forms and functions resembling code written by a professional.

I’m doing this now for two reasons — I have the time and patience … but, more importantly, I learned a mother-butt-load earning Udacity’s Mobile Web Specialist nanodegree as well as the other resources I discovered while completing the program.

Now is the time on Sprockets where I replace much of the PHP in the app with Javascript. All of the Front End stuff, in fact, will now be strictly HTML, CSS, and Javascript. The PHP will be hidden in the back likeĀ Geoff Nicholls and any other heavy metal keyboardist.

Advertisements

RoxorRescue for Disaster Search & Rescue

Graduating from the Mobile Web Specialist nanodegree program gave me the confidence to enter my first hackathon. The IBM Call for Code hackathon started at least two months before I heard about it so I’m only going to get a few evenings and weekend chunks of time in the now two weeks before the deadline but … I’m loving the project I’m working on.

Idea #1 would have required months of research and whatnot but it’s possible I could finish this (to some extent) in time to submit it.

RoxorRescue is an offline-first progressive web app using PouchDB and CouchDB. Submissions have to use IBM Cloud tools so I’ll be using Cloudant (for the CouchDB bit) among other products.

Here’s a concept for the GUI I madeĀ in Photoshop along with the current state of affairs.

Woo.png

It’s meant to be used on a mobile device and when I tested it there I was elated that the photo bit finally worked but …

notWoo.jpg

… a couple things stuck out … not the least of which was the inaccessible “Take Photo” button.

Post-hackathon, I’ll be welcoming any and all contributors during Hacktoberfest and beyond.