I'm gonna need one of you to find me an expert on Austrian cheese who can help me substitute out a few different things. :P
Or provide me with cheese.
Clint
i know nothing about austrian cheese except that i liked https://www.rupp.at/ once
MRiddickW has quit
davic has quit
MajorLurker joined the channel
Leftmost
Kind of wanting to make Kässpätzle, but the recipes I find like to call for Tiroler or Vorarlberger cheeses, which I can neither find nor figure out how to substitute. :P
ruaok: regarding the empty central space, for the time being we can show what the user recommended using "recommend recording". This can be a good indicator of what the person likes imo. Your thoughts?
legoktm has quit
legoktm joined the channel
MajorLurker joined the channel
MajorLurker has quit
d4rkie has quit
d4rkie joined the channel
d4rkie has quit
d4rkie joined the channel
d4rkie has quit
d4rkie joined the channel
d4rkie has quit
d4rkie joined the channel
ruaok
moooin!
shivam-kapila: sure that seems reasonable
iliekcomputers
Good morning
MajorLurker joined the channel
Rotab has quit
MajorLurker has quit
goapunk_ has quit
goapunk joined the channel
ruaok packs a tablet so he can do some code review on the train
and was thing shall we also show similarity score in case I visit someone's else profile. I mean the similarity score will be between the similar users and the person who's profile I visited and not with me
People might confuse the score as similarity between them
and the list of users
Mr_Monkey
Hm. I can see how there could be room for confusion.
Ideally, what I'd like to see when I visit a user's profile is:
1. my similarity with them
2. my similarity with their followers/followed users
Is that doable?
If we can only show the similarity between the user I'm visiting and their followers/followed (but not with me) I think that' would indeed be confusing
In which case, let's skip it until we have a good way to make it not confusing
shivam-kapila
Hmm. To show similarity with me will take two API calls (1 to fetch list of similar users, 2. To fetch scores for my list of similar users) and then extract out the scores. Not sure if its the best way
But this eliminates the confusion
Mr_Monkey
WRT the first call, maybe the server can pass the list of similar users in the props, and on the front-end we only do the api call to fetch the scores
shivam-kapila
yeah. so we can keep the scores and make the necessary API fetch then
Mr_Monkey
I figure that separates concerns and ensures we're only ever fetching similarity from the front-end, from the point of view of the logged in user
I think that can work
shivam-kapila
cool. thanks
Mr_Monkey
We do the same thing for loading recording feedback
shivam-kapila
yep
iliekcomputers
ruaok: i read your code review
each query is a different table
i don't think it's really realistic to make all those a single query in the database
iliekcomputers: then i posit that the DB structure is wrong. If we have 15 types and need 15 queries to load a user page, any load spikes will doom our db.
iliekcomputers
We won't have 15 queries.
Other events will go into the user timeline event table.
The follow and the listens need the extra queries because they're not events per se
Playlist creation will go in the user timeline event table
I guess we could create an event every time a user follows someone
But right now that would remove one query.
Rotab joined the channel
Let's chat about it Monday, I guess. I agree that we should come up with something that scales as the types of events grow, I don't think the number of queries right now is an issue.
ruaok
Right now, agreed. It's the future i am concerned about.
Let's talk about a realistic growth plan on Monday.
MajorLurker joined the channel
MajorLurker has quit
milkii_ is now known as milkii
iliekcomputers
Yep, sounds good to me.
_lucifer
ruaok: in case you are available, i remember you mentioning a task for AB in the coming week. I would like to know more about it.
ruaok
Nothing definite on AB, but we shared a doc about oauth and metabrainz. Did you see that?