When I tried DVC ~5 years ago it was very slow as it constantly hashed files for some reason.
Switched to https://github.com/kevin-hanselman/dud and I have been happy since ..
Dud author here. Happy to hear it's working well for you!
Readit Newskvnhn commented on The future of large files in Git is Git tylercipriani.com/blog/20... · Posted by u/thcipriani
kvnhn commented on How I write HTTP services in Go after 13 years grafana.com/blog/2024/02/... · Posted by u/matryer
>The Valid method takes a context (which is optional but has been useful for me in the past) and returns a map. If there is a problem with a field, its name is used as the key, and a human-readable explanation of the issue is set as the value.
I used to do this, but ever since reading Lexi Lambda's "Parse, Don't Validate," [0] I've found validators to be much more error-prone than leveraging Go's built-in type checker.
For example, imagine you wanted to defend against the user picking an illegal username. Like you want to make sure the user can't ever specify a username with angle brackets in it.
With the Validator approach, you have to remember to call the validator on 100% of code paths where the username value comes from an untrusted source.
Instead of using a validator, you can do this:
type Username struct {
value string
}
func NewUsername(username string) (Username, error) {
// Validate the username adheres to our schema.
...
return Username{username}
}
[0] https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
This is a variation on one of my favorite software design principles: Make illegal states unrepresentable. I first learned about it through Scott Wlaschin[1].
[1]: https://fsharpforfunandprofit.com/posts/designing-with-types...
"You can ask the agent for advice on ways to improve your application, but be really careful; it loves to “improve” things, and is quick to suggest adding abstraction layers, etc. Every single idea it gives you will seem valid, and most of them will seem like things that you should really consider doing. RESIST THE URGE..."
A thousand times this. LLMs love to over-engineer things. I often wonder how much of this is attributable to the training data...