mester / demo-day-vikings Goto Github PK
View Code? Open in Web Editor NEWLicense: The Unlicense
License: The Unlicense
Let's weigh in here for better tracking.
This seems like a better alternative. There doesn't seem to be a limit to the number of results we can get (as with the api) and even more, it eliminates the need for a config.py (as @neo1691 pointed out). We'd have to rewrite some of our code. Also, there isn't a limit on the number of results per request. Thoughts?
Our regex misses some titles and can't handled two hyphens. Also, titles shouldn't be omitted just because they don't have a year. Only the title, artist, genre, and score (to order) should be necessary. I've already written the new pattern.
This creates a problem with people using python3. Assigning myself.
So at this point the app takes a genre name and searches for it. Anything else we might want to add? e.g. we could save all music from a user's searches or keep a history of all of the music that they've actually played (I like the latter idea).
Once we've populated the database, we should be pulling songs from there.
Hey everyone.
So just in terms of advancing forward, I want to mention that we haven't thought about how we'll reach consensus on the issue of choosing a project.[1] Tyler, Jason and I have been discussing possibilities around some sort of top 10 music tracks app fetching from the /r/listentothis subreddit through the Reddit API. If we need to hash this out more, let's do that. If not, someone should raise a new issue for needed technologies (I don't want to be the one to do so because this was my idea and I have been involved in the discussion on Slack. Maybe someone who wasn't present, if in agreement can do so and if not, move the discussion around project ideas forward.)
For folks on the other side of the world, we should have a spec submitted within 24 - 36 hrs to fall around the deadline.
[1] Without some general approach to making decisions, with 5 people this is going to get complicated.
We need to use the api to cache all the posts till date, and periodically run some kind of an updater to get the latest posts.
Taken from here:
Document created in branch scope
and tied to PR #6
This may contain the same content as the readme.
I've changed the structure of our project per the recommendations in http://docs.python-guide.org/en/latest/writing/structure/. For reference, you can see https://github.com/kennethreitz/samplemod as an example of a good project structure. See PR #19.
Will do once the api_request is integrated with the app.
Let's decide on a workflow. Document created in branch workflow
and tied to PR #5
No test cases yet? Common dudes?
So as @bdauer mentions in #2, we have a bit of problem with decision making since we are many and different timezones. So since we have come up with an idea and I believe we trust each other enough, this is my suggestion for decision making moving forward:
Whenever someone makes a new suggestion or something that needs to be decided on. Raise the issue. One other person needs to take a look, then they can decide if it's good or not together with the original poster.
This suggestion because we don't have a lot of time so the decisions should be fast, but we are still a team so nobody should decide alone. I think it's a good compromise between speed and teamwork. If more people are online at the same time, of course the decisions can be discussed more thoroughly, but decisions shouldn't take days.
Reply if you agree or disagree. If you disagree, give another suggestion. If no disagreements by tomorrow morning (my timezone, GMT+1) or unanimous agreements before then, I will close this and it will be our decision making process moving forward.
We need better error handling. Rather than hard-code it, I'd like to move it to a function or decorator. At the very least, it needs to be redone in a lot of places. I've already written something.
Basically when you click on top
and choose like past week, 24 hours, all time, etc
Phase 2:
I was thinking MongoDB might be a good way to go. We can store the JSON data and not worry about too much. As I'm looking at it, we don't need a lot of linked tables.
Part of #25
Right now we only get genre from the user. If any additional inputs are needed please let me know so that I can integrate them into the front end.
Part of #25
Part of #25
I have created this mockup (pretty bad looking on paper). @jasonmeeks agrees with it, if anyone has better idea please suggest.
Hey guys,
We need to have our project under the rmotr group according to the spec. Not sure how we make that work on github. Will look into it later if I have time but I have a feeling @Mester can git it done before I do.
my_app directory now contains all the important api related to the app, we need to change the name of the directory to something meaningful.
Points to discuss,
I've chosen a handful of color palettes. Comment with any number of these palettes that you like or, if you don't like any, propose another!
http://www.colourlovers.com/palette/77121/Good_Friends
http://www.colourlovers.com/palette/444487/Curiosity_Killed
http://www.colourlovers.com/palette/90734/Newly_Risen_Moon
http://www.colourlovers.com/palette/903157/Entrapped_InAPalette
http://www.colourlovers.com/palette/475875/Gentle_Waves
Either need to page through the API request 20 at a time and fill up a database/list or consider seeing if there is a different API request where we can search the /r/ListenToThis subreddit for a specific genre. If we can't do that we probably need to populate a database with a ton of posts so we can hopefully have 10 of each genre
We're using a NoSQL database so that we can add the JSON data directly into the DB and keep it simple. TinyDB will meet our needs.
Adrian and I were discussing whether we should have one. I've already created it in another branch. I believe Adrian's points were that since we will not be publishing our package to pypi, it's unnecessary clutter and beyond the scope of our project.
My reasons to include it:
Let me know what you guys think. If you think it's useless, we can easily strike it.
I feel like the api module and functions inside do too much. Maybe possible to refactor some stuff
Basically what you get when you click hot
Part of #25
https://files.slack.com/files-tmb/T035C1NSH-F1NANCA75-f8dd31675e/img_20160702_235741_1024.jpg
Above is @neo1691 's sketch. It is a good idea to update our db every (period of time). For results returned by the hot filter, about 1000 posts are submitted in a week or 150 a day or 7 posts an hour. We should consider this when deciding how often to update our db. However, if we continue to only return a list of 10 songs with the highest scores, we can update less frequently as newer posts most likely wouldn't be included anyway due to low scores. But, keep in mind that if we choose to implement a search-by-date option, update frequency will have to be increased.
Also, we must consider the case of <10 results for a genre. This slightly complicates things. We must find a balance between returning songs with highest scores and those submitted more recently. What I mean is, to fulfill the missing number of songs, we would select the last x songs for the genre, which would be, at least as of now, selected based on score. But if a post is very old, despite it having a high score, I don't think we should necessarily select it over a newer post with a lower score. We need to keep a minimum number of songs for each genre in the db that were selected per rules to ensure not only high scoring posts are selected but timely posts. If not, the posts will be returned very often, despite new submissions or a genre. If we implement the search-by-date feature, we can use this logic and use absolute scores if not searched by date.
By the way, reddit's hot algorithm ranks new stories higher. Posts are highly affected by submission time. A post with 3000 upvotes can have a 6% higher score if posted tomorrow rather than today.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.