そこそこ学習をして感じたこと。
おそらく英語概念の由来のためか、ITインフラ用語は、異業種や分野関係と意味合いが違うものが多くある。
その点、自分は建設系のインフラ関連の経験があるため、ITインフラはとっつきやすい。
ITインフラ勉強： お勉強的な印象。深堀の価値はこちらのがありそう。ハードより
どう活かすかは、仕事にかかっている。
プログラミング： 学習の時点から、お勉強をどう活かしてコードを書いていくかに、
ウェイトがある印象。ソフトより
何をどう活かすかは、仕事にかかっている。
また、環境設定がMACだとわかりづらい印象
環境設定の時点で、インフラの知識も必要。
以下に、UNIXの哲学を記載する。
参照元：https://gist.github.com/koudaiii/82e4f8869705e5be065f#file-gistfile1-md
定理
1. Small is beautiful. 小さいものは美しい
小さいものは、大きい物にない利点がいくつもある。小さいもの同士なら簡単に独特の便利な方法で組み合わせることができる
小さなプログラムという発想
小さなプログラムはわかりやすい
小さなプログラムは保守しやすい
小さなプログラムはシステムリソースに優しい
小さなプログラムは他のツールと組み合わせやすい
一般にソフトウェアの開発者は、巨大なプログラムを書いてしまう。
これは「あらゆる不測の事態に対応できるように」という誤った考えに基づくものだ。
巨大で複雑なプログラムの開発者は、「将来が予測可能で、そして現在とそう大きくは変わらない」という勝手な思い込みを前提としている。
一方、小さなプログラムの開発者は、未来の予測など最初からあきらめている。
彼らの予測することは、明日作られるものは今日作っているものとは違うということでしかない。作った時には予測できなかったことに対しても、小さなプログラムなら直ちにそれに対処できる。
未来に目を向けよう。未来は、思っているより早く来る。
2. Make each program do one thing well. 1つのプログラムには1つのことをうまくやらせる
一つのことに集中することでプログラムに不要な部分をなくせる。
不要な部分があると、実行速度が遅くなり、不必要に複雑になり、融通が効かない。
creeping featurism(しのびよる多機能主義)
プログラマはシンプルなApplicationを書くかもしれない。
しかし、彼のCreativeさが新機能や新しいオプションを付けさせてしまうのだ。
そのコードが本当に必要なのかどうかを常に意識しておくべきだ。
・プログラムはユーザーとの対話を必要とするのか？パラメータはファイル読み込みや引数で出来ないのか？
・プログラムの入力データが特殊フォーマットである必要があるのか？他のプログラムに回せないのか？
・プログラムの出力データが特殊フォーマットである必要があるのか？他のプログラムに回せないのか？
・新しくプログラムを書く必要があるのか？他のプログラムを組み合わせれないのか？
小さなプログラムは単一機能になる傾向があり、単一機能のプログラムは小さくなる傾向がある。
3. Build a prototype as soon as possible. できるだけ早く試作する
あらゆるプロジェクトにおいて、プロトタイプは重要である。
一般的にプロトタイプは設計全体のうちの一部として扱われているが、
UNIXにおいてのプロトタイプは、効率的な設計には欠かせない重要な一部である。
ソフトウェアに完成はない
ソフトウェアには常に改善の余地はあるのはもちろんだし、時間的な制約などでそのソースコードは必ずしも最高の状態が保たれているわけではない。
ほとんどのソフトウェアは妥協の産物だ。完成することはなく、ただリリースがあるだけだ。
ソフトウェアや計算機が常に進化していることを意識しなければならない。
UNIXの考え方はソフトウェアの進化にも強い。
ソフトウェアを小さくてシンプルな部品に分割すれば、
将来の変更に容易に対応できるし、ソフトウェアを容易に移植可能にしておけば、来年には利用できるようになる、
よりはやい計算機でも簡単に動かすことができる。
なぜソフトウェアは「ソフト」ウェアなのか
ユーザーが自分たちの望むもの正格に表す事ができ、ソフトウェア技術者たちが、ユーザーが現在必要としている機能と将来必要になるであろう機能とをすべて把握していたとすれば、ソフトウェアはいらないだろう。
すべてのプログラムが最初からROMに書かれていればいい。残念ながら、そのような完璧な世界は存在しない。
リリース後に進行状況の報告を絶えず受け、対応した進路に修正していくことこそがゆういつの拠り所となる。
誰もが常に学び続けている。たとえ我々がすべてを知り尽くしたと勝手に思い込んでいても、誰かが我々への要求仕様を変えてしまうのだ。
第一のシステム、第二のシステム、第三のシステム
人間にはこの三種類のシステムしか作れない。
人間の作るSystemは人間に似るということなのかもしれない。
人間が、若さからはじまり、成熟し、やがて老いていくように、
システム設計にも若い設計、成熟した設計、枯れた設計がある。
追い詰められた人間が第一のシステムを作る
第一のシステムは、一人もしくは少人数が、時間に追われる中で創造性を発揮し、勢い良く作ったシステムだ。
時間追われたために、足りない機能もあるが無駄はなく効率的に動く。
さまざまな批判を浴びせかけられるだろう。
しかし、当の本人は「ああ、そりゃちょっと汚いのは分かってる。でもちゃんと役に立ってるだろ!」と、こういうだろう。
「正しく」やっている時間など無い。
「正しく」やる時間がない人間は、重要な箇所だけに集中して枝葉を無視する。
その結果、いくつかの細かい点は次のバージョンに回そうと計画する
第一のシステムのコンセプトは、人間の想像力を刺激する。
この段階で大規模になることはない。
チームが大きくなることで意思疎通・個性の衝突がおきる。
このタイミングで人を投入してもあちこちに縄張りが出来るだけであり、第一システムの実現すら危ぶまれる。
人月の神話である。
人間による第二のシステム
しかし、第一のシステムが成功しはじめると、多くの人が集まってくる。
そして、「専門家」が第一のシステムにより有用性が証明されたアイディアを用いて第二のシステムを作る。
第二のシステムは第一のシステムに目をつけた多くの参加者からなる委員会が機能を決定する。
その結果として、多くの人の意見(独自技術症候群を持った意見も含む)を取り込みすぎるため、機能は多いが、無駄のある遅いシステムができあがる。
多くの人に期待された第二のシステムは時には商業的にも成功するが、実はあまり役に立たない。
人間による第三のシステム
第二のシステムで「火傷」した人々が、第三のシステムを構築する。
第三のシステムだけが、第一のシステムが発見したアイディアと第二のシステムの中で見つかった必要な機能をバランスよく取り入れて、やっと役に立つシステムを構築することができる。
Systemの目的はしっかり把握され、使用するギジュ湯もすでに証明済みであるため、リスクは小さい。意思決定の段階で、正格な予算を組み、正格なスケジュールを建てることができる。
第三のシステムの設計者には、ようやく「正しく」やることが出来る時間が与えられる。
効率的に第三のシステムを構築するために
UNIXの考え方では、なるべくはやく第三のシステムを構築するために、すばやく試作することをおすすめしている。
直接、第三のシステムをつくることはできないのだ。
1 短い機能仕様書を書く(3〜4枚程度)
2 ソフトウェアを書く
3 テストして書き直す。満足できるまで、これを繰り返す。
4 詳細なドキュメントを(必要なら)書く
4. Choose portability over efficiency. 効率より移植性を優先する
現在のハードウェアに制限されないソフトウェアこそ、未来でも利用される
最も効率のよい方法は、ほとんどの場合移植性に欠ける
ハードウェアと切り離すことができないソフトウェアは、そのハードウェアが競争力を持ち続ける間しか価値を維持できない
より高速なハードウェアによって既存のハードウェアが置き換えられる度に書き直さなければならない。
5. Store numerical data in flat ASCII files. 数値データはASCIIフラットファイルに保存する
移植性を保つ上で、各OSのバイナリーファイルに依存しないASCIIフラットファイルに保存し、参照可能にする。
データをわざわざバイナリーにする必要がない。
6. Use software leverage to your advantage. ソフトウェアを梃子(てこ)として使う
プログラムの再利用は、ソフトウェアの梃子を最大限に活用した強力な考えだ。
UNIXの開発者たちは、この考え方に従って、非常に多くのApplicationを比較的に短期間に開発してきた。
独自技術症候群
一般に信じられているところとは反対に、独自技術症候群は創造性を伸ばさない。他人の仕事を見て、自分のほうがうまくできると主張してみても
それだけで創造性が増えるわけではない。
既存のApplicationをゼロから設計し直すことは模倣であっても創造とは言わない。
むしろこれを避ける事で、新しい、わくわくするような設計世界への扉が開かれる。
「自尊心」の誘惑に負けてはいけない。
すべてを自動化する
ソフトウェアの梃子をクカ的に利用する方法の一つは、マシンをより激しく働かせることだ。
コンピュータにできることを人間が手作業で行うのは時間の無駄だ。
おどろくべきことに現代的なエンジニアの研究所でさえ、中に入ってみると、驚くほど多くの熟練技術者が日常の業務を手作業で行っている。
よい方法を知ってはいても、昔からの習慣はなかなかなくせない。人間が必要以上に働き過ぎ、コンピューターが眠っているということは無いだろうか？
7. Use shell scripts to increase leverage and portability. シェルスクリプトによって梃子(てこ)の効果と移植性を高める
shell scripts はソフトウェアの梃子を活かすと同時に移植性も高めるという2つの効果がある。
8. Avoid captive user interfaces. 過渡の対話的インターフェースを避ける
いくつかのコマンドは、「ユーザーを拘束する」インターフェースを持つ。
そのコマンドを実行してしまうと、実行中に他のコマンドを実行することはできない。
そのコマンドの実行中は、ユーザーはそこをはなれられなくなってしまう。
この類のものを「拘束的」ユーザーインターフェースと呼ぶ。
先端技術の胸囲を使いこなすにあたっては、ユーザー側にもある程度の知識が必要となる。
モノが小さくなって高度になればなるほど、使うために必要な知識も増してくるように見える。
以下の様な特徴がある
・小さなものは人間にあまり良く馴染まないということ。
・小さなものは、人間とはよく馴染まなくても、互いにはよく馴染むということだ。
コンピューターソフトウェアの世界においても、
小さなプログラムやモジュールを数多く持つことで環境への適応能力は最大となる。
しかし、残念ながら、モジュールが小さくなればなるほど、ユーザーとのインターフェースという問題が大きくなってくる。
モジュールの数が増えれば増えるほど、取り扱いも煩雑になる。
そこにソフトウェア設計者にとってのジレンマがある。アプリケーションに最大の柔軟性を求めて、数多くの小モジュールから構築する。
しかし、一方では、ソフトウェアを使いやすいものにするという要件も無視できない。モジュールの数が多すぎると扱いが困難になる。
UNIXは、この矛盾を解決するためにユニークな方法を用いる。
ほとんどのシステムは、ユーザーとモジュールとの間に広がりつつ有る溝を、「拘束的」ユーザーインターフェースと呼ばれるソフトウェアで埋めようとする。
UNIX開発者も溝が広がる一方であることは認めている。
しかし、ユーザーとモジュールとを大量の「スパゲッティ」コードで結びつけるのではなく、その溝を少しずつ小さな塊または層にして減らしていこうとする。
UNIXユーザーの多くは、ユーザーが誤ったパラメータを入れると、必要なパラメータとその使い方を示す簡単なMessageを表示する。
UNIXユーザーが拘束的なユーザーインターフェースを避けるのには、もう少し深い理由がある。
UNIXユーザーにとっては、コメンど同士を対話させる方法が必要なのだ。
拘束的プログラムはユーザーを人間と想定している
拘束的プログラムの開発者は、キーボードの前に人間がいるという前提で設計している。
コンピューターが人間の限界に制約され、システムがユーザー入力を待つ必要があると、
キーボードの前に座る人間と同じ早さでしか動作できない。つまり、全く早くないということだ。
姑息的プログラムは「大きい物は美しい」的アプローチをとる
拘束的プログラムは、他のプログラムと結合するのが難しい。
拘束的ユーザーインタフェースはスケーラビリティに欠ける
最も重要な事に、拘束的ユーザーインタフェースはソフトウェアの梃子を効果を利用できない。
「Yes/No」やユーザー入力、その他の応答をユーザーから引き出したりする。
9. Make every program a filter. すべてのプログラムをフィルタとして設計する
ソフトウェアの本質は、データを処理することで、生成することではない。
その能力を最大限に発揮するためには、プログラムをフィルタとして動作するように設計すべきだ。
すべてのプログラムは、何らかの形式のデータを入力として受け入れ、何らかの形式のデータを出力として生成する。
プログラムはデータを作らない。人間がつくる
一般にはアプリケーションがデータを作ると信じられているが、実際のところ、アプリケーションにはデータを作る能力など無い。
データを作るには、想像力が必要だ。そして、オリジナルの情報源が必要だ。コンッピュータは情報源を持たない。
コンピュータは、データを一つの係止から別の形式に変換する。