softwareengineeringdaily / sedaily-feed-service Goto Github PK

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper integration’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

Can potentially use meta scrape (or something similar) https://www.npmjs.com/package/meta-scrape

Right now we are clearing the feed every 10 minutes and recreating it. This will probably cause some random problems as more users join and it doesn't scale too well.

As a fist step, ideally we would want to have the script run a lot more often... but deleting the feed collection so often leaves some users with a blank feed (until the script is done and they refresh)...

One quick thing could be to maybe first populate a tempFeed collection, then drop the old one and rename the tempFeed to feed? And maybe the client can refresh itself if the server returns an empty array []... . Or maybe just say your feed is being built.. click to refresh.... and also we make sure not clear the old items if the server returns [].

This is still very MVP.

The ultimate solution will be a bit more complex :)

Source related links from:
listened to
Favorited/ bookmarked
Post user added links to
Commented on posts
Viewed posts

If you look at the feed, description is missing from the mined links

To prevent broken link problem

Add Interests to the User Model

A user is interested in different types of entities: tags, other users, etc...

For the first version, let's just handle tags.

Every episode model has tags associated with it. These are concepts like "graph databases", companies like "Apple", and people like "Justin Kan". Tags are a simple way of giving metadata to objects in our system.

Add to the user model:

interests : { tag_interests : { tag_id : weight } }

Weight represents how interested the user is in that tag.

Calculate User Interests: Basic

For most basic version of user interest, we can simply look at the episodes they have upvoted.

For each user, find the episodes they have upvoted.
For each of the episodes they have upvoted, find all the tags associated with the episode.
For each tag, set the user's weight to 1.

That's not a great way to model the user interests, but it's a start.

Calculate User Interests: Advanced

For each user, assume we have a history of each episode they have listened to, and what percentage of the episode they listened to. We currently store this data in Firebase, but are working on getting it into Mongo.

Percentage listened is a good indication of how interested a user is in the tags associated with that episode.

The data will look like this:
user : { listen_history: { episode_id : percentage_listened } }

The algorithm for calculating user interests:

for each user:
    create a map listened_tag_weights {tag_id : [tag_sum, tag_instances]}

    for each episode the user has listened to:

        for each tag associated with the episode:

            tag_sum += percentage_listened

            tag_instances++

     // update the users interests after building the listened_tag_weights map

    user.tag_interests[tag_id] = listened_tag_weights[tag_id][tag_sum] / listened_tag_weights[tag_id][tag_instances]

Now we have weighted interests for each user!

After #7 is complete, we can use these weights to match a user with links they are interested in.

Each episode has tags associated with it

Links should be updated to inherit the tags of the episodes they are posted under.