サーバレスについて考える

サーバレスとはサーバが要らないことではないらしい、今までのローカルで扱っていた
サーバをクラウド化し、サーバの機能が極端に疎結合化されることらしい。

それが実現した場合、クライアントとサーバとのデータの交換形式はどうなるか？

JSONやXMLになっている。

最近のMVCの取り組みがまさしくこれを導く流れになっている。

だとするとBackbone.jsというクライアントのMVC技術は良い選択だろう。

クライアントの実装モデルはオブジェクト指向で良いかもしれない。

設計技術はフューチヤモデルを私は推薦している。

今の携帯の機能はクアッドコアCPU＋16コアGPUが当たり前になりつつあり、
もはやパソコンと同等なレベルまで来ている。

単にブラウズするだけであれば、十分な機能を備えている。

サーバの機能は、ひたすらデータの入出力だけで画面のことなど気にしないでいい。

クライアントとサーバの関係は疎結合化が実現していることになる。

サーバレスは、技術的にもコンセプトとしても
まさしく実現できる状況は全て揃った状態になっている。

サーバの疎結合化でアプリケーションを構築する世界は障害に強くなる。

そろそろ何か現実的に役に立つ、アーキテクチャを試行していこうと思う。

MVCとフィーチャモデルを考える

スマフォが当たり前の世界では新しいモデルが必要になります。
画面の美的なデザインのことも考慮する必要があります。

非機能要件が重要なファクタであることを前提にして考えます。
そもそも動的な画面を設計する有効な方法があるのか疑問です。
WEBの場合実画面を作成したほうが効率が上がるのではないのかとも考えられます。

---

まずモデルを考える場合、ツールが必要なので、次の２つの概念を用意します。

MVCは、モデル＋ビュー＋コントロールです。

フューチャモデル（FM）は、時間＋空間＋フューチャです。
フューチャには次の性質があるものとします。

1. OP：オプション的なフューチャ
2. AND：フューチャ同志が必須関係
3. XOR：AもしくはBの関係
4. RQ：AならばBは必須、Bは単独では非

この２つの関係は、

FM　<=>　MVC*2　（相互変換、検証）

これをオブジェクト指向型言語や関数型言語で実際に開発することになります。

自動化も前提に考えなければいけません。

追記：（7/26/13)
これのモデルは面白い事に、考え直してみると
JSD法（マイケルジャクソン、（スターのではありません、もう一人の））になっています。
JSDは既に実績がある手法なので、正解の一つである可能性が出てきました。

FMはオントロジー的アプローチであり、MVCはタクソノミー的アプローチになっています。
同じ対象をアプローチが異なる手法で表現していることになります。

---

なぜこんなことを考える必要が出てきたかといいますと、サーバサイドではMVC開発は当たり前。

「クライアントサイドの開発でもMVCは必要か？」、説明がリーズナブルにできないからです。

最近JavaScriptの傾向として、単にAjaxを使うばかりではなく、MVCを取り込む試みがあります。

「Backbone.js」のようなMVCフレームワークをクライアントで使います。

この場合の欠点として、作業量が増大してしまうことや、技術者の確保が問題になります。

クライアントサイドの開発の作業量とアーキテクチャのトレードオフをどう考えるかです。

以上、MVCとFMがシステム開発やゲーム開発で必要になると考えています。

今後はこのモデルで適用可能か検討してみます。

RoRで新しい世代を感じた

最近WEBの開発の世界で何が起きているのか調査してきました。
なんとなく、印象に残る資料が見つかったので書きます。

何を説明するのか期待させておいて、実はRuby on Rails(RoR)の話です。

ただし、Java、PHPやC#を使いWEBを開発してきた人が衝撃を受ける内容になります。

RoRが非常に先進的な技術であることは、ネットでよく知られています。
いざRubyの言語を知らないと感覚が分かりづらいところがあると思います。

やはり時間が大事なので、ダイレクトに知りたいことが伝わらないと面白くありません。
そこでYouTubeの「ドットインストール」さんから提供されている内容を見つけました。

#01 Ruby on Railsの基礎

これは連載になっていて、２分程度のコマで動画を何十も見ることができます。

この内容を見るとRoRがコマンドで流れるような開発を実現していることが理解できます。

簡単に説明するとコンソールを使い、プログラムを作成してブラウザで確認する作業です。
コンソールからはRoRのコマンドで、どんどんプログラムを勝手に作成してくれます。
詳細な仕様は、この後基本ソースを修正することになります。

まさしく、アジャイル開発を非常に手短に知ることができました。

この他に「CakePHPの基礎」もあります。
これでRoRとCakePHPの作業内容を比較してみると面白いです。
明らかに両者に差があるのが解ります。

---

現在は規約に基づいてプログラムを作成（CoC)、改造しながら開発することが流行の時期。
次は、この結果をリバースして追跡し仕様を管理することが来るのではないでしょうか。
例えばセマンティックな差分ツールがあればこれが実現できると考えています。

ようやくその後で、オントロジーやタクソノミー型開発になるのでしょうか。

全てはマトリックス化している

Jenkinsを試しにWindows8にインストールしてみた。

Windows版をダウンロードする。
解凍する。
setup.exeを実行
インストール完了です。

localhost:8080/で画面を開く。
新規ジョブ作成で、外部ジョブの監視を選択保存
適当に画面を操作

以上で全体感を見てみました。

Jenkinsの管理画面は次の一覧

1. システムの設定
2. グローバルセキュリティの設定
3. 設定の再読み込み
4. プラグインの管理
5. システム情報
6. システムログ
7. 負荷統計
8. Jenkins　CLI
9. スクリプトコンソール
10. ノードの管理
11. Manage Credentials
12. Jenkinsについて
13. 旧データの管理
14. ユーザの管理
15. シャットダウンの準備（<->キャンセル）

それにしても管理するだけでもこれだけのメニューがあります。

セキュリティの設定も必要なようです。

操作しているうちに、プラグイン管理に（アップデートあり）が赤い文字で表示されました。

CLIのコマンドは４４種類ありました。

スクリプトコンソールはGroovyです。

日本でのJenkinsの話題を検索してみた。
今は圧倒的にテストやプログラムコード管理に集中している。
今後力を入れるのであれば、
コードの自動生成やリバースに力を入れるのも良い方法ではないかと思った。
特にCakePHP、Rooではコード生成機能が提供されている。
これを使った手法にリバース機能を連携させた方法が考えられる。

話しは違いますが、

「実践スマートフォンアプリケーション開発」オライリージャパンの書籍を購入しました。

とりあえず内容を確認しましたが、
ほとんどの頁（全５５１）は表で３種類のスマートフォンの比較表になっています。

これをまとめるのは大変でしょうが、文書を読むよりも読者がロボット化してしまったようです。
内容説明というよりも
「とにかく比較して考えなさいと」
メッセージを送られているような感想を受けました。

---

まとめ

全体の情報が巨大化してくると全てをまとめることが大変になります。

そこで活躍することはやはりマトリックス的思考でしょうか。
マトリックスの本来の意味は「子宮」で、「作り出すもの」のようです。
まさしくぴったりの言葉のようです。
全てのパラメータがマトリックス構造であると仮定すると、設計デザインのモチーフとして使えることでしょう。

２０１６年の時点で、言葉を追加すると
「全てはマトリックス化し、そしてアルゴリズムがこれを飲み込もうとしている。」
すなわちAI化がこの先にあることか？

プログラム言語の雑貨屋的思考

私が実務や学習したプログラム言語についてコメントしてみます。

Fortran	今でもスーパコンピュータでは使われている。 オブジェクト指向にも対応している。 古くから数学ライブラリが揃っていた
BASIC	PCで使えるインタープリタ。 25年前ですが、実験結果で回帰分析したり、CADを連動させて自動図面を描かせたりした。 今ではVBへ進化した。
アセンブラ	MASM86、Z80を主にプログラミングした。 どのようにプログラムがCPUで処理し、高級言語がどのようにアセンブラに変換されているかが理解できる。 デバイスに対する直接操作が可能
BAT	MS－DOSのバッチコマンド、 言語というよりもOSシステムのコマンドの集合、 今ではWindowsのOSではPowerShellがシステムをカスタマイズ自動化で使われている。
COBOL	カラム指定の言語、事務処理用、
C言語	Javaの前までは一番主流な言語、今でも組込み系では人気、デバイスへ直接アクセス可能。 メモリ破壊が起きやすい欠点がある。
Shell	C,B,K等のUNIXやLinuxでのOS用のバッチ（シェル）言語、コマンドラインで履歴の再利用に便利。
SED	言語というよりも、ストリームエディタ、正規表現だけで処理する。
AWK	SEDを言語に進化したような感じ、C言語をスクリプト化したものとも考えられる。
Lisp	カッコが多い感じを受ける。非常にシンプルな構文で、構文解析をするとこの言語のイメージが解る。 一部のハッカー級の人達が使いこなしていた。 ライブラリーの標準化が見えにくいことや、言語も何種類も分岐して進化しているので初心者が使うには相当な動機が必要と考える。
Prolog	宣言型言語、構文が非常にシンプルな言語、内部DSLが簡単に使える。 DCGの構文解析が有名
SQL	宣言型言語、DSLとも考えられる。RDBのテーブル操作がシンプルに記述できる。
C++	C言語をオブジェクト指向に進化させた言語。複雑な構文を持つ。ゲーム開発の分野では主流
perl	システムメンテナンス系のスクリプト言語。AWKから進化した感じ。
python	インデントでネストを表す言語、欧米では活発に使われている。
TeX	書籍や論文を記述するドキュメントフォーマット。ツールで複雑なコードから印刷へ変換する。
HTML	WEBの代表的なフォーマット形式
Javascript	WEBの代表的な言語、今ではAJAXに進化、Nodes.jsでサーバサイドでも利用
Java	オブジェクト指向のブームで主流になった言語、今では色々な欠点も指摘されている。 今後もレガシーや基幹系の言語では使い続けられる。完成したシステムは巨大な一枚岩になっている印象
XML	HTMLをデータ交換にしたような形式、厳密な定義。色々な規格のベースになっている。 XMLによる宣言型の記述方法もありますが、非常に不評なようです。単なるフォーマットと考えています。
VB	MicrosoftのVisualBasic、BASICのビューを進化した言語。
VBA	MS-ExcelやMS-Wordで直接起動できるスクリプト言語、構文はVBに準ずる。
C#	Javaに対抗したオブジェクト指向言語、今ではJavaよりも先進的な要素を持つ。
PL/SQL	Pascalの構文に似ている。SQLを使い処理まで記述できる。高速な処理が可能
PHP	WEBでの簡単にプログラムができる言語、CakePHP等のFWが有名
Ruby	日本で生まれたオブジェクト指向型言語、先進的な試みがFWで実現されている。 Ruby On Railsでは、プログラムの自動化に成功した言語。 言語仕様はかなり多岐、その分APIを使う必要がない。 記号をメッソドに使える為、変な使い方をすると他人が書いたコードが読めなくなってしまう。
Actionscript	Flashを開発する為の言語、HTML5からはさえない感じ
Haskell	関数型言語の親玉的な言語。モナドが有名。無限を表現可能、遅延評価の有効利用 高度なツールやエンジン部分を構築することに向いている。 ライブラリも数多くあるのですが、もう少し利用しやすくできれば最高なのですが
Erlang	並列処理で有名な言語、Prologからヒントを得た関数型言語、シンプルな仕様。 いまいち将来性が伺えない
Scala	JavaやC#を並列処理化するための関数型言語。Javaの後継になるか？ 構文解析器を持つ。JVMの資産を継承できるメリットがある。
F#	HaskellやOCamlを参考にした言語。ユニークな関数型言語、あまり使われていないようです。C#の補完的な使用が事例ではある。.Netの資産が利用できるメリットがある
Alloy	テストを実施してくれる言語。SATのフロントエンドとして利用可能。 オブジェクト指向言語の仕様をテストすることが可能。
HDL	ハードウェア記述言語、回路設計に使われる、 FPGAはハードウェアの回路をソフトウェアで開発可能にしたもので利用度が増している。

あくまでも主観的なコメントになります。

何を言いたかったかと言いますと数は多いですが、 「Haskellを習得できれば、他の言語を習得するのは簡単」 だと思います。

オブジェクト指向言語はオブジェクトの概念自体は難しくないのですが、APIの階層の深さやFWの仕様が大き過ぎて困る傾向にあると思います。Javaの開発ではシステム全てが同一の言語で構築されます。従って不具合が発生して ベンダーやOSSが提供する基盤までを調査する場合には非常に広範囲な作業が必要になります。

WEBに限れば、中小規模なシステム向きにはシンプルに使えるのがRubyやPHPのFWになります。
スクリプト言語でベースそのものが比較的わかりやすく、システム開発部分が狭い範囲な為開発が楽になります。

関数型言語は、少し言語自体に複雑性があると考えられます。

• ループを再帰で記述すること
• ネイティブで記号や固有の概念を使うこと
• 記号（中置二項演算子）を追加できてしまうこと
• 数学的要素を取入れていること

が原因になっていると考えられます。
逆に、この特性により複雑な機能が驚くほどシンプルに記述できます。 又そこにはバグが入り込む余地は残されていないでしょう。

宣言型言語は、記述において完全な順番を排除したものではないので頭に処理の概念が思い浮かぶようにならないと、使うには難しいと思います。
ただし、SQLは対象がテーブルなので容易に理解できます。
単なるDSLとして考えると複雑な処理をシンプルに記述できます。

関数型言語と宣言型言語は変数の代入が一度だけで、書き換えができないのでこれによる副作用の防止効果は非常に強力なものがあります。

---

これからマルチなプログラム言語の対応することを新しい試みとしてトライしてみます。
「疎な情報」をどうやって、「密な情報」へと関係させるかが当面の課題です。
目的はあくまでも現場で使えるプログラム言語の知識や方法を構築することです。

設計書の証明性について

設計書について考えてみる。あまりにも漠然としているので
そもそも「設計書」と「仕様書」の違いはなんであるのか、
設計書は「設定関係の何らかのパラメータを計算した書類」と考えれば、
非常に正確性が求められる書類と言える。
仕様書とは、頭に要件を着けて、「要件仕様書」が本来の意味であくまでも利用者や
ステークスホルダーが、要求を出す（表す）為の書類を指している。

仕様書は人間臭い情報を内蔵しているが、設計書はかなり数学的で証明（テスト）までを
含んだ側面を持つ。

では、上位工程から下流工程までの設計の関係はどうなっているのか、
人が設計書を作成し利用しているので、当然設計書にも遊びのような部分が多分にある。

そこで設計書を次のように公理的に？定義してみる。

「上位設計書」＜＝＞「下位設計書」＋「非設計要件」

非設計要件とは、デザイン等の概念で解り易く見せたり、美しく見せたりや図を使って俯瞰
したりすることを指す。
こうして考えると、上位設計書と下位設計書はある程度可換でなければいけない気がする。
下位設計は実装関係の現実世界の話しなので、HW、SWやネットワークの設計書になる。
これについても千差万別な選択肢があり、完全な可換な設計書は難しいと考えられる。
やれるとしたら、大企業がナレッジシステムを使えば可能なのか？
何故か矛盾している。

「上位設計書」＜＝＞（「下位設計書」＋「非設計要件」）＋「外部実装仕様」

これで、良いのであろうか。

話は変わりますが、UMLにも謎なところがある。
元々言語なのだから何種類もある図を完全に定義していて開発者に完璧を求めるている。
しかし、規格を考えた人は完全な証明してから、UMLを定義しているのだろうか？
労力を考慮したら、何故UMLから完全なソースコードを自動生成できないのだろうか？
（OCLの問題もあるようですが）
まだまだシステム開発が未熟で、完成形ではないからなのだろか？

結論を直接表現することは不可能でしたので、回りくどい説明になりましたが、

今の時代は、究極のスピード開発が求められているとすると、絶えず先へと前進しないといけない。
しかし、結局開発が完了したところは既にレガシーな領域になってしまいます。
これの繰り返し。
そこで活躍するコンセプトは、設計の可換性であり、これの証明であると考えています。

果たしてこんな公理的なことが可能であるのか今後も考えて行きます。