On 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.
I had always used pencil in high school for math, figuring that I would occasionally need to correct or start over on some portion of my work; I graduated in 1969. At MIT, I learned as a freshman from an upperclassman to switch to using a pen. Every minute counted and simply crossing out was much faster than erasing . To this day, I rarely use a pencil. For scratch work I write on typing paper with a pen.
While working on more complex problem sets in my recent graduate math and CS courses I developed a couple of additional tricks:
(1) Do your home work on plain paper sheets. Write on only one side; flipping sheets of paper back and forth to find something will drive you crazy and slow you down.
(2) After obtaining a solution, copy it from the work sheets (that may be full of dead ends) to the sheets to be turned in. Then fold the work papers in half, brining the top edge down to the bottom edge and set aside. This keeps your workspace clean for the next problem while still preserving any work for subsequent parts or problems. I also fold the papers that I will turn in, but I fold them with a vertical fold (left edge over to right edge), this keeps the to be turned in papers from being mixed up with the work in progress or the set aside work sheets that I'm finished with.
(3) Papers to be turned in should be lightly tinted and or written in an unusual ink color. This accomplishes two things, it's easier to find your work when returned in a big box or stack by the professor, and secondly, the graders will start to recognize your work. My theory is that in these classes I'm usually at the top of the class the graders will start to grade my papers more charitably because they expect that I am getting the correct answers.
On 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.
>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.
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.
10 comments
[ 2.8 ms ] story [ 32.7 ms ] threadNo visibility (hopefully) for what I wanted to erase, but still better than using a pencil and eraser.
While working on more complex problem sets in my recent graduate math and CS courses I developed a couple of additional tricks:
(1) Do your home work on plain paper sheets. Write on only one side; flipping sheets of paper back and forth to find something will drive you crazy and slow you down.
(2) After obtaining a solution, copy it from the work sheets (that may be full of dead ends) to the sheets to be turned in. Then fold the work papers in half, brining the top edge down to the bottom edge and set aside. This keeps your workspace clean for the next problem while still preserving any work for subsequent parts or problems. I also fold the papers that I will turn in, but I fold them with a vertical fold (left edge over to right edge), this keeps the to be turned in papers from being mixed up with the work in progress or the set aside work sheets that I'm finished with.
(3) Papers to be turned in should be lightly tinted and or written in an unusual ink color. This accomplishes two things, it's easier to find your work when returned in a big box or stack by the professor, and secondly, the graders will start to recognize your work. My theory is that in these classes I'm usually at the top of the class the graders will start to grade my papers more charitably because they expect that I am getting the correct answers.
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.
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.