Accountants Don’t Use Erasers (2007)
blogs.msdn.microsoft.com
Accountants Don’t Use Erasers (2007)
1–10 of 11 posts
Re: Accountants Don’t Use Erasers (2007)
#2My accountant does
Re: Accountants Don’t Use Erasers (2007)
#3On a somewhat related note, a piece of advice for students: Don't use an eraser on tests. Write in pen, cross out mistakes with a single line through the middle. It will show the instructor your reasoning, so even if you get the final answer wrong there's a chance you'll be given partial credit. It won't hurt (as long as you have space) and it can certainly help. Even if you don't get partial credit your instructor may indicate that something you thought was a mistake was the path to the true solution. I used this tactic all through high-school and university, it works well and makes learning from mistakes easier.
Re: Accountants Don’t Use Erasers (2007)
#4On a somewhat related note, a piece of advice for students: Don't use an eraser on tests. Write in pen, cross out mistakes with a single line through the middle. It will show the instructor your reasoning, so even if you get the final answer wrong there's a chance you'll be given partial credit. It won't hurt (as long as you have space) and it can certainly help. Even if you don't get partial credit your instructor m…
I wrote in pen, and completely blotted out stuff I didn't want.
No visibility (hopefully) for what I wanted to erase, but still better than using a pencil and eraser.
Re: Accountants Don’t Use Erasers (2007)
#5On a similar note, don't be tempted to erase parts of your commit history. There are some modes of using git rebase, push -f, commit --amend etc that attempt this. It's almost never a good idea. If the issue is just that something was a typo and you don't want your mistakes out there, just don't worry about it.
Re: Accountants Don’t Use Erasers (2007)
#6On a similar note, don't be tempted to erase parts of your commit history. There are some modes of using git rebase, push -f, commit --amend etc that attempt this. It's almost never a good idea. If the issue is just that something was a typo and you don't want your mistakes out there, just don't worry about it.
Unless you have a password or secret token in there.
Re: Accountants Don’t Use Erasers (2007)
#7On a similar note, don't be tempted to erase parts of your commit history. There are some modes of using git rebase, push -f, commit --amend etc that attempt this. It's almost never a good idea. If the issue is just that something was a typo and you don't want your mistakes out there, just don't worry about it.
Unless you have a password or secret token in there.
At that point, it's better to change the secret if at all possible.
Re: Accountants Don’t Use Erasers (2007)
#8>1) You don't really ever delete ANYTHING. As a matter of fact, you don't update anything either...
It's a good article but it has the common shortcoming of leaving out tradeoffs.
Append-only architecture:
a) requires more disk space
b) can have slower performance: e.g. double writes of (1) to the immutable log and (2) summary cache -- and both operations must be sync'd in a transaction ... or other option of skipping the writes to the summary cache which means all subsequent reads must "re-materialize" what the "current" data looks like by re-applying history of deltas repeatedly
For some domains like financial accounting, those tradeoffs are immaterial and you absolutely need immutable history for auditing and system debugging.
However, for other purposes (e.g. os filesystems like NTFS), the better tradeoff is to mutate data in-place and forego history to save diskspace. (E.g., You want to modify 2 terabytes of data on completely full 8 TB harddrive that only has 100 MB free.)
The tradeoffs are why many database engines offer a "generate no rollback log" option for bulk update commands. The opposite example is bolting on a "history log" on top of a mutate-in-place file system -- which is what Mac OSX "Time Machine" backups do.
Re: Accountants Don’t Use Erasers (2007)
#9On a similar note, don't be tempted to erase parts of your commit history. There are some modes of using git rebase, push -f, commit --amend etc that attempt this. It's almost never a good idea. If the issue is just that something was a typo and you don't want your mistakes out there, just don't worry about it.
Why is it not a good idea? If I know that no one pulled my commits, then what is the downside of e.g. erasing the latest commit?
Re: Accountants Don’t Use Erasers (2007)
#10>1) You don't really ever delete ANYTHING. As a matter of fact, you don't update anything either... It's a good article but it has the common shortcoming of leaving out tradeoffs . Append-only architecture: a) requires more disk space b) can have slower performance: e.g. double writes of (1) to the immutable log and (2) summary cache -- and both operations must be sync'd in a transaction ... or other option of skippi…
Yeah, append-only computing is only a good solution in a field where you need to be able to thoroughly, accurately audit the state of the system with 100% non-repudiation. Financial and medical data are probably the two biggest areas, though there are others.
And you're right, this is a performance killer and a disk eater. I work on backend services that handle financial data, and about 50% of the internal network traffic is the various audit widgets doing their thing.