Create web version

Question

Create web version

Closed this issue 11 years ago · 26 comments

Would be cool to have web catalog for music here, probably maintained in a separate playlist (JSON?) file and updated with pull requests, with player or, at least, links to pages where you can listen to music.

Answer 1 · 2014-01-31T04:44:21.000Z

+1
I'd really like to take these links from Soundcloud, Spotify, Google Music, YouTube and create a web player that I could open up and let it work through the playlist. Potentially, there could be a rating system, or even a cloud-based popularity system for what to play next: "Up next XYZ, 10 others are listening to XYZ right now!"
Not sure if all of that is within the scope of repository. I would really just like a way to play all of these tracks without having to stop and manually open the next one from #1. 😄 Thanks!

Edit: And I would interested in helping out if I can!

Answer 2 · 2014-01-31T05:42:18.000Z

I worked on this a little bit - very plain, but good start. Here it is: https://github.com/vasilionjea/tastejs-links

So far it hits this endpoint https://github.com/tastejs/TasteMusic/issues/1/comments through the GitHub API and extracts the URLs people post and creates a link for each URL in the first 30 comments.

Next I would need to take into account the rest of the (paginated) comments via:
https://github.com/tastejs/TasteMusic/issues/1/comments?page=1, ...?page=2, and so on.

After that, big refactoring will be needed.

@sindresorhus if you want, I can fork TasteMusic and merge this stuff in with a pull request.

Answer 3 · 2014-02-01T00:30:16.000Z

I'd really like to take these links from Soundcloud, Spotify, Google Music, YouTube and create a web player that I could open up and let it work through the playlist. Potentially, there could be a rating system, or even a cloud-based popularity system for what to play next: "Up next XYZ, 10 others are listening to XYZ right now!"

Hot, yes!

Not sure if all of that is within the scope of repository. I would really just like a way to play all of these tracks without having to stop and manually open the next one from #1. 😄 Thanks!

Not sure either. Keep building it and we'll see.

I worked on this a little bit - very plain, but good start.

Nice!

I think it would be nice to do without a back-end. I see no reason for needing that. Might also be nice to use a framework like Angular or Ember for the player.

Answer 4 · 2014-02-01T02:56:31.000Z

Looks like we can definitely do it all client/browser-side!

Proof that CORS is not an issue

Endpoint: https://api.github.com/repos/tastejs/TasteMusic/issues/1/comments

Paste into JS Console on another non-GitHub page (with jQuery):

$.ajax({
url:'https://api.github.com/repos/tastejs/TasteMusic/issues/1/comments', 
method:'GET'
}).done(function(error, result) { 
console.log(error, result); 
});

It correctly returns the data as described: http://developer.github.com/v3/issues/comments/
No crossorigin problems with GitHub API!

Now to put @vasilionjea's comment parsing code into client side webpage.

Might also be nice to use a framework like Angular or Ember for the player.

I just started using Emberjs and am very impressed with it. I have yet to use Angular, however looking at the documentation I found myself liking Ember's API more. I would be very interested to hear the pros and cons of each, especially if we decide to develop this out further.

Update: I should have taken a closer look at GitHub's API documentation first: http://developer.github.com/v3/#cross-origin-resource-sharing

The [GitHub] API supports Cross Origin Resource Sharing (CORS) for AJAX requests.

Answer 5 · 2014-02-01T03:55:36.000Z

I think it would be nice to do without a back-end.

Looks like we can definitely do it all client/browser-side!

I agree it can be done only with JS. The idea for the backend script was for being able to do file based caching, basically to be able to save the JSON file locally on the server instead of hitting the GitHub endpoint on every page load.

I think GitHub allows only about 60 requests that can be made to its API without authentication, so saving the JSON file locally may be necessary if a hosted, web based version of this app is viewed by many users.

Edit: It might just be easier to do localStorage for caching! What do you think?

Answer 6 · 2014-02-01T04:08:31.000Z

Good points, @vasilionjea.

I think GitHub allows only about 60 requests that can be made to its API without authentication

It looks like 60 [unauthenticated] requests per hour, per client.

See http://developer.github.com/v3/#rate-limiting

For requests using Basic Authentication or OAuth, you can make up to 5,000 requests per hour. For unauthenticated requests, the rate limit allows you to make up to 60 requests per hour. (The Search API has custom rate limit rules.)

A possible solution would be implementing optional user Sign In and authentication, and then we could make more than a sufficient number of requests, per client.

The idea for the backend script was for being able to do file based caching, basically to be able to save the JSON file locally on the server instead of hitting the GitHub endpoint on every page load.

I would rather have GitHub handle the requests then have our own backend handling those requests. If we want to have the pre-parsed tracks in a JSON structure to be loaded, maybe would could store that data in the repository? This would require Pull Requests for tracklists to be merged. Then it would be loaded by making a request such as:

GET https://raw2.github.com/tastejs/TasteMusic/master/tracks.json

Ideally, the client would maybe make only a handful of requests to load all, or a select few, of the current tracks listed, parse the comments for links if applicable, and then store in memory or local storage to be played by the web player. Then the client would likely not be needing to reload for a couple of hours.

Edit: Another idea, for providing additional functionality without hosting the backend ourselves would be using an existing service, such as Clay.io, which has Persistant Data Storage built in, allowing us to provide features such as statistics on what the user has listened to most and potentially predict what track should be played next -- maybe the same GitHub user posted most of the songs that are replayed / up voted? Clay.io is for gaming and just a suggestion of something that I have used and enjoyed working with in the past.

That predictive functionality, again, may be out of scope; and potentially an add-on in the future. The core of this should be simple: play music recommendations by JavaScripters while JavaScripting!

Answer 7 · 2014-02-01T12:41:51.000Z

I think front-end only with caching in localStorage will work fine. No need to overcomplicate it with auth. 60 requests an hours per client is more than enough with caching enabled. Let's start with this and we can always expand later on.

Answer 8 · 2014-02-01T15:11:00.000Z

Agreed with Sindre. Even though I'd refer IDB over localStorage. :)

@passy - from his phone
On Feb 1, 2014 12:41 PM, "Sindre Sorhus" notifications@github.com wrote:

I think front-end only with caching in localStorage will work fine. No
need to overcomplicate it with auth. 60 requests an hours per client is
more than enough with caching enabled. Let's start with this and we can
always expand later on.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-33870496
.

Answer 9 · 2014-02-09T20:27:41.000Z

For moving forward, can we agree on a MVC framework? My personal vote is for Emberjs, however I lack experience with Angular and would love to hear someone else's opinions.

If using Ember, we could use: https://github.com/yeoman/generator-ember
For Angular: https://github.com/yeoman/generator-angular

Answer 10 · 2014-02-09T21:57:24.000Z

I personally wouldn't mind us opting for either Ember, Angular or just vanilla JS. I have more experience with Angular over Ember personally but I think our preference should factor in what works best for the devs that will be working on it.

Answer 11 · 2014-02-10T00:19:24.000Z

Lets try out Ember :)

Answer 12 · 2014-02-10T06:18:03.000Z

Quite honestly I would just go with vanilla JS, but because I'm currently trying Backbone (reading Addy's book), I would prefer Backbone over Ember. If I were to vote, it would be in this order:

Vanilla JS (perhaps with RequireJS, PubSub system, & Underscore/LoDash helpers)
Because It's plain old JS and gets the job done. Also it's an opportunity to learn more about JS APIs.
Backbone
Because I'm interested in learning more (currently evaluating for an app).
Ember
Because I work with Rails & Ember seems to follow similar conventions, which I already understand.

Note:
Currently I can be most helpful with vanilla JS but will try to contribute even if vanilla JS isn't chosen.

Answer 13 · 2014-02-13T00:06:59.000Z

I see valuable in a minimalist approach. We could simply use vanilla JS and create a one-page app, displaying a list of tracks and one main player.
By using Vanilla JS it would allow for a wider developer audience to contribute, and also abide by the KISS principle 😉.

I am going to pull and take a look at what you currently have, @vasilionjea. I assume it is in vanilla JS with Twitter Bootstrap and some working JS for loading the track links from the Comments in #1.

I agree with using RequireJS and other helpers. We should split it into components that can be required, such that development for support of Soundcloud, Spotify, Google Music and YouTube (etc) can progress concurrently.

Answer 14 · 2014-02-13T00:10:17.000Z

Sure, whatever works best for you is fine with us :)

Answer 15 · 2014-02-13T01:20:31.000Z

I just submitted a PR with some core changes. I moved over your code, @vasilionjea, to the new web app structure, and made sure nothing was broken from the changes.

Would someone with permission be able to build and push to gh-pages branch?

Answer 16 · 2014-02-13T02:04:53.000Z

SoundCloud

We will need to obtain a client id.
To lookup the track with the posted URLs, use the /resolve API request.
There's a Widget for embedding and playing tracks

Answer 17 · 2014-02-13T03:07:51.000Z

Since I don't use Yo, does anyone know why I'd be getting the following error?

$ bower install
path.js:360
        throw new TypeError('Arguments to path.join must be strings');
              ^
TypeError: Arguments to path.join must be strings
    at path.js:360:15
    at Array.filter (native)
    at Object.exports.join (path.js:358:36)
    at Object.<anonymous> (/usr/local/lib/node_modules/bower/lib/core/config.js:41:22)
    ...

I tried uninstalling and re-installing bower but no luck.
grunt serve aborts with this: No such file or directory /TasteMusic/app/bower_components

Update:

$ node -v
v0.10.15

$ npm -v
1.3.5

$ grunt --version
grunt-cli v0.1.9
grunt v0.4.2

$ yo -v
1.1.2

I can't get the bower version because it throws the error mentioned above.

Answer 18 · 2014-02-13T03:18:50.000Z

@vasilionjea, what're your current versions?

node --version
npm --version
grunt --version
bower --version

etc

Any luck so far?

Answer 19 · 2014-02-13T03:34:56.000Z

I can't get the bower version because it throws the error mentioned above.

Of course, silly me.

Try updating Node and NPM.

Mine are:

$ node -v
v0.10.25
$ npm -v
1.3.24
$ grunt --version
grunt-cli v0.1.13
$ yo -v
1.1.2

Answer 20 · 2014-02-13T03:57:11.000Z

Yeah... no idea what's up. I updated everything but nothing.
I might try to downgrade... or just have a beer instead! :)

Answer 21 · 2014-02-13T04:21:55.000Z

Try removing all NPM global modules
See http://stackoverflow.com/a/9283646/2578205

Then reinstall bower.

Is anyone else having problems?

Answer 22 · 2014-02-13T06:35:40.000Z

Finally after doing the following it worked:

Fixed Homebrew linking issue.
http://stackoverflow.com/questions/12607155/error-the-brew-link-step-did-not-complete-successfully
I had to add sudo in front of each pipe to remove all global node modules.
sudo npm ls -gp | sudo awk -F/ '/node_modules/ && !/node_modules.*node_modules/ {print $NF}' | sudo xargs npm -g rm
Not sure how bower ended up in bin/ but I had to remove it by hand: rm -rf /usr/local/bin/bower.
Set permissions so I don't have to use sudo when installing node modules.
sudo chown -R $USER /usr/local
Then re-install.
npm install -g grunt-cli bower yo

I believe the actual solution was to simply remove bower from bin: rm -rf /usr/local/bin/bower
Thanks for your help @Glavin001

Answer 23 · 2014-02-13T16:11:00.000Z

Glad to hear you found a solution!

Answer 24 · 2014-02-14T03:27:49.000Z

@sindresorhus, was this Issue accidently closed or should we continue now to open new specific Issues for feature requests and discussions?

Answer 25 · 2014-02-14T09:18:08.000Z

@Glavin001 better to have more targeted issues for each feature. Mind opening some?

Answer 26 · 2014-02-14T13:11:47.000Z

Makes sense now that we have the foundation. Will do.