![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Braaaaaaaanes...
Mar. 6th, 2008 01:53 pmThree easy steps to being a zombie:
1) Oversleep
2) Skip breakfast
3) Donate blood
1) Oversleep
2) Skip breakfast
3) Donate blood
Mar. 6th, 2008
Braaaaaaaanes...
Mar. 6th, 2008 01:53 pmThree easy steps to being a zombie:
1) Oversleep
2) Skip breakfast
3) Donate blood
1) Oversleep
2) Skip breakfast
3) Donate blood
Epiphany the Second
Mar. 6th, 2008 06:35 pmPublication is not secondary to research. It is on an equal footing. I should be treating it not as something to be dreaded, and tackled only forced to by a deadline, but as part of an ongoing process of development, just as with the code. It needs to be taken, managed, and maintained just as seriously as the source code I produce.
1) Use a version control system.
Right now, this looks like git. It will let me have a local copy on the laptop at all times, and a central server at home I can coordinate with. Easy tagging should let me be able to mark versions 'draft', 'submitted', 'final', and so on and get back to them at any point later. git also handles the PDF/EPS files I use. (I find svn to be simpler to use, but it lacks the distributed approach that would be *really handy* here.)
2) Use an ongoing topic-based organization system.
I've been storing papers in folders based on the conference they were submitted to, or the title of the paper. This has led to lost text passages when I can't recall where I wrote what. The organization will be done by topic first, and tagging in the git repository will mark 'submitted-FSE2004', etc. (Hmm, I wonder if Spotlight can read git tags? That would be slick.) I find it much harder to go back and select passages based on topic, but that's what I do most. (Finding by conference can also be done through caching the final PDF on a Publications website.)
3) Write every day.
It doesn't matter which topic, it doesn't matter if it's polished or not, the version control saves my butt here, just like it does with code. There's no reason why I shouldn't be writing *something* every day, regardless of my creativity levels or deadlines. When a CFP comes, I should be able to grab the topics for that conference, and compile a paper in due time - if there are any holes, the time to submission should be spent filling them with research, not wringing my hands over the writing.
4) In LaTeX files, each sentence is a line.
Okay, this is an implementation detail, but it just struck me that using git will get nasty with diffs if I stick with the current paragraph-per-line approach. Hmm. Batch find/replace to the rescue. Not too difficult.
5) Strongly consider breaking out topics in papers to sub-documents.
LaTeX's \include directive will let me break out individual sections, etc, into separate documents. Store by topic, with a master doc that is the conference name? (How to manage versioning from within a document - interesting question... and one I don't think I'm going to spend any more time on.)
6) Quit making excuses.
I have a shitload to write. I have not done so. Time to get it done.
(Can you tell I have a deadline looming that I'm frustrated over?)
1) Use a version control system.
Right now, this looks like git. It will let me have a local copy on the laptop at all times, and a central server at home I can coordinate with. Easy tagging should let me be able to mark versions 'draft', 'submitted', 'final', and so on and get back to them at any point later. git also handles the PDF/EPS files I use. (I find svn to be simpler to use, but it lacks the distributed approach that would be *really handy* here.)
2) Use an ongoing topic-based organization system.
I've been storing papers in folders based on the conference they were submitted to, or the title of the paper. This has led to lost text passages when I can't recall where I wrote what. The organization will be done by topic first, and tagging in the git repository will mark 'submitted-FSE2004', etc. (Hmm, I wonder if Spotlight can read git tags? That would be slick.) I find it much harder to go back and select passages based on topic, but that's what I do most. (Finding by conference can also be done through caching the final PDF on a Publications website.)
3) Write every day.
It doesn't matter which topic, it doesn't matter if it's polished or not, the version control saves my butt here, just like it does with code. There's no reason why I shouldn't be writing *something* every day, regardless of my creativity levels or deadlines. When a CFP comes, I should be able to grab the topics for that conference, and compile a paper in due time - if there are any holes, the time to submission should be spent filling them with research, not wringing my hands over the writing.
4) In LaTeX files, each sentence is a line.
Okay, this is an implementation detail, but it just struck me that using git will get nasty with diffs if I stick with the current paragraph-per-line approach. Hmm. Batch find/replace to the rescue. Not too difficult.
5) Strongly consider breaking out topics in papers to sub-documents.
LaTeX's \include directive will let me break out individual sections, etc, into separate documents. Store by topic, with a master doc that is the conference name? (How to manage versioning from within a document - interesting question... and one I don't think I'm going to spend any more time on.)
6) Quit making excuses.
I have a shitload to write. I have not done so. Time to get it done.
(Can you tell I have a deadline looming that I'm frustrated over?)
Epiphany the Second
Mar. 6th, 2008 06:35 pmPublication is not secondary to research. It is on an equal footing. I should be treating it not as something to be dreaded, and tackled only forced to by a deadline, but as part of an ongoing process of development, just as with the code. It needs to be taken, managed, and maintained just as seriously as the source code I produce.
1) Use a version control system.
Right now, this looks like git. It will let me have a local copy on the laptop at all times, and a central server at home I can coordinate with. Easy tagging should let me be able to mark versions 'draft', 'submitted', 'final', and so on and get back to them at any point later. git also handles the PDF/EPS files I use. (I find svn to be simpler to use, but it lacks the distributed approach that would be *really handy* here.)
2) Use an ongoing topic-based organization system.
I've been storing papers in folders based on the conference they were submitted to, or the title of the paper. This has led to lost text passages when I can't recall where I wrote what. The organization will be done by topic first, and tagging in the git repository will mark 'submitted-FSE2004', etc. (Hmm, I wonder if Spotlight can read git tags? That would be slick.) I find it much harder to go back and select passages based on topic, but that's what I do most. (Finding by conference can also be done through caching the final PDF on a Publications website.)
3) Write every day.
It doesn't matter which topic, it doesn't matter if it's polished or not, the version control saves my butt here, just like it does with code. There's no reason why I shouldn't be writing *something* every day, regardless of my creativity levels or deadlines. When a CFP comes, I should be able to grab the topics for that conference, and compile a paper in due time - if there are any holes, the time to submission should be spent filling them with research, not wringing my hands over the writing.
4) In LaTeX files, each sentence is a line.
Okay, this is an implementation detail, but it just struck me that using git will get nasty with diffs if I stick with the current paragraph-per-line approach. Hmm. Batch find/replace to the rescue. Not too difficult.
5) Strongly consider breaking out topics in papers to sub-documents.
LaTeX's \include directive will let me break out individual sections, etc, into separate documents. Store by topic, with a master doc that is the conference name? (How to manage versioning from within a document - interesting question... and one I don't think I'm going to spend any more time on.)
6) Quit making excuses.
I have a shitload to write. I have not done so. Time to get it done.
(Can you tell I have a deadline looming that I'm frustrated over?)
1) Use a version control system.
Right now, this looks like git. It will let me have a local copy on the laptop at all times, and a central server at home I can coordinate with. Easy tagging should let me be able to mark versions 'draft', 'submitted', 'final', and so on and get back to them at any point later. git also handles the PDF/EPS files I use. (I find svn to be simpler to use, but it lacks the distributed approach that would be *really handy* here.)
2) Use an ongoing topic-based organization system.
I've been storing papers in folders based on the conference they were submitted to, or the title of the paper. This has led to lost text passages when I can't recall where I wrote what. The organization will be done by topic first, and tagging in the git repository will mark 'submitted-FSE2004', etc. (Hmm, I wonder if Spotlight can read git tags? That would be slick.) I find it much harder to go back and select passages based on topic, but that's what I do most. (Finding by conference can also be done through caching the final PDF on a Publications website.)
3) Write every day.
It doesn't matter which topic, it doesn't matter if it's polished or not, the version control saves my butt here, just like it does with code. There's no reason why I shouldn't be writing *something* every day, regardless of my creativity levels or deadlines. When a CFP comes, I should be able to grab the topics for that conference, and compile a paper in due time - if there are any holes, the time to submission should be spent filling them with research, not wringing my hands over the writing.
4) In LaTeX files, each sentence is a line.
Okay, this is an implementation detail, but it just struck me that using git will get nasty with diffs if I stick with the current paragraph-per-line approach. Hmm. Batch find/replace to the rescue. Not too difficult.
5) Strongly consider breaking out topics in papers to sub-documents.
LaTeX's \include directive will let me break out individual sections, etc, into separate documents. Store by topic, with a master doc that is the conference name? (How to manage versioning from within a document - interesting question... and one I don't think I'm going to spend any more time on.)
6) Quit making excuses.
I have a shitload to write. I have not done so. Time to get it done.
(Can you tell I have a deadline looming that I'm frustrated over?)