LINUXとUNIXの思想2

UNIXの原点の思想について。覚書２

・ASCIIをもって尊しとする
　データの保存は、原則アスキーファイルする。そのＪＯＢに特化したバイナリデータは避ける。組み合わせることを前提とし、効率より移植性を大事にしていけば、出てくる結論は、ASCIIだ。　ここにはデータに対する哲学が含まれる。動かせない、再利用できないデータは死んでいる。特定の何か（人、アプリ）でしか扱えないデータであるとすれば、それはデータを人質にとられている。処理速度の問題？まあね、でも、それ、来年にはもっと早いマシンになってるんだぜ。


・使えるものは使う。作ったものは使い倒す。
　小さく、組み合わせのしやすさに重きをおいた。勿論、それは自分のコードだけではなく人のコードも、組み合わせて使う。自分のコードも使わせる。UNIXのソースコードは無料で配布されていた。秘密にしておく価値があるのか？

・データをしゃぶる、使いまわす。紙に出さない
　紙に出たデータはそこが終着だ。再利用には極めてコストがかかる。検索もできない、暗号化もできない。そのデータは死んでいる。紙に書くな、書くエネルギがあるならASCII入力してしまえ。
　
・１０％の努力で９０％の問題を解決する
　人の生き死にや、銀行口座のシステムで無い限り、９０％の問題に対応すれば十分なことが多い。残りの１０％を満たすためには、それまでの１０倍のリソース、コストを投入しなければならない。
　

LINUX UNIXの思想 １

言うまでもなくLAMP,LAPPの L は、Linuxだ。
若いエンジニアが 2w3w で訪れてくる時、あるは、社員採用に応募してくるサーバ￥ネットワーク系の技術者から、こんな話あった。「Linuxは自信あります。けどUNIXになるとちょっと・・」

おいおい。
勿論、/etcやらのconfig関係は、ずいぶん変わってきているのは事実だ。最近のSOLARIS10は、従来の定番の管理手法が通用しないという泣き言も聞いている（というか、俺も泣きたい）。
まあ事実ではあるな。

で、質問してみる。
「LINUXでも、HP-UXでもSOLARISでも、共通している考え方、原点の思想ってあるんだが、それはわかるかい？」「最初にUNIXを作った人の考え方とか、使いながら考えたり、体感したことあるかい？」
細かいパラメータの違いは各O/Sにあるのは事実だけど、そんなものをたくさん丸暗記したってしょうがない。いつか変わる。そうじゃなく、変わらない思想や考え方が身についているかなあと、たしかめてみている。何とかなりそうだなあと思える人は半分くらいかな。

いくつかのポイントを書いておく。
文中のUNIXはLINUXと読みかえても差し支えない。

・スモールイズビューティフル
　カーネルも、シェルも、各種コマンドも。小さいからわかりやすい、組み合わせしやすい。組み合わせなんて、今でこそコンポーネントが当たり前だけど、当時としては画期的。

・ひとつのことをキチンとやる
　組み合わせすることを前提とすれば、ひとつのことだけ、きちんとできればいい。ひとつのことのレスポンシビリティを保証すればいい。
　クラス設計をする時に避けるべきことに、何でもやっちゃうウルトラなクラスを作らない。先の小さいことはいいことだとあわせ、これは今でも設計開発に通用する原則だ。（不慣れだとついやっちゃうんだよな）

・さっさと試作する
　勿論、これは機能仕様や要求の整理の重要性を否定するものではない。しかし、聞いても、事前に調べても、埋められないことがある。その時には、ちゃっちゃとプロト・サンプコードを書いて、リスクを減らしてしまう。UNIXそのものには、設計書は存在しない。簡単な機能メモは作られたかもしれない。現在、書店に行けば、山ほどのUNIXの仕様について書かれた本がある。しかし、それらはできあがってから書かれたものだ。UNIXそのものの開発プロセスが、レガシーなウォターフォールを排斥して進められてきている。

・実行速度より移植性
　UNIXそのもの開発者の頃でも、「来年にはマシンの性能は、Ｘ倍になる」と言われていた。チューニングなんて意味がない。基本のアルゴリズムがダメダメで、あまりにムダなことをやっているコードや、腐ったSQLの話は別だが。繰り返し使われ、コールされる回数の多いサブルーチンは、チューンする価値はある。
　最も効率のよいコードは、移植性を犠牲にする。あるいは、もっとも、ユーザインターフェースに優れたコードは移植性を犠牲にする。後の話は最近の携帯電話での開発の余談だ。機種独自機能を使えば、１年後は大変だ。

まあ、HP-UXや今のSOLARISに、原点の思想がどこまで残っているの？は、議論の余地があるのは承知しております。
「変わり果てたからこそ、Linuxだけに原点が生きているんだ」という、よくわかっているグルやウイザードの方々には、私ごときは逆らいません。逆らいませんから色紙にサイン下さい。

PHPフレームワーク Ethna(エスナ)

PHP5用のフレームワーク。今回、初めて仕事に使用してみている。規模は２人月。暫定サービスインは、7/13で、その頃には、結論も出せるだろう。

他のフレムワークと比べて、勿論いいところもあるし、足りないところもあるが、メンテをする人が日本であることが嬉しい。サイトはここ->
画面系がsmartyを前提としているあたりも、敷居が低い。

strutsに構造が近く、Mojaviの人にも、似ていると受けとられている。何より、見通しがいいと思わせてくれている。

PHPフレームワーク phrameとMojavi

phrame は、Strutsの設計思想を継承していて、JAVA/Struts 環境から移行してきたプログラマには、習得の面では、非常に魅力的だと思う。開発する組織・会社で、JAVA/PHPのプログラマが兼務することが多いような場合であれば、教育コストを考えると、悪くない選だと思う。しかし、JAVAとPHPの言語仕様が違う現実の中、PHP用フレームワークとして「最適」と断言するには少し無理があると思う。
調査程度はやったが、実プロジェクトには使っていないので、このへんで。

Mojaviは、非常にシンプルなフレームワークだが、PHP用に作られたが故に、フレームワークのもつ共通のメリットの他に、いくつかの優れた特徴を持っている。

Mojaviを使っているチームや組織も多いでしょう。実際、うちの会社でも、ここ何年か、使ってきた。

PHP5を前提としたフレームワーク

「低コストで短い期間で・・」どのようなシステムでもそうだ。社会の要請といってもいい。
特に、Web・携帯アプリケーション開発に対する要望は、よりシビアな昨今だ。
答えのひとつがフレームワークの活用だが、現在MVCモデリングが主流となっている。
フレームワークのメリットは大きく２点ある。
・MVCに代表されるデザインとビジネスロジックの分離による保守性・生産性の向上
・フレームワークというルールに則って実装することによるコードの均一化、品質の向上
などなど、今となってはわかりきったことだが、Windows プラットフォームでは、.NET 、JAVAプラットフォームではStrutsが、事実上のスタンダートとなり、多くのプロジェクトで使われてきた。

その中で、PHPにはデファクトスタンダードと言い切れるフレームワークがない。
PHP4の成功による裾野の広がりから、その状況が変わってきているが、まだ試行錯誤と言えるだろう。
phrame 、Mojavi、 Ethna が気になるところだ。

PHPの歴史 PHP5の優位性

PHP5は、それ以前のバージョンとは、多くの点が改良されている。PHP4の基本的な文法は、Zend Engineと呼ばれるスクリプトエンジンだった。PHP5が多く使われ出している今となっては、異論も多いが、当時としては、洗練された構造かつ容易に拡張可能な言語エンジンとして優れていると言える。これはそれまで、*場当たり*的な拡張を繰り返してきたPHP3に対する反省と要望の賜物だろう。

Zend Engineは、PHP4を成功に導いた。そのため利用用途もより広範囲・大規模になり、エンタープライズ用途にPHPを利用する・・・という、ある意味冒険的な構築も行われた。（当時の僕なら、そんな選択はできなかったかもしれない。）

こういう利用は、Zend Engineの開発者達の想定を越えた広がりだったと思う。当たり前のことだが、大規模サイトを構築する際のコードの再利用性の悪さといった問題を呼んだ。
技術面か、最も問題視されたのは、PHP4のオブジェクト指向機能の弱さで、JavaやC++に慣れたプログラマからは、不満が多く寄せられ抵抗された。

もちろん、PHP4でもオブジェクト指向機能を徐々に加え改善され続けてきた。世の中にはオブジェクト指向COBOLだってあるんだ。付け加えることぐらいは、できるわな。
しかし、基本的なZend Engineの文法を大きく変更することまではできない。そうなると開発者達それぞれが、職人的努力と技量で、PHPなりの記述方法を新たに開拓し、目的を達成しようとした。
努力は涙ぐましい・・。でも、それに変わる処理系がなかったんだよなあ。
職人のような努力をすればするほど、（目的のシステムはできるけれど）、わかりにくコード群になるわなあ。保守性を切り捨てることになる。

さてPHP5は、これらの問題に、抜本的な解決を与えるために作成された。
各種extensionの対応やPEAR、クラスフレームワークの新機能への対応など、JAVA C++の経験者には、「便利」「再利用性高まった」と思える機能も、PHP3やPHP4*だけ*に慣れたプログラマにとっては、敷居が高くなったとも、考えるべき要素が増えたとも、いえる。

PHP5のもつヨサを生かすには、プログラマーやチームに、スキルが要求される。
僕は、2005-2006年、WEBとIP電話の交換機(PBX)の繋ぎこみゲートウエー構築プロジェクトに、PHP5を選択した。従来であればJAVAまたC++を選んでいただろうが。

他システムとのI/Fすりあわせ等、言語そのものとは無関係の苦労が多いプロジェクトではあったが、PHP5によるコンストラクションそのものや、その後の運用(かれこれ１年）には、何ら問題はなかった。

PHP5でやらせて

LAPP,LAMPの話の場合、つまりほとんどのWEB系開発の場合、特別の事情や制限が無い限りPHP5を使わせてもらいたいとお願いしている。

過去あった特別な事情とは、

・既存サイトがPHP3 PHP4 で作成されおり、プログラム資産の継承が重要な場合。
・利用しているIDCのサービスが、PHP4の利用しかできない場合。
・お客様が、Perlがどうしても好きな場合
・製品版のJVM を用意する予算が有る場合(tomcat はお勧めしない）
・既存のサーバがWINDOWSベースなので、.NetASPでの構築が自然な場合

LAMP LAPP

WEBや携帯サイトの構築において、LAMPあるいはLAPPでの開発のメリットは広く知られるようになり、問い合わせをいただく場合も、それを前提としていることが多い。
実際の受注も、バージョンの差異はあるものの、基本的にこの組み合わせで落ち着く。

LAMP Linux Apache Mysql Php
LAPP Linux Apache Postgresql Php

これは、無償ライセンスでありながら、
・Linux + Apacheの組み合わせの実績、
・大半のWebサイトには必要十分な機能を提供できるMysql Postgresqlの機能
・Java(Tomocat等)よりも軽く安定したPHPの実行エンジン
等が実績として評価されてきたことによるのだと思う。

重宝されているLAPP LAMP ではあるものの、APの規模が大きくなり開発に従事するメンバーが増えてくると、それなりに種々の課題・問題が産まれる。これは別に、LAPP,LAMPに限った話ではないが、LAPP,LAMPも、やはりそれらの課題からは免れない。すべての問題を解決する魔法の手法ではない。
小さな話であれば、品質には大きな影響はなく、やっつけてしまえるものの、規模がある際は、当たり前のシステム構築の手法を積み重ねていく必要がある。