mester / demo-day-vikings Goto Github PK

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.

• Build a basic skeleton.
• Add bootstrap.
• Format with bootstrap.

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:

• App Name. Choose a name for your app.
• Team members. Name, short bio, github profile, (social media profile).
• Short description of your app. What’s going to do? What’s problem is going to solve?
• Detailed list of the features the web app will support at Demo Day.
• Services you’re going to use
• Technical details: technologies used, frameworks, deploy method, hosting, etc. (Personally disagree with this part, since most of it we don't know until we actually start)

Document created in branch scopeand tied to PR #6

• add name, version, packages field

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.

• error handler

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

• Create a class that fetches new posts.
• Add new posts to the db.

Phase 2:

• Update the upvotes count for posts already in the db as needed.

• Find a web host
• Get set up (this will very likely be multiple new issues.)

• Get JSON file from API
• Add JSON file to db
• Parse JSON file from the db instead of from the API.
• Run in the background at a regular interval and append new posts to the database.

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,

1. Does this make sense?
2. What does it impacts? setup.py? tox.ini?

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

http://www.colourlovers.com/palette/625987/dont_you_go_down

http://www.colourlovers.com/palette/1/metro

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

Some examples I've encountered:

• Alternativegives 0 results
  • Here's one that could be returned by that link
• This is not returned by either of these strings, alternative, funk, alternative/funk

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:

• so called "good practice" - this is something you will come across in the wild
• allows our package to actually be "installed"
• contains important metadata about our program
• use it to run tests
• other uses for deployment on our server

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

I think this might be quite useful instead of working with a bunch of dicts. Just have a class that represents a post with all the relevant data to the post (title, genre, upvotes etc)

• #23
• #27
• #22
• #26

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.

• Get an API key.
• Connect the app to the api
• Make the calls that we'll need.