AMDmi3

joined 1 year ago
[–] [email protected] 2 points 7 months ago

Neither. A button should show action it performs.

[–] [email protected] 4 points 7 months ago

Read official docs, then rewrite some small own project in it.

[–] [email protected] 4 points 7 months ago* (last edited 7 months ago)

It's not a responsibly of the format, so, at most, it's a mere side effect. In any practical process which could result with truncated data, even if it handles data with such property, it should be wrapped in a container which includes length. At the very least, it would allow to trace the source of truncation, e.g. was the data originally truncated, or was it truncated in the process, and change the format without shooting in oneselves foot. And the generating side should always provide success flag which should be properly handled, since it may produce syntactically correct, but semantically invalid data. Such as checking exit code of process which generates json/yaml in question

[–] [email protected] 2 points 7 months ago* (last edited 7 months ago)

You just check the exit code, no? The other process may fail while generating syntactically correct data too, regardless of format.

[–] [email protected] 27 points 7 months ago (4 children)

That's not a problem of a format and should be handled by transport or storage.

[–] [email protected] 5 points 7 months ago (1 children)

Agreed, and I have more arguments against commit signing.

  • Commit immutability is undesirable, and mutable commits are not compatible with signing. For instance, pull requests are squashed and rebased to keep linear history, and changes are cherry picked around. It does not change authorship, however it changes hashes and invalidates any signatures. Or, say, one wants to adopt an otherwise FOSS project which though contains some copyrighted material in its repository, which needs to be filter-branched away, again invalidating the signatures.
  • In our world where stuff randomly gets criminalized I prefer to avoid being undeniably linked to my code.

BTW this topic has common considerations with now mandatory (on GH and more places) 2FA. For the latter reason, and also for own convenience and for reducing risk of losing access to your account (which I assess as much higher than risk of leaking my password to third parties) I make second factor public, effectively reverting to 1FA.

[–] [email protected] 9 points 8 months ago (4 children)

Why would you need to flesh it out it the first place? If you have serious projects I take it you're not total beginner, so don't waste time on projects with no purpose.

[–] [email protected] 3 points 10 months ago (1 children)

Being open to new opportunities and being dissatisfied with you job are different things. I've mainly meant that these statistics are biased. Hypothesis is that people not interested in doing their work hang out on SO instead, as a result a lot of people hanging out on SO are "considering a career move".

[–] [email protected] 12 points 10 months ago (3 children)

IMO it just says which and why people hang out on SO.

[–] [email protected] 6 points 11 months ago (1 children)

Do not worry, you will not have any issues such as data loss or corruption regardless of what data you keep in git. Keeping binary files may be ineffective, as many binary formats do not play well with external compression, as a result your repository will grow by the whole size of updated file on each commit, even if the logical change is small. This should not be the case for sqlite files though, which should be well compressible both as individual blobs and between versions of the same file, so with each update your repository would grow roughly by the size of changed data. You should be careful though to close all database connections before committing so the file is in consistent state and contains all the recently written data.

[–] [email protected] 6 points 11 months ago

Hard to understand as in learning it or as in reading others code?

view more: next ›