スキップしてメイン コンテンツに移動

書評 -「UNIXという考え方」について - その1

Mike Gancarz著の2001年発売のかなり有名で既に読まれた方も多い著書だとは思うのだけれど、今も通じる大切なことが多く書かれていると思うので、自分なりに書評をツラツラと書いていければと思います。

これからもし読まれる方の参考になれば幸いです。

1章

UNIXの考え方におけるそれぞれの定理はシンプルで一見簡単に見える

1章ではこれから述べられるUNIXの考え方の定理が簡単にまとめてあり、その中でも1〜3の内容は他でもよく言われていることだが、意外といざ実践となると分かってはいても難しいことに気づく。

特に1の「スモール・イズ・ビューティフル」と2の「一つのプログラムには一つのことをうまくやらせる」を意識するかどうかでも実装が変わってくると思うので、常に頭の片隅に置いておきつつプログラムを書いていきたいし、その為の定石も自分の中に蓄積していきたい。

そう言えば高校の時に数学の先生がいつも「Simple is the best!」って言っていたのをふと思い出しました。

後、UNIXの成り立ちをみていてやはり基礎研究の厚みって重要だなと。基礎研究の中から企業がプロダクトにして世の中に価値提供が行われる好循環があってこそUNIXシステムやその他のオペレーティングシステムが発展してきたと思うので。

2章

とにかく小さいプログラムは素晴らしい

2章ではシンプルで小さいプラグラムの素晴らしさについて書かれている。近年柔軟性を兼ね備えたマイクロサービスアーキテクチャの様な手法が新しいものの様に取り上げられているが、実はUNIXの黎明期からそういう手法というのは存在していて、基本は変わってないのだなと。

逆に言うと近年になってもマイクロサービスアーキテクチャが取り上げられるということは裏を返せば、各々分かってはいるものの中々実際には多くの困難が伴うことを表していて、新しいサービスであればまだしも既存のサービスを変えていくことはそれだけ難しく、それは世界中の多くのサービスが抱えている問題でもあるのかなと。

それからlsコマンドがここではUNIXの理想から離れた例としてあげられていたのだが、普段全くそんなこと考えもしなかったので、UNIX力まだまだだなぁと感じました。


「UNIXという考え方」の書籍の購入はこちらからどうぞ。


以上、3章へつづく。

コメント

このブログの人気の投稿

書評 -「UNIXという考え方」について - その3

    前回に引き続きMike Gancarz著の「UNIXという考え方」について、書評を書いていければと思う。 4章 ソフトウェアが短命で終わるか否かは移植性を重視して作れるかどうかにかかっている 4章では効率より移植性が重要であり、例え効率を求めたとしてもそれは間もなく新しく来るスペックのものが来た時に残念ながらその努力はあまり意味を成さないものとなってしまうことがAtariの例も挙げられながら書かれている。 これはデータでも同様のことが言える。 取り巻く環境が変化することを前提にソフトウェアを書いていくこと。 その為繰り返し呼ばれている様な箇所以外で最適化にリソースを割き過ぎると環境が変化した時に対応することが困難になる。 その為にもまずは移植性を重視する必要がある。 環境が変化して、新しいハードウェアが登場しそこに移植さえ上手く出来れば前の世代のハードウェアで懸命に最適化して得られた効果よりももっと大きな効果を得られる。 昨今、もはやデファクトになり移植性の為にも無くてはならない存在になっているDocker。 従来以上に開発からサービスのリリースまでのスピーディーさが求められてる世の中になっている様にも感じるし、その為の環境もかつてよりかなり整備されてきている。 こういった環境の中で、効率性を上げるというよりかは、移植性を上げる方が将来的な環境の変化のことを考えると喫緊の課題と言える。 そもそも効率化や最適化を余りにも重視したところで、環境が変わって動かなくなれば元も子もないのだから。 「UNIXという考え方」の書籍の購入は こちら からどうぞ。 以上、5章へつづく。

Terraformのど基本 - その1

はじめに Terraformに関して、現在ではエンジニア界隈でどの位浸透してきているのだろうか。自身はインフラエンジニアからのスタートでは無かったこともあり、DevOps周りに興味を持ち始めてから知るようになってきたという感じだ。 ここではTerraformがどの様なものなのかという概要と使用にあたってのど基本の使い方の流れを解説していければと思う。 Terraformとは何か? 一言で言うのであれば、Terraformはコードでインフラを構築する為のツール。もう少し詳しく言うとコードによりAWSなどのクラウドサービスをコントロールする為のAPI的な窓口を提供しているものと個人的には認識している。 なぜTerraformが必要なのか? ではなぜTerraformが必要になってくるのか、もしくはなぜあると便利なのかと言うと簡単には次の2点に集約されると思う。 まず1点目はコードでインフラを管理する様になるので 構成管理をGit管理することが可能となること 。2点目はTerraformを使用することで 環境の構築または破棄が容易となること であると考えている。 つまりGit管理が可能となるので、インフラの変更の跡をコミットで残すことが出来、アプリケーションのコードの様に開発者間で構築内容を共有出来るということである。従来であれば例えばAWSのコンソール画面からポチポチとセットアップして構築していた為跡を追うのが面倒であったし、跡をドキュメントなどで残していたとしても今度はドキュメントのメンテナンス作業にコストが発生してしまっていた。 それからTerraformを使用することで環境の構築と特に破棄の面で便利さが実感出来る。恐らく1度そこそこのインフラをAWS等で構築したことがある方であれば分かると思うのだが、コンソール画面からポチポチと消す作業などをする際にその消す順番を誤ると消したいものもなかなか消せないという場面に遭遇したことはないだろうか。 これは一つ一つのサービスの依存関係によることが多いのだが、その辺りを消す際に確認せずとも比較的安全にそしてキレイに破棄を行ってくれる。これは地味にTerraformの有り難い機能の一つであると考えている。 なぜTerraformなのか? ここででは他にも同様のサービスは無いのかと思っている方もおられるかもしれないので、一応軽く触...

書評 -「UNIXという考え方」について - その5

       前回に引き続きMike Gancarz著の「UNIXという考え方」について、書評を書いていければと思う。 6章 過度の対話的インタフェースを避ける 6章では主に拘束的なインターフェース、プログラム、コマンドパーサーを避けなければならない理由について書かれている。 ソフトウェア設計者にとってのジレンマ 小さなプログラムやモジュールを数多く持つことで環境への適応能力は最大となるが、取り扱いも煩雑になる。 UNIXはユーザとモジュール間に広がる溝を少しずつ小さな塊または層にして減らしていこうとすることで解決を図る。 拘束的ユーザーインターフェース このアプローチの欠点は多くのアプリケーションが稼働するシステムだったり、あるコマンドを実行していてもそれを終わらせるまでは他のことが出来ない。 何故、避ける必要があるの? UNIXユーザーにとってコマンド同士を対話させる必要がある。UNIX環境ではどのコマンドも単独では存在できない。様々な時点でコマンド同士が対話する前提だから。 拘束的プログラム ユーザーを人間と想定している為、人間の限界によって動作を制限されるようなシステムは、潜在能力をフルに発揮できない。 何故、避ける必要があるの? 複雑になった拘束的プログラムは多機能主義と相まってますます大量のシステムリソースを必要とする。 ユーザーが人間であることを想定している為、他のプログラムとのインターフェースは苦手。 拘束的コマンドパーサー あらゆる可能性に対処しようとしてコマンドパーサーが肥大化し複雑になる。UNIXプログラマはユーザーインターフェースへの対処を避けて通る。典型的なUNIXアプリケーションにはコマンドパーサーがない。 その代わり、コマンド起動時にユーザがコマンドラインに動作パラメータも入力することが前提になっている。 何故、避ける必要があるの? ソフトウェアのテコの効果を利用出来ず、他のプログラムとの対話を妨げるので、その効果をコンピュータ世界に広めることが出来ない。その為やがて取り残されて魅力を失っていく。 すべてのプログラムをフィルタにする 世界は、人間が作り出したデータで溢れている。コンピュータが発明されていなくても、データは存在している。 コンピュータは、データの収集とフィルタリングを効率よく行えるよう...