メタバース本3連発

何が3連発やねんという感じだけど単に連続で読んだ。それぞれ印象に残った部分をピックアップして紹介する。

タイトルはこういう基準で選んだ

  • 実際に手を動かしている人の書いた本
  • 若い著者のやつ
  • Web3とか絡めてこないもの

メタバースとは何か~ネット上の「もう一つの世界」~ (光文社新書)

大学の教員の人が書いた新書。いち早く発刊されていて売れていたので手に取った。

この本の特徴はアニメやゲーム作品を題材にムーブメントを俯瞰していくところだと思う。インターネットやSNS論の切り口も多い。

とくに目を引いたのは著者がセカンドライフを現役でプレイしている点。生徒を集めて授業を開催したらしい。

世界2.0 メタバースの歩き方と創り方 (幻冬舎単行本)

代表を退いたメッタプスの社長が隠居して盆栽を嗜むように3DCGで遊んでる—— なんか最初はそんなイメージだったんだけど、次の事業の種としてこの領域を研究しているらしい。

ヤカラ度が高い内容なのかと思ったがそんなことはなくてバズワードとしては距離を置いて要素技術に関心あるようだ。

語彙は硬めで真面目な語り口だったが、となえている各論はカジュアルな話題が多かった。

メタバース=VRバイス、という関連付けが世間でも多い中「インターネット空間の3D化」さえしていれば何のデバイスでもプラットフォームでもかまわない、=それが次世代のインターネット体験。というのがこの本の中心となる価値観だと思う。なので3DCGで遊んでいるらしい。

印象に残ったのは「メタバースといってもゲームの中の特定のジャンルのことでしょ。コンテンツとしては限定的じゃん」という世間の声に対して「今ゲームだと思われているサービスがインターネットの中心になっていてもいいじゃん」という意見を持っているところだと思う。

これには価値観の変化が必要だと思った。僕らの世代はウェブブラウザでテキストを読む→インターネット体験だ、という思い込みがあるが、スマホしか持たない人はアプリをゲートウェイにインターネット以下の世界が広がっていてブラウザアプリの提供する機能は図書館的だし、それが入口がすべて3D化された世代が入ってきたら自分と同じインターネット感は保てないなと思考実験していた。

後半にかけての世界の仕組みをソフトウェアで実現するための理論は人を選びそうな内容だと思うけど、「完成して本になっていてエラい」と思った(投げやり)。

メタバース さよならアトムの時代 (集英社ノンフィクション)

clusterの社長が書いた今年出た本。この3冊の中では一番VR技術寄りの内容だと思う。実際に展開されている国内外のVR系のサービスの話題も多く出てくる。

この本の要点は「現在デジタルでないものをデジタル化していく過程の先にあるのがメタバースの世界」だという点だと思う。

すべてがデジタル化された先には、バーチャルな空間でのモノや体験がリアルな空間のそれより上位になる。現地に旅行に行けないからVRで行く、ではなくて長期的に見たらVRで旅行することの方が価値がある世界になる。という感じだ。

その世界では物体の移動よりデータの転送が社会の中心になるからソフトウェアの制約で新しい経済も作れる。なかなか現在の価値観ではすぐに共感できないところであるけど、何をいいたいかは個人的には理解した。

この本にはWeb3関連の話がちょっと出てくるけどやはり苦々しく思っていそうだ。まぁたしかに僕も今のNFT投機系の仮想空間ゲームを楽しいからという理由でプレイしている人はあまり想像できてない。

フレームワーク乗り換える必要なし系の意見がもう少し欲しい

ushironoko.me

Vue.jsビギナーズガイド などを著書に持つushironokoさんの記事。

とくに共感したのは以下の文章

Vue は長らく「持たざる者のための宣言的UI」でした。React は Javacript さえ書ければ使えると評されるように、裏を返せば JavaScript を書けないデザイナーや非フロントエンドエンジニアにとって扱いが難しく、jQueryが支配的な環境において Vue の存在はとてもありがたかったのです。 https://ushironoko.me/articles/2022/vue-ore-taido

僕がVueを知ったのは「Angularほど難しくない軽量データバインディング」としてのVueだったのでニーズが重なっていた。逆にこのニーズは今後Vueではなく別のライブラリが補うことになるのかもしれない。

TypeScript対応もComposition APIもVueがより大規模でプロフェッショナルなプロジェクトで機能するように目指す改善だというのはEvanの発言を見て認識していた。

Vue3へのマイグレーションめっちゃ大変話(Vue 3 was a mistake that we should not repeat) もこれも裏を返せばVueやAngularがリリースプロセスや後方互換性を重視して管理していることを表わしていて、ローリングリリースをメンテナンス人口でカバーするやり方から見ると優れた面もあると思う(LTSとか)。

Vueが特定の時期にReactより導入が進んでいたのは非JavaScript専門家にとって敷居が低かったのもあるし、ただその時点での業界の多数派だったという可能性もあり、卵と鶏の関係になっていると思う。

僕は フレームワークのシェアを重視しがち で触れたように多数派によって技術選定が左右されてしまう現状は、より長い目でみると将来変化するかもしれない一時的なトレンドという仮説も持っていて、バランスを取るためにこれをしきりに推していきたい。

プロジェクト内でフレームワーク乗り換えなどの大きな変化はロードマップになるしより成果として表現しやすいから注目されやすいが、変えないことを選択し続けることも同じぐらい影響を与えるのではないか。

とはいえトレンドアウトしてメンテナンスされないものは、変えるか自分が参加するしかないので分かりやすいけど、多数派でない活発にメンテナンスされ続けるフレームワークをどう扱うのかは難しいところだとは思う。

色々な判断軸があると思うけど、僕の場合はアップデートして使い続けることに価値を置いてる。フレームワークを変えてDXを向上してプロダクトへポジティブな影響を及ぼす、というのが大規模な技術組織に置いて正解なこともあるし、プロジェクトやプロダクトの非技術的なレイヤーに問題を見出す場合は道具だけを変えても解決しない。

フレームワーク乗り換える必要なし」といっても新しいものを受け入れないということではなくて、必要に応じて新技術を検証したりサイドプロジェクトで実践したりする余地を確保するべきだと思う。

だから今「採用を考えて多数派フレームワークに移行しましょう」と言われてウッとなってしまう時に「今あるものを深堀りする方が私たちにとって得策なのかも?」と対抗できるぐらいにはフレームワーク乗り換える必要なし系の意見がもう少し欲しいところである。

Web3のここがすごい

1. 名前

「Web3」というナンバリングで定着しているのがすごい。

Web3になってることで本来別の文脈であるWeb 2.0と同じ正史の土俵にある概念のように受け取られているし、Web1→Web2→Web3のようなメタファーでストーリーが構築できている。

Web1 Web2 Web3
Read Write Own/Join
HP SNS DApps/DeFi
GAFAM DAO

という対比をよく見かけるけど、僕の視点だと以下になる

Web 1 Web 2.0 Web 3.0 Web3
2004年 2006年 2014年
ない 当時流行っていたサービスの総称 セマンティック・ウェブあげるよ ブロックチェーンで何かサービス作れない? という話題

3の命名はParityのギャビン・ウッドとされているが、今の文脈とどの程度地続きなのかは定かでない。ただWeb 3.0にしなかったところにWeb 2.0シリーズではないよというこだわりを感じる。(追記:単にティム・バーナーズ=リーの3.0の命名と被るからというのが理由かもしれない)

最初にWeb3の名前を知ったのはweb3jsというnpmモジュールだった。全然予備知識がなかったので何か革新的な取り組みなのかと思って、取り敢えずインストールして使ってみて「お前イーサリアムだろ!」と思った記憶がある。

WebXシリーズはあっという間に埋まってた

www.npmjs.com

Ethereumが革新的な取り組みなのが言うまでもない。その時にGETHやParityも知って、ついでにRustの活用事例にも出会えた。

ところでTim O’ReillyはWeb3について「oreilly.comのサブスクで基礎となる技術を学ぶことができます」と述べている(本質だ……)

www.oreilly.com

2. タイミング

コロナ禍以降に急激に認知度を広げたのがすごい。

いたるところでWeb3というキーワードを見かける。ブロックチェーンの話題自体はそれ以前より事欠かなかったというのに。

ブロックチェーンってインターネットじゃね?」っていう言い方は、僕は『ブロックチェーン・レボリューション』という本で最初に見た記憶がある。たしかにそうですね、ぐらいの感想を持った。

自分がビットコインの存在を知ったのはマウントゴックス事件のあった2014年ぐらいだったと思う。

当時スマホ決済関連のソフトウェア開発をしていて「次のロードマップに入れる決済手段」を議論していた時に当時レジュプレスという名前だったコインチェックが提供するビットコイン支払いを採用するのはどうかという話があった。

当時のビットコインは僕らのまわりではかなりオモチャ枠の技術で、ビジネスの現場に導入するという話に当初ギャグっぽさを感じたのだけど、POが「これは実現するなら最もインパクトがあるので真面目に検討する価値がある」と言っていてスタートアップ的な発想だなと共感したので強く印象に残ってる。

Web3という言葉をブロックチェーン界隈以外でよく見かけるようになったのは、僕の場合2020年以降の「Off Topic // オフトピック」というポッドキャストでだった。

podcasts.apple.com

その背景としてアンドリーセン・ホロウィッツのクリス・ディクソンのCoinbaseへの投資の成功が、2020年以降のWeb3の隆盛に関わっていそうだなと認識した。

forbesjapan.com

あとSolanaについては「Today I Learned」というポッドキャストで知った。

Today I Learned

Today I Learned

  • Imai and Yusuke
  • Technology
  • USD 0
podcasts.apple.com

3. 経済性

ユーザーから見たすべての行動が経済活動になっている点がすごい。

Web3じゃなくても広告見たり商品買ったりしたら経済活動やろ、と思うかもしれないけどユーザーが「儲かるかも!?」という期待を元に取る行動のことを指しているのでより範囲が広い。

例えば現金に換えることができるポイントを他のユーザーを紹介して獲得するという直接的なインセンティブはWeb3に限らず実現されているけど、暗号資産○○やWeb3サービス△△に対するポジティブな意見を発信し続けることで、自分が持っているトークンの価値が上昇して「儲かるかも!?」という期待を元に、ユーザーたちがWeb3サービスの宣伝を自発的に繰替えしていたりする(ネットワーク外部性的な)。

開発者として「App Storeでアプリを販売して儲かるかも!?」と考えることはよくあったんだけど、ユーザーとして儲かるためにアプリを選ぶ使うということを第一に考えたことがなかったのでその考え方自体が自分には新鮮みがある。

ユーザーとしては本来消費者なので、金か情報を出して娯楽や便利を受け取る、という世界観だった。

似た感覚としてはWeb 2.0の時代にはじめてAmazonアフィリエイトを使った時の「ブログ書くだけの消費者なのに報酬が頂けるんですか〜〜?」というのに近い(今日では一般的な広告ビジネスなので違和感はないけど)。

ただこれには負の側面もあり、ほぼ負の側面かもしれないけど「技術に関心ないけど技術的な用語を使って価値を煽る」とか「そのみんな紹介しているWeb3サービスは実際誰も利用していないのである」、はては「他トークンと利益を奪い合うために攻撃するインセンティブもある」等の問題がよく起きていると思う。

他方、ここは魅力を感じていない

巨大プラットフォームからの開放

Web3の解説でよく「現在のWebはGAFAMにあなたの個人情報を握られ搾取されています。非中央集権化することでこの問題を解消しましょう」というストーリーが出てくるが、論理構造が逆だと思っている。

  1. パブリックブロックチェーンでデータの管理を分散できます
  2. ブロックチェーンでないものにこれはできません
  3. GAFAMの巨大プラットフォームはブロックチェーンではありません

「できること」から見たそれができない場所を探しているアプローチで、ニーズの定かではない非中央集権化をイシューにするように誘導している。

巨大プラットフォームが槍玉に上るのはブロックチェーンではないもので一番シェアの高いものであるし、反トラスト法関連で時流に乗っていて迎合しやすいからだと思われる。

Web3ユーザーとしては「InfuraやAlchemyなどのエンポイントに接続不能になったら自分で別のノードに接続するように再設定したい〜〜」と思ったことはまだない。

パスワード不要

Webのカスタマーサポートに携わったことのある人なら問い合わせの多数が「パスワード分からん」みたいな状況に立ち合ったことがあると思う。

認証がなんとかならない時になんとかしてくれそうな第三者の存在はありがたい。

僕はMetaMaskのニーモニックをこの先もがんばって保持して運用できていく自信がまだない。

日本復活

国を上げて新興産業としてのWeb3に関わりブチ上げていくぞ、みたいなムーブがよくあると思う。

投資すべく実際に予算が通されているのかは知らないけど既得権益も薄いし、取り組むのに莫大な資金がかかるわけでもないだろうから歓迎すべきなんだろうけど、日本復活のためにそれを優先すべきかというとそうは思わない。

日本復活というか現状維持を実現するための経済施策の1つという位置付けなのかもしれない。そうであるのなら現状維持を目指すのではなく、すでにある資源を使って国民が幸福に過す、他人への要求水準を下げ、他文化の人を受け入れ、自殺者やうつを減らしという部分に重点を置いて欲しいと願っているのだけど、まぁそれも経済ブチ上げたらなんとかなるぞと頭のいい人たちは考えているのかもしれない。

ただブロックチェーンのプラットフォーム側やシビテックを地道にやっていっている人たちは国と関係なくグローバルに報われて欲しい。僕のTwitterリストにはブロックチェーンの技術の話題を中心にする人(ネットワーキングだけをする人を区別するため)を登録するリストがあってそこで彼等の活動を追い掛けている。

情報開示

著者にはWeb 2.0が台頭していた時期に「ウェブ進化論梅田望夫が恐竜のロングテールを振り回して暴れる」といった内容のショートストーリーを公開していた過去があります。

唐突に使っている有料アプリケーションを紹介

僕は有料のアプリケーションの購入をかなり厳選したいタイプで、サブスクリプション型のは断固拒否して過していたんですけど、ここ最近は「契約→カレンダーに解約日を設定する」というので管理しようとしている。

MindNode

www.mindnode.com

Macマインドマップを書くアプリケーション。

かなり昔の記事だけど トニー・ブザン 頭がよくなる本 - higepon blog を読んで「マインドマップ・・あるな????」と影響されて買って使い続けている。

いわゆるAppKit製のMacネイティブなルックアンドフィールでJavaクロスプラットフォーム製な他のアプリケーションより使いやすかったのでこれにした。

マインドマップはあまりなかった。

IntelliJ IDEA

samuraism.com

プログラミングをする時の環境。

サムライズムという日本の代理店で購入してる。

IntelliJ IDEAとの付き合いは長く2011年からWebStorm→PHPStorm→Rubymineと経て、言語ごとにIDEがあるのなら、みんな買うしかないじゃない と感じたのでAll Products Packライセンスに移行した。

ただVisual Studio Codeを使えないと時代に取り残されてしまうのではという危機感から、週1ぐらいは代りにVSCodeを起動してる。

関係ないけど「IntelliJ IDEA」「JetBrains」やそれぞれの言語別製品名と呼称がバラけていてウェブ検索する時にいつも迷う。

TablePlus

tableplus.com

MacのDBクライアント。

SQL書く時に使ってる。IDEAにDataGripというツールがあるんだけど、こっちのが好き。

Alfred Powerpack

www.alfredapp.com

Macのランチャー。

スニペットクリップボード履歴を使うために購入した。あまり活用できてない。

HUAWEI CLOUD

www.huaweicloud.com

HUAWEIAWS

「これからはクラウドIDEで複数人でコーディングする時代が来る」とずっと思っていてシンクライアント的な開発環境を試しているんだけど、どのプラットフォームもSSHできるLinuxサーバーを求めてくるのでできるだけ物理的距離の近い場所にあるサーバーが欲しくて契約した。

VSCodeやJetBrainsのソリューションを試しているんだけど、時代はまだ早かった。

Strainer(ストレイナー)

strainer.jp

ビジネス系のメディア。

現代病「集中できない」を知力に変える 読む力」という本を読んでいた時に購読するメディアの意識して分類せよという話があって、何かひとつぐらいビジネスメディアを読む習慣をつけるかと思って契約したやつ。Newspicksや日経電子版などと比較して決めた。

ブラウザとJavaScriptで自動読み上げするツールを作った。その結果中身を読まなかった。

死後強まるサイト

個人開発のコストはDB次第 この記事を見てびっくりした。まずビックリしたのは「DBにお金を払えばいいのでは?」という点。

OSSへの寄付の月予算を$10にした にあるようにソフトウェアに費用をかける意思はあるのになぜプライベートの開発にコストをかけたくないのか。

記事の反応を見て気が付いたのだけど、僕は何故かサーバーレスアーキテクチャの採用を前提としていて、ここにヒントがあった。

最初はサーバー管理に関心がないのかもと思っていたのだけどパソコンとしてLinuxを使うのは結構好きだし、VPSもいくつか契約している。

これは何故なんだろうと考えていたのだけどブログのリセット でも触れたように「死後に放置されたサイトになる」ことを考えているんだろうという結論になった。

ノーメンテナンスでなるべく生き続けて欲しい。思い出してみると独自ドメインを避けるとか宣伝しないなどもその動機の為であった。

現実的なSPOFはクレジットカードの有効期限だと思うのでそれを解決しないと始まらないのたけど。

ブロックチェーンやスマートコントラクトを使った分散アプリケーションへの関心もここにありそうだ。

Tauri on mobile 現状確認会

tauri.app

Tauri とは

Electron代替として作られたRust製のGUIアプリケーション開発ツールキット。

ユーザーは各プラットフォームのWebViewで動くHTML+JavaScriptでUI開発をして、裏側はRustで書いたネイティブバイナリにコンパイルされるプログラムを呼び出す。

実際の実装のイメージが以下で、Electronに使い方は似せられている。

tauri.app

Electronは特製ChromiumとNode.jsをユーザーのアプリケーションに同梱することでポータビリティを担保させているのに対して(find /Applications -name "Electron Framework.framework" コマンドを実行してみると大抵どんな環境にもElectronが10匹ぐらい居る)

TauriはOSが用意しているWebViewにリンクして、スクリプトもネイティブバイナリにするので早くて軽い、というアーキテクチャのようだ。

GUIツールキット界隈ではこのようにプラットフォーム側かエンジン側のどちらに寄せるかという選択自体はよくあり、プラットフォームや動作環境の差異で挙動が変わったり、安定するかわりに成果物が重くなったりと一長一短の歴史ではあった。

ここ何年かの変化としてはWindowsのバージョンシェアやWebView開発環境が一新されてレガシーに引きずられることがなくなったという部分がある。

あとGoやRustのように依存が少ないシングルバイナリをクロスコンパイルできるツールの発展もTauriが出てきた背景としてありそう。

時系列的にはこうだと思う。

製品 時期
Electron 2013年
Tauri 2019年
WebView2 2020年

そしてElectronはApp Storeレギュレーション的にiOS版ビルドを吐くのは難しそうだけど、Tauriならできそうというわけでモバイル対応が進んでいるらしい。

WRYとは

github.com

このディオ・ブランドーみたいな名前のコンポーネントはWebView Rendering librarYの略で、WebViewで動くアプリケーションとバックエンドのブリッジとして機能しているらしい。

内部的にさらにtauri-apps/taoというコンポーネントと組合せてWebViewに任意URLを与えて直接Windowを持つアプリケーションとして実行できるようになっていた。

https://github.com/tauri-apps/wry-mobile というリポジトリも作られているが更新されていなく、モバイル系の開発はどうやらtauri-apps/wryの方からリンクされているHackMDページに情報があるらしい。

hackmd.io

このドキュメントからさらにリンクされているのが cargo-mobile というツールで。gomobileのようなモバイルアプリ向けのビルドをサポートするツールのようだ。

cargo-mobile

なぜかこっちも分裂していて、さらにそれぞれのリポジトリでコミットされている。

すこし眺めてみたところ、オリジナルとTauriメンテナのwusyongさんによるフォークという関係のようだった(wry-mobileのドキュメントからリンクされているのはwusyong/cargo-mobileの方。)。

TauriはもともとRust界隈のやる気勢たちによってコミュニティでメンテナンスされているが、モバイル対応をメインでやっているのはwusyongさんだけだった(モバイル開発まわりには明るくないらしい)。

あくまでも検証中の段階らしく、IPCの動作の確認とシュミレータ向けのビルドやデバッグをしていることが分かる。

tauri-apps/tauri

tooling/bundler/src/bundle/macos/ios.rs

アプリケーションのバンドル化のコードにmacos->iosがあることが分かる。

iOS SDKとのインテグレーションがあるというわけではなく、アセットファイルの生成ぐらいの処理が定義されている。

2021年に最初にコミットされたバージョンからあまり変更がなかった。

tauri/tooling/bundler/src/bundle/settings.rs

ビルドできるバンドルの種類。Androidの定義はなく、apk,appbundle,ipaなどのフォーマットに関するコードも今はない。

/// The type of the package we're bundling.
#[derive(Clone, Copy, Debug, Eq, PartialEq)]
#[non_exhaustive]
pub enum PackageType {
  /// The macOS application bundle (.app).
  MacOsBundle,
  /// The iOS app bundle.
  IosBundle,
  /// The Windows bundle (.msi).
  WindowsMsi,
  /// The Linux Debian package bundle (.deb).
  Deb,
  /// The Linux RPM bundle (.rpm).
  Rpm,
  /// The Linux AppImage bundle (.AppImage).
  AppImage,
  /// The macOS DMG bundle (.dmg).
  Dmg,
  /// The Updater bundle.
  Updater,
}

分かったこと

  • モバイル対応はまだ検証中
  • iOS/Android SDKと連携する部分の開発はされていない。
  • wusyongさんの助けが必要

ここまで書いたけど単にWebViewで動くHTML+JavaScriptアプリ開発をしたいだけならIonicを使うのがいいと思う。

ionicframework.com

Rust好きやデスクトップアプリケーションとの共通化を見据えてTauriの開発に参加したい人にはフィットするかもしれない。

iOSDC JAPAN 2022にプロポーザル提出した #iosdc

iosdc.jp

nextstep.fm でみんなすごい気を遣ってSwiftの話をしていたので、ウッ・・後ろめたい・・! と思ってiOS界隈に為になることをするぞとやる気になってiOSDC JAPAN 2022にプロポーザル提出した。

(このようにただの感想ブログにリンクを張ったら先方にPVが流入してしまうということがよくあるのが最近の困まりどころ)

fortee.jp

「全部Swiftで作るWebアプリケーション」はいわゆる縛りプレイ系の内容で、特定の技術のカンファレンスでまぁまぁ行われている伝統的な手法。僕の記憶に残っているのはyouchanさんがOpal芸をよくやっていた気がする

全部Swiftで作れるかは今をもっても判明していなくて、SwiftWasmではじめるWebアプリ開発 があるからどうにかいけるのでは??? 程度の目論見がある。

僕は普段からkateinoigakukunさんの活動を尊敬しており、SwiftWasmをカンファレンス駆動開発で実際に使ってみたいと思ったこともあります。

fortee.jp

「サーバーサイドSwiftで学ぶバックエンド開発」は上記のトークを需要を伺いよりオーソドックスな路線に下げたもので、フロントエンド側をあきらめバックエンド側に重点を置いた。

最近Cloudflare Workers上のノンフレームワークな環境でコード書いていて、ルーティングとかJWT認証やCookieの暗号化を意識して実装する必要があったため馴染みがあり。実装例もVaporを読み解けば分かりそうだなと感じたので、この内容にした。

過去のiOSDC JAPANを思い起すに僕は抽象的な話ばかり好んでいた傾向があったので、次何かやるならストレートにコードがたくさん出てきそうな内容にしたいなぁと前から思っていた。

いづれにせよ数年iOS開発から遠ざかってしまって愛機もAndroidなので、アウトサイダー感もありつつ。採択された暁にはまたSwiftをがんばってキャッチアップしないといけなさそう。

仕事でやっていないということは余暇をこれに当てるしかないので単純に他のことできなさそうでつらい。

そんなブログたちを集めたリンク集(!?)がこちらです

fortee.jp

iOSDC Japan 2022のチケットはこちらで販売中です。

www.eventbrite.com