search

lwholey / concert

Testing with Ruby on Rails
0 stars 0 forks source link

Site needs to be faster in creating playlist #2

Open lwholey opened 13 years ago

lwholey commented 13 years ago

Currently up to 15 bands are searched for a track on Spotify. On my machine this takes about 15 seconds (tested with the New Yorker site). There could be additional bands to search. I recommend the following approach:

lwholey commented 13 years ago

See commit 33d5431dfee2272f5eac . This is implementation is different than comments above.

lwholey commented 13 years ago

We should show a progress bar for when the site is creating the playlist

lwholey commented 13 years ago

Can we use caching to make the site faster? See http://developer.spotify.com/en/metadata-api/overview/#caching.

At the moment it seems like we're making serial requests, any way to change this to parallel so that we can get closer to the limit of 10 requests per second?

johnwilde commented 13 years ago

Maybe a way to create parallel requests is to create a new thread for each request. I agree that client-side caching would be very nice to have - do you know of any resources for learning about this? I bet there are some libraries that might help. Also, and unrelated, what do you think the best way to use this "Issues" page on Github? When should be choose to "edit" the issue vs. add comments? Should we try and avoid email conversations in favor of keeping everything on the site?

lwholey commented 13 years ago

I haven't learned anything about client-side caching but I could check into it.

I think it'd be good to have all dialogue recorded in Github, but this might require creating too many issues. Let's keep using email for now - perhaps readjust later. Let me know what you think.

On Fri, Aug 26, 2011 at 7:18 PM, johnwilde < reply@reply.github.com>wrote:

Maybe a way to create parallel requests is to create a new thread for each request. I agree that client-side caching would be very nice to have - do you know of any resources for learning about this? I bet there are some libraries that might help. Also, and unrelated, what do you think the best way to use this "Issues" page on Github? When should be choose to "edit" the issue vs. add comments? Should we try and avoid email conversations in favor of keeping everything on the site?

Reply to this email directly or view it on GitHub: https://github.com/lwholey/concert/issues/2#issuecomment-1917789

johnwilde commented 13 years ago

Sounds good. I'll try to keep discussions that relate to issues on github. Also, I'll edit the "main issue" as it evolves. Comments are good for suggesting changes and code reviews.

On Fri, Aug 26, 2011 at 5:36 PM, lwholey reply@reply.github.com wrote:

I haven't learned anything about client-side caching but I could check into it.

I think it'd be good to have all dialogue recorded in Github, but this might require creating too many issues.  Let's keep using email for now - perhaps readjust later.  Let me know what you think.

On Fri, Aug 26, 2011 at 7:18 PM, johnwilde < reply@reply.github.com>wrote:

Maybe a way to create parallel requests is to create a new thread for each request.  I agree that client-side caching would be very nice to have - do you know of any resources for learning about this?  I bet there are some libraries that might help.  Also, and unrelated, what do you think the best way to use this "Issues" page on Github?  When should be choose to "edit" the issue vs. add comments?  Should we try and avoid email conversations in favor of keeping everything on the site?

Reply to this email directly or view it on GitHub: https://github.com/lwholey/concert/issues/2#issuecomment-1917789

Reply to this email directly or view it on GitHub: https://github.com/lwholey/concert/issues/2#issuecomment-1918102