From a recent backup, there are
417,361 files
in my main collection of files for my
startup, computing, applied math, etc.
All those files are well enough organized.
Here's how I do it and how I do related
work more generally (I've used the
techniques for years, and they are all
well tested).
(1) Principle 1: For the relevant file
names, information, indices, pointers,
abstracts, keywords, etc., to the greatest
extent possible, stay with the old 8 bit
ASCII character set in simple text files
easy to read by both humans and simple
software.
(2) Principle 2: Generally use the
hierarchy of the hierarchical file system,
e.g., Microsoft's Windows HPFS (high
performance file system), as the basis
(framework) for a taxonomic hierarchy
of the topics, subjects, etc. of the
contents of the files.
(3) To the greatest extent possible, I do
all reading and writing of the files using
just my favorite programmable text editor
KEdit, a PC version of the editor XEDIT
written by an IBM guy in Paris for the IBM
VM/CMS system. The macro language is Rexx
from Mike Cowlishaw from IBM in England.
Rexx is an especially well designed
language for string manipulation as needed
in scripting and editing.
(4) For more, at times make crucial use of
Open Object Rexx, especially its function
to generate a list of directory names,
with standard details on each directory,
of all the names in one directory subtree.
(5) For each directory x, have in that
directory a file x.DOC that has whatever
notes are appropriate for good
descriptions of the files, e.g., abstracts
and keywords of the content, the source of
the file, e.g., a URL, etc. Here the file
type of an x.DOC file is just simple ASCII
text and is not a Microsoft Word document.
There are some obvious, minor exceptions,
that is, directories with no file named
x.DOC from me. E.g., directories created
just for the files used by a Web page when
downloading a Web page are exceptions and
have no x.DOC file.
(6) Use Open Object Rexx for scripts for
more on the contents of the file system.
E.g., I have a script that for a current
directory x displays a list of the
(immediate) subdirectories of x and the
size of all the files in the subtree
rooted at that subdirectory. So, for all
the space used by the subtree rooted at x,
I get a list of where that space is used
by the immediate subdirectories of x.
(7) For file copying, I use Rexx scripts
that call the Windows commands COPY or
XCOPY, called with carefully selected
options. E.g., I do full and incremental
backups of my work using scripts based on
XCOPY.
For backup or restore of the files on a
bootable partition, I use the Windows
program NTBACKUP which can backup a
bootable partition while it is running.
(8) When looking at or manipulating the
files in a directory, I make heavy use of
the DIR (directory) command of KEdit. The
resulting list is terrific, and common
operations on such files can be done with
commands to KEdit (e.g., sort the list),
select lines from the list (say, all files
x.HTM), delete lines from the list, copy
lines from the list to another file, use
short macros written in Kexx (the KEdit
version of Rexx), often from just a single
keystroke to KEdit, to do other common
tasks, e.g., run Adobe's Acrobat on an
x.PDF file, have Firefox display an x.HTM
file.
More generally, with one keystroke, have
Firefox display a Web page where the URL
is the current line in KEdit, etc.
I wrote my own e-mail client software.
Then given the date header line of an
e-mail message, one keystroke displays the
e-mail message (or warns that the date
line is not unique, but it always has
been).
So, I get to use e-mail message date lines
as 'links' in other files. So, if some
file T1 has some notes about some subject
and some e-mail message is relevant, then,
sure, in file T1 just have the date line
as a link.
This little system worked great until I
converted to Microsoft's Outlook 2003. If
I could find the format of the files
Outlook writes, I'd implement the feature
again.
(9) For writing software, I type only into
KEdit.
Once I tried Microsoft's Visual Studio and
for a first project, before I'd typed
anything particular to the project, I got
50 MB or so of files nearly none of which
I understood. That meant that whenever
anything went wrong, for a solution I'd
have to do mud wrestling with at least 50
MB of files I didn't understand; moreover,
understanding the files would likely have
been a long side project. No thanks.
E.g., my startup needs some software, and
I designed and wrote that software. Since
I wrote the software in Microsoft's Visual
Basic .NET, the software is in just simple
ASCII files with file type VB.
There are 24,000 programming language
statements.
So, there are about 76,000 lines of
comments for documentation which is
IMPORTANT.
So, all the typing was done into KEdit,
and there are several KEdit macros that
help with the typing.
In particular, for documentation of the
software I'm using -- VB.NET, ASP.NET,
ADO.NET, SQL Server, IIS, etc. -- I have
5000+ Web pages of documentation, from
Microsoft's MSDN, my own notes, and
elsewhere.
So, at some point in the code where some
documentation is needed for clarity for
the code, I have links to my documentation
collection, each link with the title of
the documentation. Then one keystroke in
KEdit will display the link, typically
have Firefox open the file of the MSDN
HTML documentation.
Works great.
The documentation is in four directories,
one for each of VB, ASP, SQL, and Windows.
Each directory has a file that describes
each of the files of documentation in that
directory. Each description has the title
of the documentation, the URL of the
source (if from the Internet which is the
usual case), the tree name of the
documentation in my file system, an
abstract of the documentation, relevant
keywords, and sometimes some notes of
mine. KEdit keyword searches on this file
(one for each of the four directories) are
quite effective.
(10) Environment Variables
I use Windows environment variables and
the Windows system clipboard to make a lot
of common tasks easier.
E.g., the collection of my files of
documentation of Visual Basic is in my
directory
H:\data05\projects\software\vb\
Okay, on the command line of a console
window, I can type
G VB
and then have that directory current.
Here 'G' abbreviates 'go to'!
So, to command G, argument 'VB' acts like
a short nickname for directory
H:\data05\projects\software\vb\
Actually that means that I have --
established when the system boots -- a
Windows environment variable MARK.VB with
value
H:\data05\projects\software\vb\
I have about 40 such MARK.x environment
variables.
So, sure, I could use the usual Windows
tree walking commands to navigate to
directory
H:\data05\projects\software\vb\
but typing
G VB
is a lot faster. So, such nicknames are
justified for frequently used directories
fairly deep in the directory tree.
Environment variables
MARK.TO
MARK.FROM
are used by some other programs,
especially my scripts that call COPY and
XCOPY.
So, to copy from directory A to directory
B, I navigate to directory A and type
MARK FROM
which sets environment variable
MARK.FROM
to the directory tree name of directory A.
Similarly for directory B.
Then my script
COPYFT1.RXS
takes as argument the file name and does
the copy.
My script
COPYFT2.RXS
takes two arguments, the file name of the
source and the file name to be used for
the copy.
I have about 200 KEdit macros and about
200 Rexx scripts. They are crucial tools
for me.
(11) FACTS
About 12 years ago I started a file
FACTS.DAT. The file now has 74,317 lines,
is
2,268,607
bytes long, and has 4,017 facts.
Each such fact is just a short note,
sure, on average
2,268,607 / 4,017 = 565
bytes long and
74,317 / 4,017 = 18.5
lines long.
And that is about
12 * 365 / 4,017 = 1.09
that is, an average of right at one new
fact a day.
Each new fact has its time and date, a
list of keywords, and is entered at the
end of the file.
The file is easily used via KEdit and a
few simple macros.
I have a little Rexx script to run KEdit
on the file FACTS.DAT. If KEdit is
already running on that file, then the
script notices that and just brings to the
top of the Z-order that existing instance
of KEdit editing the file -- this way I
get single threaded access to the file.
So, such facts include phone numbers,
mailing addresses, e-mail addresses, user
IDs, passwords, details for multi-factor
authentication, TODO list items, and other
little facts about whatever I want help
remembering.
No, I don't need special software to help
me manage user IDs and passwords.
Well, there is a problem with the
taxonomic hierarchy: For some files, it
might be ambiguous which directory they
should be in. Yes, some hierarchical file
systems permitted to be listed in more
than one directory, but AFAIK the
Microsoft HPFS file system does not.
So, when it appears that there is some
ambiguity in what directory a new file
should go, I use the x.DOC files for those
directories to enter relevant notes.
Also my file FACTS.DAT may have such
notes.
Well, (1)-(11) is how I do it!