3,099 karma · joined October 24, 2016
https://github.com/b0o
For us, we audit every update of every package. We read the changelog or release notes for every version from the current version to the new version (some packages make this very cumbersome, looking at you Vercel). Then, we use our judgement about the order in which to update packages; usually we apply all patch-level updates, run our tests; then minor updates, re-run our tests; and then we apply major updates one-by-one and re-run tests after each of them.
We've found plenty of semver violations in this process, to the point where we don't really trust the semver of NPM packages at all.
Is this a common approach, or do you just blindly update everything at once and fix things if they break?
On a more serious note, this is a great example of how to handle a vulnerability report - fix it, change your processes, and say thank you! (geek_at could probably have done better by disclosing this in private first, though)
For each frame, get at least 4 different drawings.
For voters, show them 2-4 frames and have them pick the best one.
If there are more than 4 versions of a frame, do a bracket-based competition to determine the best frame.
This could be an ongoing process. Generate a version of the movie using the best available frames, but continue allowing people to redraw frames. The movie would continue getting better and better over time.
Then, when you watch the movie, maybe you could have a slider to control which "generation" of the movie you're watching. Slide all the way to the left and it will be really primitive, slide all the way to the right and it will be the best version.
I've been using relational databases for years, but my conceptual understanding was never that strong. I hadn't touched MySQL in particular for several years. Your course not only got me back up to speed, but I learned a lot of things I'd never known before.
I love how you organize your lessons, how you make sure to answer the right questions at the right times, and how you prioritize helping the learner build a strong mental model.
I hope you make more content like this in the future.
I watched it a few months ago and just re-skimmed the transript, so I'm not sure if I'm remembering it perfectly, but here's what I took away from it:
- YouTube's algorithm recommends videos based on audience viewing patterns.
- The algorithm doesn't care what the video is about, it only cares about who is clicking on it and watching it.
- Click-through rate and watch time are the most important metrics, they're how the algorithm determines who to recommend your video to, and whether to recommend your video to a wider audience.
- It first shows your video to a small group and if it's well-received, expands to a wider audience with similar viewing habits.
- It repeats this process until it finds the falling-off point, where the click-through rate and watch time drop off.
- Figure out who your niche audience is and make videos that they're likely to click on and watch.
- You're going to need to create enough videos in order for the algorithm to figure out where your audience is, and then you're going to want to make more videos for that audience.
- The average clickthrough rate you see in your analytics is not the whole story. You might have a 20% clickthrough in your target niche, but if the algorithm starts recommending your videos to a wider audience, your click-through rate is going to start to drop. That doesn't mean your video is not doing well, it could actually be doing well enough with your niche that the algorithm is trying to show it to more people outside of your niche.
// we only keep unfollows in the past 90 days due to the huge size of this dataset,
// and to prevent permanent "shadow-banning" in the event of accidental unfollows.
// we treat unfollows as less critical than above 4 negative signals, since it deals more with
// interest than health typically, which might change over time.
val unfollows: SCollection[InteractionGraphRawInput] =
GraphUtil
.getSocialGraphFeatures(
readSnapshot(SocialgraphUnfollowsScalaDataset, sc),
FeatureName.NumUnfollows,
endTs)
.filter(_.age < 90)
https://github.com/twitter/the-algorithm/blob/main/src/scala...I’m interested, but I can’t find anything about this on their site. Can you provide a link?
Exactly, this is known as "cognitive dissonance".
I would hypothesize this is an artifact of the training data being photos taken for the purpose of selling the cars.
As a seller, it doesn’t make a lot of sense to take a photo of the middle of the car, unless a) you’re trying to hide something or b) you’re being lazy (implying the car isn’t worth much of your time). I would imagine that better photography in general - composition, framing, lighting, setting - would be correlated with higher car prices.