3 ms·
A lot of the goals/problems mentioned in the document can be solved with a "lab notebook" consisting of plain text files plus Git version control. For example:
by nayuki 5y ago
A lot of the goals/problems mentioned in the document can be solved with a "lab notebook" consisting of plain text files plus Git version control. For example:
> Legal document to prove patents and defend your data against accusations of fraud
> Bound/Stitched | No lost pages, legally stronger | Difficult to copy, not logically organized
> Requires electronic security, corrupted files, software compatibility issues
> No pages come out of the notebook | Do not take any pages out or remove any data | Do not skip pages in your notebook | Cross out any unused parts of a page
> Correct mistakes, do not remove them | Cross out mistakes with a single line | Paste in corrections without covering anything | Sign and date all corrections
Also, if you sign your commit hashes with a trusted timestamping service, then that could serve as watertight evidence of prior work.
- jjoonathan 5y agoProgrammers really love plaintext/markdown notebooks, but they introduce a lot of friction around graphs and "snap a picture + annotate," and that destroys their value prop for me. Snap + annotate (or sketch + annotate) is an absolutely killer workflow if you deal with artifacts in the physical world, to the point where I gladly endure poor text editing capability and version control so long as I can have snap + annotate. Heck, if I didn't have a computer with good snap + annotate support I'd use a physical lab notebook before I tried to somehow shoehorn the workflow into text.