------ art_1790_10836503.1331003684921
Content-Type: multipart/alternative;
boundary --- art_1791_29217197.1331003684921"
------ art_1791_29217197.1331003684921
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
This is probably one of this topics that will get little attention.
Nonetheless...
Have other developers started to feel like the *configuration* files for
all the various project tools they use are starting to overshadow the rest
of the project files? For instance, In many of my projects the meat of the
project consists of a few source directories `lib/`, `test` (or `spec`) and
sometimes `bin/`, usually four general documentation files
`README`, `HISTORY`, `LICENSE` and `MANIFEST` and then of a few non
vcs-tracked things like `pkg/`, `log/` and `web/` directories. All the rest
consist of various configuration tool files. A quick look at various
projects on github provides:
* .git
* .gitignore
* .document
* .rdoc_options
* .yardopts
* .yardoc
* .autotest
* .travis.yml
* .rspec
* .ruby
* .test
* .braids
* .vclog
* .rvmrc
* .rbenv-version
* .test-unit.yml
* .gemtest
* .gemspec -or- foo.gemspec
* Guardfile
* Rakefile
* Gemfile
* Gemfile.lock
* Procfile
* config.ru
And there are no doubt many more. Feel free to mention notable ones I've
missed.
Now, obviously not all of these will apply to every project. But I can
imagine that given enough time and a rather thorough developer, a
project could acquire configurations for a couple dozen tools. Think code
coverage, code analysis, IDE/RAD configuration, etc. I suspect there is a
saturation point --at some point it just becomes too much to remember. Even
so, it could amount to quite a few files, well exceeding the number of
toplevel "meat" files of a project.
Another thing to notice is that there are almost universally two file
formats: Ruby or YAML, and three naming schemes: dot files, Foofile files
and lowercase with special extension files.
While there are obviously some files that will always remain (e.g. .git), I
wonder if it is possible for a convention to ever develop to mitigate all
this. Most likely that would be in the form of a common directory to hold
all these files, although conceivably, it could be in the form of a couple
of shared files --one for Ruby code and one for YAML.
------ art_1791_29217197.1331003684921
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
This is probably one of this topics that will get little attention. Nonetheless...<div><br></div><div>Have other developers started to feel like the *configuration* files for all the various project tools they use are starting to overshadow the rest of the project files? For instance, In many of my projects the meat of the project consists of a few source directories `lib/`, `test` (or `spec`) and sometimes `bin/`, usually four general documentation files `README`, `HISTORY`, `LICENSE` and `MANIFEST` and then of a few non vcs-tracked things like `pkg/`, `log/` and `web/` directories.ll the rest consist of various configuration tool files. A quick look at various projects on github provides:</div><div><br></div><div>* .git</div><div>* .gitignore</div><div>* .document<br></div><div>* .rdoc_options</div><div>* .yardopts</div><div>* .yardoc</div><div>* .autotest</div><div>* .travis.yml</div><div>* .rspec</div><div>* .ruby</div><div>* .test</div><div>* .braids</div><div>* .vclog</div><div>* .rvmrc</div><div>* .rbenv-version</div><div>* .test-unit.yml</div><div>* .gemtest</div><div>* .gemspec -or- foo.gemspec<br></div><div>* Guardfile<br></div><div>* Rakefile</div><div>*emfile</div><div>* Gemfile.lock</div><div>* Procfile</div><div>* config.ru</div><div><br></div><div>And there are no doubt many more. Feel free to mention notable ones I've missed.</div><div><br></div><div>Now, obviously not all of these will apply to every project. But I can imagine that given enough time and a rather thorough developer, a project could acquire configurations for a couple dozen tools. Think code coverage, code analysis, IDE/RAD configuration, etc. I suspect there is a saturation point --at some point it just becomes too much to remember. Even so, it could amount to quite a few files, well exceeding the number of toplevel "meat" files of a project.</div><div><br></div><div>Another thing to notice is that there are almost universally two file formats: Ruby or YAML, and three naming schemes: dot files, Foofile files and lowercase with special extension files. </div><div><br></div><div>While there are obviously some files that will always remain (e.g. .git), I wonder if it is possible for a convention to ever develop to mitigate all this. Most likely that would be in the form of a common directory to hold all these files, although conceivably, it could be in the form of a couple of shared files --one for Ruby code and one for YAML.</div><div><br></div><div><br></div>
------ art_1791_29217197.1331003684921--
------ art_1790_10836503.1331003684921--