ループする体験
この話、正直私の個人的な興味と、その不思議なつながりに関して書いたものです。したがって、いや、それはつながってないんじゃない・・・？と思われるかもしれません。おそらくはそうかもしれません。
ただ自分は、なんだか不思議な気持ちになったなぁ。というとても私的なものです。それを出来るだけなぜ「自分がそう思ったのか。」を書いていこうと思います。
UnityのSceneのGit管理のベストプラクティス
数年前、STYLYの開発の話を聞いていると、こういう話が出てきました。
UnityのプロジェクトはGitで管理しているけど、Sceneは1人1人触るようにして、異なるブランチでもSceneは同時に作業しないようにしよう。
私には最初、意味が分かりませんでした(そもそも私はサーバーサイドエンジニア)。令和の時代にそんなことある？？Gitで管理できないことってあるか？？と。
でも、触っているうちにある程度意味は解りました。Unityのシーン自体はテキストで保存されており、そのデータは基本的にはUnityEditorでしか触りません。しかし、テキストで保存されている。という性質上、Gitはテキスト的にマージを試みようとします。しかし、そのGitのマージ機能では不十分で、その機能でマージをしてしまうと、UnityEditorで開いた時にSceneが破壊される。といったことが発生する可能性があります。
もう少し別の視点で話すと、例えば、HTMLを書いていたとき、それを複数ブランチで管理し、マージするとデザインが崩れる。といったことがあります。この時、どのように直すか。というと、そもそもエンジニア側がHTMLの構造に詳しいので、手動で壊れた部分をテキストエディタで直したり、マージすることが可能です。しかし、UnityのSceneの内部構造は非公表ですし、そもそもシーンはUnityEditorで制作し、直接テキストとして触らないため、エンジニアが手動で修正することが難しい。という事情もあります。
でも、本当にそんなことある？？
と思いました。それ、世の中になんかベストプラクティスあるんじゃないか？？と思いました。
思い出すSmalltalk
どうも自分の中でUnityEditorにはデジャヴがあって、それはSmalltakでした。たぶんみなさんが知っているSmalltalkの情報というのは、「アラン・ケイというコンピューター史に残る偉大な人が作った」とか「オブジェクト指向の始祖のプログラミング言語」ぐらいの情報量だと思います。そんなものがどこがUnityと似ているんだ？と思われるかもしれません。そうではなく、
SmalltalkはGUIの環境が主流でCUIの方がマイナー
なのです。
私は割と古典的な話や、使い勝手も含めてSmalltakを触るなら、Squeak.jsをお勧めしています。
https://squeak.js.org/
実際に操作するのであれば、オージス総研のオブジェクトの広場、オブジェクト指向再入門をお勧めしています。
なぜそれにデジャブを感じていたのか。と言うと
- 基本的な操作がGUI
- スクリプトでEditor自身を拡張する
という2点です。
Smalltalkが他の言語と一線を画すプログラミング言語環境だ。と思う1つの理由が、基本的にGUIコミの環境であることです。一般的なプログラミング言語はエディターならびに統合開発環境があり、それをコンパイルするビルドチェーンがある。といったことが普通ですが、SmalltalkはGUI環境含めてSmalltalkです。むしろGUIしかないです。だから、Smalltalkの内部にテキストエディタがあり、実行環境があり、それをGUIの位置も丸ごと含めてバックアップを取ります。たぶんそんなプログラミング言語あんまりないと思います。
Unityは、プログラミング環境こそテキストエディタに任せられますが、それ以外は、ほぼGUIで、プロジェクトという単位で全体をバックアップしたりします。このGUIが強制的についてきて、GUI必須の開発環境というのは、プログラムの開発環境全体の中ではかなり珍しい部類ではないかと思っています。
また、SmalltalkはすべてがGUIですべてがself-hostedなので、自分自身の機能を拡張するスクリプトも書けます。だから、シェルに対するシェルスクリプトのようなものがSmalltalk内で書けます。そして、そのスクリプトを書くエディター自体もまたSmalltalkで実装されていますし、Smalltalk内にWindowを出したりできます。ある意味でOSみたいな全部入りの環境が入ってる。みたいなイメージです。また、それはUnityEditorも同じで、Editorスクリプトという形で、UnityEditor自身の機能を拡張するスクリプトも書けます。
この辺のGUIの操作である。といったことだったり、自己拡張が出来るキモさ。あたりにSmalltalkとUnityの同型を見出していました。そんな中で思ったことがありました。
基本的にGUIで操作するSmalltalkなのであれば、GUIの部品やデータの分散管理や、多人数作業のマージなどは既に解かれた問題ではないか？であれば、その同じ仕組みをUnityに持ってくれば、シーンのマージなどの問題など無くなるのではないか？
ということを思い立ち、Smalltalkについて調べる日々が続きました。
その答えの1つがこれです。
流行っている・流行っていないプログラミング言語に関する1つの考察
その中にある文を引用すると、
Smalltalk界隈のソースコード管理は割と特殊で、その特殊性がよくまとまっているのが、この「Source Code Management with Pharo Smalltalk - Pharo Smalltalkソースコード管理方法」です。上記の記事によると、その特殊性からSmalltalkのソースコードがgithubで割と楽に管理できるようになったのは、2012年のFileTreeを待たないといけなかったようです。
割とラフに書いてしまいますが、Smalltalkは現代では流行っていません。流行っていない。ということは、個人で小規模なものを書くことぐらいしかありません。そうすると、多人数で分散管理という問題に直面することも少なくなります。したがって、SmalltakでどうやってうまくGUIなどのデータをマージしているの？という答えは、そもそも個人で作ることしかないから、多人数での分散管理やマージという部分はあまり問題にならない。という根も葉もない答えになってしまいました。
というわけで、先駆者としてSmalltalkへデータの管理方法を学ぼうと思ったが、そこには何も落ちてなかった。というとても悲しい結果に陥ってしまいました。
テスト駆動との合流
そのようなわけで管理方法に関する調査は頓挫したわけですが、そのアイデアはどこかに落ちていないか？と模索を始めました。実のところで言うと、Smalltalk自体には過去から興味がありました。それはなぜか。というと私はテスト駆動が好きだからです。
10年ほど前に「テスト駆動は死んだ」という、Ruby on Railsを作ったDHHのコラムが話題になったり、現代においても、テスト駆動自体あまり一般的なプラクティスではないと認識しています。しかし、私自身、テスト駆動は良いものである。と思っており、それは何かテスト駆動が効果を発揮しない要因があるのではないか？という問いを立てていました。
そこでテスト駆動を提唱しているKentBeckに関する情報を集めてみると1つ面白い事実が見つかりました。それがこの記事です
SUnitのWikipediaを見に行くと
SUnitはケント・ベックの著書「Kent Beck's Guide to Better Smalltalk」の第30章「Simple Smalltalk Testing」および「Simple Smalltalk Testing：With Patterns[注釈 2]」（1989）にて発表された。
とあります。そう xUnit自体もKentBeckが1989年に構築したソフトウェア だったのです。
テスト駆動はその名の通りテストを書いて進めるプログラミング技法であるため、テストフレームワークが必須です。そのテストフレームワークであるxUnitを提唱した人自身も、テスト駆動を提唱したKentBeckだったのです。
そして、 KentBeckが最初に作ったxUnitはSmalltalk用だった。 ということです。というわけで、テスト駆動が現代においてうまくいかない。効力を発揮しない。といわれる理由に、Smalltalkというプログラミング言語にはあったが現代で使われているプログラミング言語で失ってしまった特性があるのではないか。 という仮説があります。そんなわけで、Smalltalk自身にも興味があったのですが、ここでもう1つ自分の琴線に触れる話がありました。
リファクタリングで有名なマーチン・ファウラーのXUnitにこういった記述があります。
JUnitは、1997年にアトランタで開かれたOOPSLAに向かうチューリッヒ発の飛行機のなかで産声を上げた。 KentはErich Gammaと一緒だったが、2人のギークが長時間のフライトでやることといったら、それはプログラムしかないでしょう。 JUnitの最初のバージョンは、そこで、ペアプログラミングで、テストファーストで作られた（メタ循環的なのがギークっぽくてよいね）。
そう。実は、JUnitはKentとEric Gamma(デザインパターンで有名なGang of Fourの1人)が飛行機の中でペアプロで作ったものがベースとなっています。
この記述を見たときに、OOPSLA？という謎のワードに当たりました。おそらく何かの国際会議なのだろう。マーチンファウラーも行っているぐらいなのだから、オブジェクト指向などの議論があるのではないか。ということは、OOPSLAを調べれば、自分が知らないSmalltalkや最新のオブジェクト指向事情が知れるのではないか？そこに何かしらテスト駆動とSmalltalkを繋ぐ何かの情報があるのではないか？ と思うようになりました。
OOPSLAと日本人、そしてメタバース
Wikipediaによると
OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) とは、ACMが毎年開催している国際会議である。オブジェクト指向プログラミングのシステム、言語、アプリケーションを主題としている。
第1回のOOPSLAは1986年、ポートランドで開催された。主催したのはACMのSIGPLAN (Special Interest Group for Programming Languages) であった。OOPSLAの開催地とテーマは毎年変わる。通常、論文発表を中心として、比較的実用的な実験報告、パネル、ワークショップ、チュートリアルなどがある。
OOPSLAは今日のオブジェクト指向プログラミングの隆盛に寄与してきた。また、デザインパターン、リファクタリング、アスペクト指向プログラミング、モデル駆動工学、アジャイルソフトウェア開発、ドメイン固有言語といった関連分野の発展にも寄与した。
やはり、オブジェクト指向に関する国際会議であり、ここで最新のオブジェクト指向情報に触れられるだろう。と思って見ていると気になる記述があった。OOPLSAの1990年のプログラム幹事が米澤明憲さんという日本人の方だった。どんな方だろうか。と思って調べ始めたところ以下のようなサイトを見つけた。そこにある並列オブジェクトを用いた大規模システムというスライドに衝撃を受けてしまった。その中身を引用すると
なぜか自分の興味のママにネットの海を漂っていると、なぜかSecondLife(メタバース)にたどり着いてしまった。という妙な話でした。
もともとUnityのシーンをベストプラクティスを調べていた理由は、最近話題だったメタバースなどの開発で問題になっているから。というモチベーションでした。そこから、Smalltalkのソースコード管理方法を調べ始め、Smalltalkとテスト駆動の関係性を調べているうちに、OOPLSAに出会って調べてみると、なぜかメタバース(Secondlife)に帰ってくるという。謎のめぐりあわせに出会いました。
これは別記事にする予定ではありますが、メタバースを真面目に考えると「計算とは何か」「計算機アーキテクチャとは何か」という話に帰着するな。と個人的には思っていました。そんなことをぼんやりと思っていた矢先、オブジェクト指向という方向から、メタバースの話が出てくるとは正直言って面食らいました。
そんな中で日常で感じたUnityでの課題をどんどんどん掘っていくと、実はメタバース(SecondLife)に繋がって、なんだ・・・この気持ち・・・となった話でした。結局は、UnityシーンのGitで管理するベストプラクティス。というものは分からずじまいで、だんだん自分でも話が繋がってるか繋がってないかよく分からない状態ではあるんですが、とりあえず最終的につながると思っていなかったSecondLifeの話にぶち当たったときはマジで衝撃だった。という話でした。