ハローラスク

https://twilog.org/hellrusk

ビルドシステムの記述自由度と保守性のトレードオフ

突然だが、Makefile というものがある。
主に C や C++ で使われるツールで、この Makefile を作っておけば、 gcc / g++ のコマンド(往往にして gcc –Wall -o hello hello.c みたいに長くなりがちである)をいちいち入力することなく、make と打つだけで肩代わりしてくれる優れものである。
記述量を減らせるだけではない。例えば、 hoge.c を オブジェクトファイル hoge.o に変え、 fuga.c を オブジェクトファイル fuga.o に変えて、さらにヘッダファイル guee.h と一緒にリンクして最終的に実行ファイルを作る ... というような複数の工程を make 一つで済ませることができるというメリットがある。


この Makefile についてちゃんと知る機会がこの前あった。OSに関する授業である。
UNIX系のOSはC言語で書かれていて、Cを使えばOSがプロセスを扱う仕組みをシステムコールのレベルで理解できるので、OSの学習のためにはCを書くのである(もちろん一般的に使われているほとんどの言語でOSを操作することはできる。ただ大体の場合、その操作のための関数/メソッドは人間が扱いやすいように API でラップされているので、「中が本当はどうなっているのか」を勉強するのにはCのような低級言語が学習・研究用によい)。
で、Makefile について「ちゃんと知る」というのはどういうことだったかというと、Makefile の存在自体は前から知っていたが、Makefile が実はとても自由に記述できるファイルだということを知らなかったので、勉強になったのである。
たとえば、Makefileシェルスクリプトのように変数が使える。

CC = gcc
CFLAGS = -Wall

test.o: test.c
    $(CC) $(CFLAGS) -c test.c

他にもググるとと Makefile には無数の文法事項が存在していることがわかる。


もしかしたらCやC++ばかり書く人にとってはこれは当たり前に受け入れている話なのかもしれないが、僕はそうではない人なので、これは面白いことだと思った。何が面白いかというと、世の中のソフトウェア開発で(Cに比べると)一般的に使われているような高級言語では、ビルドシステムの記述自由度は Makefile よりも断然低い。

高級言語を扱う際は Makefile はおそらくあまり使わない。そもそも GNU Make 自体が UNIX系に強く依存しているので、プラットフォームに関わらず普遍的に使用できることを目指す Web の世界とは方向性が違う。
その代わりに、それぞれの言語に応じたパッケージ管理システムがあり、その中でビルドシステムに相当するものも用意されている。
例えば、JavaScript、特にサーバーサイドでも動く Node.js に関して言えば、npm というパッケージ管理システムがある。この npm において、ビルドシステムに相当するのが package.json である。

{
  "name": "prompts",
  "version": "2.0.4",
  "description": "Lightweight, beautiful and user-friendly prompts",
  "license": "MIT",
  "repository": "terkelg/prompts",
  "main": "index.js",
  "author": {
    "name": "Terkel Gjervig",
    "email": "terkel@terkel.com",
    "url": "https://terkel.com"
  },
  "files": [
    "lib",
    "dist",
    "index.js"
  ],
  "scripts": {
    "start": "node lib/index.js",
    "build": "babel lib -d dist",
    "prepublishOnly": "npm run build",
    "test": "tape test/*.js | tap-spec"
  },
(略)
  "dependencies": {
    "kleur": "^3.0.2",
    "sisteransi": "^1.0.0"
  },
(略)

これはとあるOSSの中の package.json である。ビルドと関係ない項目も色々あるが、dependencies の中に書かれている外部ファイルを読み込み、scripts に書かれているコマンドでプログラムを実行したりファイルを書き出したりする、という意味では Makefile に近い役割をしていると言える(インタプリタである node よりも、ECMAScript を素の JavaScript に変換する babel が元の gcc の意味に近い。細かい話だけど...)
この JSON というファイルは、記述自由度がとても低くて、もちろん中で変数なんか定義できないし、何ならコメントすら書けない。JSON で値として使えるのは null、真偽値、数値、文字列 と、それらから成る配列、オブジェクトだけだと決まっている。Makefile と比べるととても制約が強い。
JavaScript 以外でも、このような設定ファイルは、YAML だとか、TOML だとか、制約が強いマークアップ言語が使われるのが普通である。CIを回すことをビルドの一種と考えれば、.travis.yml とかもそうである。


さて、このように書くと、自由に書ける Makefile がすごいという話になるが、必ずしもそういうわけでもないと思う。
あまりに自由に書けるビルドファイルは、こだわり過ぎると俺流のファイルを作ることになってしまい、他の人が読んでも理解しづらいものになってしまうだろう。正直、ググると出てくる Makefile の例も、行数が多いものは何をやっているのだか一目では分からない。
Makefile 以外の例でこの現象に近いものを一つあげると、webpack.config.js というのがある。これは Webpack というフロントエンドでは必須に近いツールの設定ファイルだが、JSONではなく普通の JavaScript で書かれるため、見た目がグチャグチャになりがちで、何をやっているのか解読するのが慣れていないと難しい。
一方で、記述自由度の低いビルドシステムは、その分単純に書くことしかできないので、他の人が読みやすい。すなわち保守性が高い。世の中のソフトウェア開発は一人でやるものではないし、世界中で協力して作っていくソフトウェアも星の数ほどあるので、保守性が高いことはとても大切なことである。
このようにビルドシステムの記述自由度と保守性の間にはトレードオフの関係があるのではないかと考えている。


最後に、このトレードオフのバランスを上手くとっていると自分が思う例を一つ挙げて終える。それは Dockerfile である。
Docker というのは比較的新しい(もう新しいとは言えない位に時代は経過したかもしれない・・・)仮想化技術である。コンテナ型と呼ばれていて、非常にざっくり言うと、今までは元のOSの上に新しい仮想OSを乗っけていたのを、元のOSの一部分を切り出してそれを新しいOSにしてみたよ、だから効率が良くなったよ、という感じの技術である。
Dockerfile は Docker が提供する仮想OSの元となる"イメージ"をビルドするためのビルドシステムだが、面白いことに、ただOSを用意するだけではなくて、そのOSの環境変数を変えたり、apt-get で外部のソフトウェアを入れたりする部分も Dockerfile に書くことができる。だから、例えば Nginx + Laravel + Vue の環境が整った仮想OSを用意できる Dockerfile、みたいなものが存在する(このようにインフラを一本のコードでまとめていくことで保守管理しやすくしていこう、というような思想が Infrastructure as Code と呼ばれる)。
このように書くと Dockerfile は Makefile のように記述自由度の高い、ゆえに読みづらいファイルになっていると思われるかもしれない。しかし、Dockerfile には制約がある。必ず [FROM, RUN, CMD など命令の種類を判別するラベル] + [命令] というフォーマットで書かねばならず、このラベルの種類は限られている。ゆえに読みやすさ・保守性の高さもある程度確保できているのではないかと思う。実際、Dockerfile は Docker Hub という場所でOSSとして共有されていく仕組みが整備されている。Web 開発に限らず、データサイエンスの分野でも Docker はかなり普及している。
このように考えていくと、あるシステムがソフトウェア開発において覇権を握る上で、記述自由度と保守性の双方をうまく担保することがキーポイントになっているのではないだろうか。

2019年3月

雑記

Web 開発の経験をもう少し増やしたいなという気持ちと、3Sセメスターはそもそも東銀座でまとまって働く時間があまり確保できそうになく、リモートで働きたいという気持ちから、新たにとある受託開発企業でお世話になり始めました。
東大生のアルバイトが多いです。
早速フロントをReactで書いたり、データベースを操作するAPIPHPで書いたりしています。このSQL操作にPropelとかいうのを使っているのですが(あとそもそものWebフレームワークとしてはSlimというのを使っているっぽい)、ドキュメントが本当に全然無くてつらい。
あとはフロントに関して言うと Material-UI というのでデザインを統一していて、これを使うとイケイケの画面を脳死で作れるので超便利です。

例えばデータ一覧を表示するならこの Table とか↓

もう Bootstrap とか不要な時代なのではないでしょうか。みなさんもWebサイトを作るときに参考にしてみてください。


プライベートでは最近はシャニマスばっかりやってます。
『マスカレード・ホテル』観た。とても良かった。一つの舞台の中でストーリーが完結するタイプの作品が結構好きです。
幼女戦記』観た。一対一の個人戦がとりわけ見どころだった。個人的なツボはセレブリャコーフの従順な部下っぷりですね。


ところで3月は久しぶりに小説を書きました。


10連休はフォロワーの方に勧められた黒部峡谷に行ってみようと思っています。

読書

孤独な散歩者の夢想 (岩波文庫)

孤独な散歩者の夢想 (岩波文庫)

かなり読みやすい。 自分自身と向き合うには「夢想」という形式を取るのがよいとルソーは考えているようで、現代のブログに通ずるものがある。

ウェルベックは、単一の人物にスポットを当てて、その孤独な生涯を描くのが上手い作家だと思っていた。なので、この作品の卓越した重層性には心底驚かされた。今まで読んだウェルベックの中で一番好き。

とても参考になっただけでなく、読み物としても面白かった。

有限性の後で: 偶然性の必然性についての試論

有限性の後で: 偶然性の必然性についての試論

例えば50億年前の地球にどのような生物がいたのかというのはどうして分かるのか。
科学者であれば、それは化石の中の炭素の放射性崩壊の比率で測定できると考えるだろう。すなわち、科学的な理論が新しく書き換えられる可能性はあるものの、いずれにせよ50億年前の地球で起こったことの事実性を認めるのだ。
一方で、哲学者であれば、それは「今現在の我々」にとっての祖先の認識でしかない、という相関主義の立場をとる。先行者の存在は先行者より後に存在する我々の後方投射の認識でしかないというわけだ。
ここに大きな乖離がある。つまり、科学が「コペルニクス的転回」と呼ばれる出来事によって、人類が世界の中心ではない、と脱中心化していくにつれ、哲学は逆に、世界は「我々にとっての」見方でしかない、という、いわば逆方向の中心化の立場を支持するようになったのだ。
この本は、そのように距離が離れていった科学と哲学を、再び引き合せようとするような、野心的な取り組みだ。著者の立場が過去の思想家とどのように異なるのかを丹念に説明している。
著者のメイヤスーなどがメンバーの「思弁的実在論」グループは今注目されているようなので、今後の書籍が楽しみだ。

久し振りに綿矢りさ読むかという気になって本屋で買った。


スペクタクルの社会 (ちくま学芸文庫)

スペクタクルの社会 (ちくま学芸文庫)

ウェルベックの小説の中で言及されていたので読んだ。全般的によく分からない本なのだが、訳者解説を読むと時代背景が分かってなるほどとなる。メディアが急速に発達していった時代において、我々があらゆる出来事の観客(傍観者)に堕することを戒めている感じがする。

濃霧の中の方向感覚

濃霧の中の方向感覚

エッセイ集なので色々テーマがあるのだけど、教育や社会に関しては『都市と野生の思考』で読んだのと似たような話が多い。政治テーマはあまり面白くない。鷲田清一自身の学生時代の話は結構面白いのが多い。

著者のことよく調べたら割とツイッターで見る kizawaman02 氏だったという... インターネットの暗部について書かれた本、というよりはオルタナ右翼の紹介の本だった。
ともかく、アメリカにとってのインターネットが反体制のカウンターカルチャーとしての側面を持っているのに対して、日本のインターネットがノンポリだというのは、確かにそうかもなあと思いました。

アニメ

バイト先で耳に入った話。
Webデザインの授業の講師として生徒(高校生)と向き合っている方が、自分がこうやってデザインを教えることによって、もしかしたら生徒が、大学なんか通わなくてもWebデザイナーとしてやっていけるじゃん!と性急に結論づけてしまうのではないか、もしそうだとしたら自分はそれに非常に重い責任を感じてしまう、という趣旨の内容を同僚の方とされていた。

これはとても考えさせられることだと思った。確かにそういう行動に対して、我々が「頭が悪い」「偏差値が低い」というラベルを貼って認識することはとても簡単である。
しかし、人間誰しも、自己表現をしたい、そしてそれを生業にしたいという欲求を内に秘めているのではないだろうか。大体の人はそれを趣味として片付けると思うのだけど、そうではない人もいるのだ。今風の表現をすると、ワークライフバランスではなくワークアズライフを取る、とも言い換えられる。例えば私の父親はずっとフリーランスでデザイナーをやっているけど、そんな感じで親戚にその生き方に近い人がいれば、このことはより身近に実感できるだろう。

自己表現を仕事にすることが、なんとなく大学でサークルに入って仲間うちで適当にワイワイ4年間過ごすことよりも大切だという判断を、高校生のうちにしている人に対して、いや一応大学くらい出た方がいいんじゃない?とアドバイスするのは、一体何を根拠にしてできるのだろうか。
もちろん、大学に通うことにも何らかの意義を感じている人は、大学にも通いつつ自己表現を極めるという選択肢をすんなり受け入れるかもしれない(大学に通っている/いた声優の回顧を聞くと、それが役作りにもプラスの影響を与えるのではないかと考えていたという話をよく耳にする)。
一方で、大学に通うというような「回りくどいこと」をせずに、好きなことを一刻も早く仕事にしたい、という気持ちを持っている場合も多いだろう。そういう生徒に対して、その講師の方が危惧されていたのは、好きだと思っていたデザインで仮に挫折や嫌なことがあった時に、その生徒はくすぶってしまうのではないか、過去を後悔してしまうのではないか、ということであった。

どんな分野であれ、一つの得意なこと・好きなことで人生をやっていくというのはカッコいいことのように見えるが、相応のツケが回る可能性もある。それを高校生のうちに100%理解させるのは不可能なことだろう。そして最終的な判断をするべきなのは本人である。