なんとなく、技術文書を小説風に書いたらどうなるんだろうという思いが巡って、それをなんとなく実現したしょっさんです、こんばんわ。

久しぶりに目眩におかされて、その結果生み出されたものがこれだったと認識していただければ、それで良いです。あと、面倒なので読み返してないです。Typoは静かに教えていただけると幸いです。なお、書こうと思えば1行で書ける内容をここまでのばしたんだから、これはもう小説でいいや、と言う投げやりな気持ちです。

こばむもの

わたしは、ずっと拒んでいた。

プログラムを書くことは好きだ。なんなら朝から晩まで、はては食事を何度か抜いたってプログラムを書き続けることはできる。考えたロジックが動くさまは見ていて楽しいものだし、コードを見ているだけで幸せにもなれる。そして、単純なロジックであろうと、複雑なロジックであろうと、それが実現された後、どんなに簡素化されたアルゴリズムとコードでそれが実現できるか。そのリファクタリングの繰り返しこそが人生の楽しみと言っても過言ではない。洗練されたアルゴリズムと、美しいコードは世界を平和にさせる、そう常に信じている。

そう、アルゴリズムは尊い。生まれた赤子を見て、人生の尊さはかなさを感じるのと同じように、アルゴリズムに尊さを覚える。洗練されたアルゴリズムは、無駄のないスリムなコードを紡ぎ出す。そして、そのコードは最小の手数で実行され、期待する答えを導き出す。そこが、すべて自分の世界であり、私の生きる範囲だ。必要なインプットを与えると、それらは生き物かのように動き出し、決められたアルゴリズムに従って、期待したアウトプットを出力する。入力も出力も、至ってシンプルなものが良い。この世界はテキストが全てだ。テキストで準備されたデータは、好きなように如何様にでも加工ができる。数字は数値としてだけではなく、文字としても扱える。そのテキストをどのように扱うかは、全てプログラムが決めることだ。そして、そのプログラムは、私がコーディンする。したがって、そのテキストをどのように扱うかは、すべてわたしの手にかかっている。

「神だ」

中学生のころ、マシン語とアセンブラだけが正義だった時代。いかにシンプルで、最適化されたアルゴリズムを導き出し、それをアセンブラで最短のステップで実行させることができるか。それが全てだった。21世紀の今とはちがい、1980年台のコンピュータはリアルタイムにゲームを処理するためには、CPUはもとよりハードウェアを直接叩くことでしか、その性能を享受することができなかった。今でこそ、インタプリタで実装されるスクリプト言語でもゲームどころかAIのバックエンド園児人にすることができる時代となったが、そうほんの30年前まではマシン語が正義だった。そこへたどり着くためには、洗練されたアルゴリズムとシンプルなコードだけが全てだった。

いかに単純化し、人の目を欺き、少ないリソースで迫力のあるゲームを実現しうるか。まだ、だれも今の世界を思い描けない時代、コンピュータを巧みに操ることは神の所業であった。

0と1で構成される電圧の差が生み出すゲームは、人々を耽美の道へと導き、そして愚弄していった。それらを作り上げた者たちは「神」と呼ばれた。少ないドットで構成されるキャラクタは誰でも方眼紙があれば生み出すことができた。その小さいドットの組み合わせで、どのように世界を表現するか。人は、みな心血を注ぎ、500×500よりも少ないドットだけで画面を表現した。今であれば、ほんのアイコンにしかならないようなドットの構成でも、その当時は髪の描いた蜃気楼のようなものであった。

時代は変わった。

金さえあれば、無尽蔵に使い続けることのできるリソースと、カンタンに作り上げることのできる3Dのキャラクタ。自然界に存在するものと同程度に発色する薄いモニタ。すべてが浮き世離れした世界になった。プログラムはアルゴリズムが全てではなくなった。すぐに動くことが求められた。アルゴリズムを考える前に、動くコードが求められた。動くことが良しとされた世界観。時間をかけて、高速に動作するアルゴリズムを生み出す前に、同等の動作を実現するための簡易なコードが求められた。

そして、入力も出力も複雑なものになった。

わたしはずっとロジックだけを作りたかった。画面を作ることはデザイナーのすることで、ロジックだけを準備すれば良いと考えていた。しかし、アプリケーションを作ることを目的、生業としていない開発者は、美しい画面も同時に準備することで利用者の目を引き、名声を上げることは必要不可欠だ。多少見栄えの悪い画面を準備しても、動けばよいということはない。多少動かなくても、見栄えの良い画面のほうが重宝された。見た目は重要だ。内面の一番外側が外面だ、なんて言われたこともあった。見た目が良いことは、中身もよいだろうことを、後押ししてくれる。しかし、わたしはそこに屈したくなかった。

ただ、時代は変わった。

動けばよいという時代はとうに終わっていたのだった。もう私は次の一歩を踏み出すしかなかった。しかし、画面を構成するためにはいくつもの試練がある。バックエンドのアプリケーションの開発はカンタンだ。シンプルな入力にシンプルなアウトプット。これまで生きてきた世界と何も変わらない。しかし、フロントエンドの世界はちがった。ちがっていた。フロントエンドでは文章の構成を表現するもの、構造にあわせて視覚的に表現を与えるもの、そしてそれらに動作をつけるものがある。わたしは、まず動作をつけるものに一歩を踏み出すことにした。画面の構成や見た目はあとでもどうにでもなる。しかし、画面に動きを与えるためのロジックや、処理の方式には採用するフレームワークによって覚えるべきことが異なっている。できるだけカンタンに画面へ影響を出せるフレームワークにしたかった。覚えることは極力すくなく、学習コストを下げておきたかった。もう、若くはない。少なくとも折り返しの頃合いは過ぎただろう。これからは、ただただ老いを感じていく、そして老いとともに人生を進んでいかなければならない。活動できる時間も、そう多くない。あたらしく学ぶための時間は、少なければ少ないほど良い。

もう、拒んでなんかはいられない。新しい一歩だ。

なにを選択すれば

マシン語やC言語を嗜んできた自分からしてみれば、Javascriptなど容易でしかるべきと考えていた。しかし、その考え方はずっとずっと甘かった。使える機能を複雑に絡め、抽象度の上がった最新のプログラム言語たちは、それ単体でもできることが多すぎた。構造化アプローチだけで実現することのできた過去とはちがい、オブジェクト指向とは一線を画す、プロトタイプ型の実装であり、関数型の表記も可能だ。コールした関数の返り値を関数にすることもできる、いわゆる高階関数というやつだ。サブルーチンをコールした後、何が起きたかわからずにメインルーチンに戻っていたマシン語の世界とは異なり、返したいものを、返したいように何でも返すことができるようになった。その結果、複雑度は増し、プログラムのコードを追ってみても何が実現されているのかわからないことが多くなった。言語の仕様とはまったく異なる世界で、フレームワークやライブラリが、容易には実装できないことをいともカンタンに実装してみせた。こどものころ、なんでもできる大人たちが眩しかった。それがどうしたことだろう、なんでもできる大人になったはずなのに、何もできないじゃないか。ただ、ここで屈するわけにはいかなかった。オブジェクト指向の書籍をつまんだかと思えば、今日は関数型だ。時間もないし、できることも限られているが新しいことを拒むだけでは先に進むことができない。必要なことには時間をかけよう、そう、考えていた。

「Googleの開発したAngular、FacebookがつくっているReact、そしてReactを開発していた開発者がスピンアウトしてできたVue.jsか」

フロントエンドのフレームワークとして、今、よく利用されているものはこのの３つだ。GoogleとFacebook。GAFAで構成される「A」以外の２つが作り始めてフレームワークとは感慨深い。AppleとAmazon。「A」からはじまる二社はわかりやすいプロダクトを販売している。Appleは自社開発をしていてそれを販売している。Amazonはほとんどのものが他所で作られたものを販売している。業態としてはわかりやすい。物を売っている。GoogleとFacebookは何を売っているのだろう。Googleはメインの検索は無料で使わせているし、多くのサービスも無料で利用できる。FacebookはSNSだ。特に何かを売ろうってことではない。二社のメインは広告費であった。産業の始まりが、このフロントエンドのフレームワークの開発へ導くことになろうということではないのだろうか。余計なことを考えてしまう。

歴史を紐解いてみると一番古いのはAngularだ。2009年から開発されている。一番最後に発表されたのはVue.js。2014年だ。秒進分歩と言われるIT業界では5年というのは数世代の開きが出てしまう。この5年のひらきが何を意味するのかは、いま現時点ではわからないが、調べてみれば何かが分かるかもしれない。もう少し、調べてみよう。

実は、AngularとReactの本は持っている。数年前になるだろうか、これからはフロントエンドの時代だと、今と同じように考えた時期があった。しかし、本を買って満足していた。いわゆる積読というやつだ。積んで満足している。わかった風な気になるアレだ。実際は読まなかった。決意が足りなかったのかもしれないし、仕事が忙しいということをやらない理由にしていたのかもしれない。もう、その頃のことは思い返すこともできないが、とにかく読まなかった。学ぶことはなかった。

この機会に、読んでみてはどうだろう。わたしのモチベーションが声を上げた。一番気になっていたのはAngularだ。Angularだけでほとんどのフロントエンドアプリケーションを開発できるフレームワークを維持している。それもそのはず、技術力には定評のあるGoogleが作ったもので、今も開発が継続されているということは、それだけ利用され、品質も担保されていることを意味する。ああ、いけない。昔のソフトウェアとは違う。過去、旧態依然のソフトウェアは、あるバージョンが発表されると、そのバージョンが継続してメンテナンスされていた。いや、今でもあるだろう。このバージョンでは新機能を追加することは積極的に行われず、バグの修正に時間が割かれた。長い時間をかけて、ソフトウェアは枯れていき、安定した。今はそうではない。バージョンは常に上がっていき新機能はどんどん追加されていく。もちろんバグフィックスもされていくが、新機能にはバグがあってもおかしくはないだろう。求めているのは安定性よりも、イノベーションだ。

Googleはバージョンアップに最も積極的だ。定期的にメジャーバージョンを上げていく。わかりやすいのはChromeだろう。Version 72だ。信じられない。

ReactはもうすぐVersion 8が出てくる。わたしが持っている書籍はAngular2と4。いささか古すぎるのではないか。しかし、基本原則はそう変わらないだろう。少しでも新しいものを、ということでAngular4の解説本を手にした。技術書といえばずっしりと重いものがほとんどだ。100ページでは解説できないものがほとんどで、500ページや600ページになるものも多い。「よし」時間を決めて、Angularでできることは何か、そこに集中して踏破することに決めた。目次を眺めただけでも、だいぶわかった気はするが、あとは気になるポイントをおっていって、思い浮かべたアプリケーションを実装するにはどうしたら良いかを考えた。しかし、どうしても受け入れられなかった。原因は「Typescript」だ。JavascriptのトランスパイラであるTypescriptであるので、そう大してちがいはない。しかし、ずっと違和感がこびりついて、うまく理解することができなかった。

「一旦、他のものを見てからにしよう」

Typescriptの壁を超えてでもAngularにすべきかどうか、他のフレームワークを見てからでも良いだろうと、Angularのことを一旦わすれることにした。残っているのはReactとVue.jsだ。いずれも、本体はシンプルな構成で組まれていて、必要に応じて他のライブラリを組み合わせる仕様。いずれもJavascriptで書き記すが、Typescriptなども利用できるようだ。ここは、Facebookが開発しているReactを採用したほうが良いのではないだろうか。そんな考えがよぎった。Reactであれば、技術者にはおなじみのオライリー本もある。どちらもスモールスタートに向いているということであるし、対応しているライブラリはReactが多く、利用している企業も大手が並んでいる。信頼性や品質もReactが上ではないだろうかと、容易に想像がつく。

「まてよ、ひろきはVue.jsを使っていると言っていたな…」

東京の駅で一緒に仕事を営むひろきは、日々、フロントエンドのアプリケーションデモを開発している。彼らのチームは、フロントエンドでの開発を多用している。その彼らがVue.jsをメインに使っているという話を聞いたことを思い出した。「カンタンですよ」そう、うそぶいていた。そうか、少し試してみるか。

また本を読んで、それで終わってしまっても仕方がないと思い、実際に手を動かしながら学ぶ方法を選択した。ちょうどよいことに、Kindle unlimitedに速習本がでていたので、良い機会だとKindleで画面を眺めながら実際にコードを打ち込んで作ってみた。

「たしかにカンタンだな…」

ReactもVue.jsのいずれも、MVCモデルで言えばViewの部分を司っている。表示部分を実現するためのフレームワークとして提供されている。構造を記すもの、デザインを表現するもの、ロジックを扱うもの、これら３つを上手く分離して記述することが容易だった。まとめて記述することも、分離することも実にスムーズに利用できた。利用する本体のフレームワークも１行で記すことができる。また、構造とロジックを紐付ける部分が明確にできるので、不用意に余計な場所への影響を抑えることができるのではないかと考えた。ここで、Reactを１行も書かずにVue.jsにすることを決めている自分がいることに気がついた。技術者御用達のReact入門書もまだ開いていない。技術者としてあるまじき行為ではなかったろうか？純粋な比較検討をした上で決めるべきだ…。

入門書を手にとって眺めてみる。ん…JSX…？Vue.jsでもJSXは利用できるようだが、入門書などではとっかかりが良いように、純粋なhtmlにscriptを埋め込んでいる方式をとっていたのだが、Reactではどのようにテンプレートを記述するか以前にJSXを使うことが延々と説明されていた。Javascript内にhtmlを記述する方式を紹介しているものも多い。やっとたどり着いたもので、やっとhtmlに直接記述するタイプを発見したが、どうもおさまりが悪い。Angularのときにも覚えて違和感がそこにはあった。「かっちりしてる…」すぐに始めるという方法に対して、AngularもReactも「この方法で実現すると良いよ」の最初の壁が高かった。htmlを準備してそのまま利用可能なのはVue.jsだ。Reactも同様の方法はあるが、標準的ではないようだ。AngularはTypescriptをベースにしていることで、トランスパイルやら何やらで、パッケージをある程度きっちりして始めたほうが良さそうだ。

自分の心が決まった。あまり時間のない中での選択ではあったし、この選択が正しいとも言えない。しかし、早く始められて、最初に障壁の少なかったVue.jsとの恋に落ちた。自分の心は決まった、さぁ、次はカスケーディングスタイルシートだ。

(続く)