dir構成とgit hub submodule



# イントロ：dir構成とセミラティス

fileが増えるに従って，directory構成を修正していく必要があります．書類の整理なんですが，これを系統的にやる方法を考察します．

複数人で作業する時の一番重要な掟は，「直交性(orthogonality)を守る」です．自分の分担している部分のdirectoryのみをいじって，それ以外は触らないが基本です．そうすれば独自作業と共同開発が同時に進行できるからです．こういう掟を自分にも課すことが書類整理の第一歩です．

そのほかの基本となる掟は，

1.  tight binding
2.  semi-lattice

です．tight bindingは簡単で，関連の深い書類をできるだけ近くに置く．これは書類が迷子にならないようにというのを目的にしています．一方で，semi-latticeはちょっと複雑な概念が混じっています．単純には，directory構成をできるだけ同じにして，粒度(fileの中身の量と，数と思ってください)を揃えるということです．どこで切っても同じように見えることがコツです．そうすればどこからでも始めることができるから．そして，どこへ行っても同じ感覚で学習ができるから．つまり，tight-bindingは書類からみた要望，semi-latticeは使う側からの要望です．これらを適切に調整すれば素晴らしい書類管理ができます．

これらは，実際に経験すればわかるのですが，馴染むまでは重要な「概念」ということで単語を覚えておいてください．このような感覚を掴んで，今後の学習に活かしてください．これを強制するようなshellを作ってくれると嬉しんですが．．．my\_help, qiita\_orgはその第一歩です．


# semi\_latticeについて

普通の学習過程の基本思想はツリー構造なんです．つまり，基本から始まって，それらを積み上げて応用，発展へとつながっていく．大学の基本的なカリキュラム構成も，今はこうなっています．

ところが，複雑な内容を研究しようとするとこれではダメで，セミラティスと呼ばれる構造が良いとされています．なぜいいかといういうと，どこからでも始めていいから．基礎知識もなく，スキルもなくともはじめることが可能です．目で見て，わかりやすい例を建設業で考えてみましょう．建設業で，設計，大工，左官，電気屋根などの分担がありますよね．でも，これを全て学んでいるわけではない．高校で始める人は，基礎を一通りやりますが，そうではなく飛び込みで職人になる人もいます．その人たちもすぐに作業ができるのは，「単純」だからだけではなく，一つ一つの作業が分解されて，スキルが限られていてもできるからです．ところが，そのままでは全体がわからず，現場監督とか設計士とかに出世することはできません．別に出世する必要はありませんが，

> ある建築現場で、何をしているのかを聞かれた三人の石工のうち、「一人目の男は『これで食べている』と答えた。二人目は手を休めずに『腕のいい石工の仕事をしている』と答えた。三人目は目を輝かせて『国で一番の教会を建てている』と答えた」『マネジメント』（ダイヤモンド社刊）より

工学で必要となるスキルはそういうものだと思ってください．全てを知ってなくても，どこからでも始められるけど，全てを知っていると得．「石切工は伽藍を思い浮かべならがら作業をする」という言葉です．

ツリー構造は，思考法として演繹(deduction)と帰納(induction)に行き着くように，セミラティスは不明推測法(abduction)に行き着きます[^Nishitani19] [^Mint99] [^Yonemori]．

| ![./figs/abduction.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/151211/daa6a337-7ce4-71f9-a23e-a19048188aba.png)|
|:------------------------------------------------------------------------------------------------------------------------------------|
| abductionの図示                                                                                                                     |

で，これを形にしたのが，fishのbob's\_shellです（嘘）．


# directory構成の変更

実際にこのdirectory(repository)を例に，どういう風に整理されてきたかを紹介しましょう．

    materials_sicence
    .
    ├── README.md
    ├── README.org
    ├── al_boundary/
    │   ├── README.md
    │   ├── README.org
    │   ├── asura_speed_check/
    │   ├── docs/
    │   ├── einstein/
    │   ├── first_frenkel_calcs/
    │   ├── fluctuation_view/
    │   ├── frenkel_calcs/
    │   ├── frenkel_new/
    │   ├── ground_state_result/
    │   ├── iferc_speed_check_rev/
    │   ├── sketch_view2/
    │   └── sketch_view2_movie_poscar_dir/
    ├── al_surface
    │   ├── README.html
    │   ├── README.md
    │   ├── README.org
    │   ├── calc/
    │   ├── deviation.org
    │   ├── docs/
    │   ├── figs/
    │   └── mk_md.rb
    ├── first_paper/

でした．まず最初にやったことは，rootの名前を変えること．materials\_scienceをfinite\_temp\_calcにしました．「名は体を表す」です何をする，何が書かれているかは，名前で示すべきです．初めの目論見からずれていくことも多々あります．それに従ってdirectoryを調整していき，できるだけ多くの人が参加できるようにするべきです．自分一人での作業であっても，時間が経つと記憶は不明瞭になります．いつでも，どこからでも始められるようにdirectoryには「最小必要限」の構成物を用意しておきましょう．

さらに追加していきます．ほとんどが，al\_surfaceから格上げしたものです．これは「粒度」を揃える段階で，必要になった切り分けです．また移動，再構成をいくつかかけています．こうして，「最初っから作業できるようなプラットフォームを用意する」を試みていました．

    ├── al_100
    │   ├── POSCAR_orig
    │   ├── bin
    │   ├── vol_098
    │   ├── vol_100
    │   ├── vol_102
    │   └── vol_104
    ├── al_110
    │   ├── al_111
    │   ├── bin
    │   ├── docs
    │   ├── old
    │   ├── unfinished_calc
    │   ├── vol_098
    │   ├── vol_100
    │   ├── vol_102
    │   └── vol_104
    ├── al_111
    │   ├── POSCAR_111_42
    │   ├── README.md
    │   ├── README.org
    │   ├── Rakefile
    │   ├── bin
    │   ├── docs
    │   ├── double_new_model
    │   ├── einstein_calc.org
    │   ├── einstein_results_all.txt
    │   ├── qsub_auto_calc.md
    │   ├── qsub_auto_calc.org
    │   ├── wild_card.md
    │   ├── wild_card.org
    │   └── wrong_models
    ├── al_twist\
    │   ├── README.md
    │   ├── README.org
    │   ├── bin
    │   ├── docs
    │   └── modeling
    ├── bin\
    ├── docs
    │   └── akahon
    ├── frenkel
    │   ├── README.md
    │   ├── README.org
    │   ├── bin
    │   └── figs
    ├── github_submodule.md
    ├── github_submodule.org
    ├── mk_qiita_summary.rb
    └── ti
        ├── README.md
        ├── README.org
        ├── bcc
        └── bin


# repository管理

前述のsemi-latticeを実現するには，document量の増加に伴って頻繁にdirectoryを調整する必要があります．その時，githubでのbackupをどうやっていくかが問題となります．

それをgithubのsystemとして提供しているのがsubmoduleです．

でも，先ずは，そのままinitします．そうすると，他で管理しているdirectoryは外してくれます．そのdirectoryはそちらで管理します．そうすると，semi-latticeの思想の「自分の知らないといけない範囲の情報」だけを見ることが可能になります．一方で，統括する方(super visor)は，まとめサイトを自動生成するようにして，そこで管理しやすいようにします．全てはqiitaに表示かな．．．

    >  git add -A
    warning: adding embedded git repository: al_100
    hint: You've added another git repository inside your current repository.
    hint: Clones of the outer repository will not contain the contents of
    hint: the embedded repository and will not know how to obtain it.
    hint: If you meant to add a submodule, use:
    hint: 
    hint: 	git submodule add <url> al_100
    hint: 
    hint: If you added this path by mistake, you can remove it from the
    hint: index with:
    hint: 
    hint: 	git rm --cached al_100
    hint: 
    hint: See "git help submodule" for more information.
    warning: adding embedded git repository: al_110
    warning: adding embedded git repository: al_111
    warning: adding embedded git repository: al_boundary
    warning: adding embedded git repository: al_surface
    warning: adding embedded git repository: al_twist
    warning: adding embedded git repository: first_paper
    warning: adding embedded git repository: frenkel
    warning: adding embedded git repository: ti
    > git help submodule
    > git add -A
    > git commit -m 'first commit'
    [master (root-commit) f1d9b19] first commit
     18 files changed, 5580 insertions(+)
     create mode 100644 .gitignore
     create mode 100644 README.md
     create mode 100644 README.org
     create mode 160000 al_100
     create mode 160000 al_110
     create mode 160000 al_111
     create mode 160000 al_boundary
     create mode 160000 al_surface
     create mode 160000 al_twist
     create mode 100755 docs/akahon/answers.pdf
     create mode 100755 docs/akahon/chapter_10.pdf
     create mode 100755 docs/akahon/chapter_5.pdf
     create mode 100755 docs/akahon/chapter_7.pdf
     create mode 100755 docs/akahon/chapter_8.pdf
     create mode 160000 first_paper
     create mode 160000 frenkel
     create mode 100644 mk_qiita_summary.rb
     create mode 160000 ti
    > git remote add origin git@github.com:TeamNishitani/finite_temp_calc.git
    > git push -u origin master
    Enumerating objects: 13, done.
    Counting objects: 100% (13/13), done.
    Delta compression using up to 4 threads
    Compressing objects: 100% (12/12), done.
    Writing objects: 100% (13/13), 3.06 MiB | 1.07 MiB/s, done.
    Total 13 (delta 0), reused 0 (delta 0)
    To github.com:TeamNishitani/finite_temp_calc.git
     * [new branch]      master -> master
    Branch 'master' set up to track remote branch 'master' from 'origin'.


# 引用文献

[^Nishitani20]: テスト駆動学習:名前付き loop の重要性 関西学院大学・理工学部 西谷滋人，河野大登, 内田 啓太郎 香川大学・創造工学部，福森聡[^Mint99]:  バーバラミント. 考える技術・書く技術 – 問題解決力を伸ばすピラミッド原則. ダ イヤモンド社, 1999.[^Yonemori07]: 米盛裕二. アブダクション – 仮説と発見の論理. 勁草書房, 2007



------
 - **source** ~/finite_temp_calc/docs/github_submodule.org