2022年の思い出コーナー
総評
予想外の様々で思うように行かなかった一年。国際情勢の変化で諦めたことから、数年に一度レベルのヒッデぇミスで12月を潰したりに至るまで。。
色々手は出してるんだけど、なかなか丁度良いサイズの成果が出なくて辛いところ。まぁでもこういう時期ができてしまうのは仕方ない。。
今年のヒット賞
今年はそもそも実験記事1本という少なさ。。来年はもうちょっと小ネタも記事に纏めていきたい。超細かい実験は スクラップの方 に書いてるけど、 スクラップのバグをGHに報告した 感じ、 こういう使い方をしているのは自分だけ なんじゃないかという気が。。いや本当すみません。。
1本の記事自体は3ケタのいいねを集めるなど大好評だった。
今年はiOSやAndroidでのPasskeyの導入があったり、LastPassのリークがあったり、マイナンバーカードが良くも悪くも話題になったりと認証とそのセキュリティが注目される年になった。TOTPは記事の反応でも認知が進んでいることを感じさせるものが多かったので、思い付きを記事にする反射神経はこれからも大事にしていきたい。
もっとも、カーネルを担当していた以前とは違ってセキュリティはあんまり本業でないので、ウケを狙うよりはもうちょっとバラエティに富んだ記事を書くようにしたい。。 今の本業はプロゲーマー (ゲームを上手にプレイして[1]ハイスコアではなくバグを出す)って説明してるけど、それは究極には雑用なのでそれに関した記事ってのも難しいものがあるが。。
来年は、とりあえず1本あたりの反応は追わずに、合計で今年1本ぶんのものは越えられるように努力したい。
OTPは今や謎の数値を数ケタ追加入力する奴として一般にも認知が進んでいる。
もっとも、記事でも触れたようにOTPは今後より"セキュア"な(connectedな)認証器への置き換えが進むと予想している。セキュリティとconnectedであることはどんどん同義になってきている。これはとても危険な兆候である割にはあまり注目されていないと感じている。
身の回りの "PC向けWebサイトではできないが、携帯電話からならできること" を挙げてると、マクドナルドのモバイルオーダーからマイナポータルに至るまで、セキュリティを盾にベンダロックインされたものが増えていることがわかる。直近では、そのような傾向は今後も変わらないだろう。
プロジェクト進捗
進捗はかなり鈍い。。仕事の方ではマイルストーンを置いて何か達成しながらという作り方になるけど、こっちは自分の金でやっているのもあって他人に報告を上げる必要性が無いのが原因じゃないかという気がする。
そういう意味ではZennに記事上げなきゃという記事ドリブンは悪くないはずなんだけど、なかなか良い切り口が無いもんで。。
戦争
後から振り返るにあたってはこれには言及しないわけにはいかない。。個人的に作っていたゲームが割とガッツリと戦争テーマで、流石に今の状況は予想と違い過ぎて一旦ボツに。
ゲームは割と絵本に近い(漫画と違ってフルスクリーン前提である等)フォーマットだと思っていて、テーマ選択の時代性も近いんじゃないかという気がしている。絵本も歴史的には大人達のテーマを避けてきた訳ではないけど、ただ、現実にはそういう段階を飛び越えて社会的な状況が変わってしまったと感じる。
mosh(-scheme)
Mosh[2]というhigepon先生が作成されたScheme処理系 https://github.com/higepon/mosh があって、今回M1 mac対応のために急遽復活してビルドやR7RS(現状最新のScheme標準)対応が入った。
自分とMoshの関わりはZenn最初の記事(2020年)に書いた:
今回のリリースにあたっては多環境でのCIの整備やバグ出し、ビルド関連の整理等を実施した。あと、R7RSランタイムは yuni起源のものを使用している。この関係でyuniは現状ではMoshをサポートしていないが、そのうち解消する見込。
そして未だに Intel MacやFreeBSDで複雑なスクリプトを動かすとクラッシュする 要因がわかっていない。。MoshはBoehm GCを採用していて、GCを切ると正常に動作することから使用中のオブジェクトを解放してしまっていることはほぼほぼ確実だと考えているんだけど。。
来年は...デバッガのスクリプティングを活用するとかでコレ追えないかな。。ヒープ確保/解放のアドレスとbacktraceを全収集するとかなら簡単なのでは。。？
M1環境で脱落したSchemeとしてはLarcenyとかMIT/GNU Schemeのような歴史あるScheme処理系が含まれるが、MIT-Schemeは Win32をバッサリ切った後 、 syntax-rules をほぼ書き直す 等未だに大きな開発が続いている。(Mosh自体はJITC型の処理系ではないものの、)M1 Mac上ではいわゆる W^X要求 があって、 JITCしたコードを書き出す前に専用のAPIでモード切り替えをする必要がある 。Schemeのような言語のJITCはコンパイル単位が超小さいことが多く、単純なロードストアで命令列が書き出せないと辛い傾向にある。有名な処理系であるChez SchemeもM1 Macを直接はサポートしなかったが、 Racketで行われた変更を基本的に全部取り込む方向にある のでそのうちサポートが入ると見られる。
yuni
RibbitというScheme処理系の調査を進めて、クローン処理系を作ってみたり、Schemeの他の機能に対応させてみたりした。
RibbitはコンパクトなVM仕様に加え、 any 型な配列を表現できればどこにでも移植できる https://github.com/udem-dlteam/ribbit/tree/d0082a08df12efca921d37daf04d64fb4ad63b78/src/host という強烈な特徴があって、細かい特徴は去年の論文 https://www.iro.umontreal.ca/~feeley/papers/YvonFeeleyVMIL21.pdf にある。要するに、長さ3の配列(ribと呼ぶ)をLisp的なConsセルやVM命令列の表現に使うことで、シェルスクリプトのような環境でも常識的なパフォーマンスの処理系がコンパクトに実現できるとしている。
ただ、Ribbitの機能性では普通のScheme処理系として使うにはちょっと厳しいものがあるので、可変長引数とか多値のような基本機能が追加できることを示した。まぁ多値はあんまり使わないので常にヒープアロケーションが発生するエミュレーション実装にしたけど。
来年はこの拡張したRibbitに基本ライブラリやFFIを実装してマイコン上で実用的に使えるようにしたい。...そのためにはファイルI/Oのような基本ライブラリを揃える必要があってそれがちょっと面倒。。
yunipocket
去年末の振り返りでスマホ風おもちゃを作れないか って書いたけど、その後実験のために手を替え品を替え歩き続けるハメになり結果的に関東一円を歩くことになった。こんなに歩く年はもう一生涯無いのではないか。
携帯機はどうしても環境要因が大きくなるので、長時間持ち歩き、移動を前提としたものであれば可能な限り連続して実際に移動する必要がある。このため、河川敷とか街道沿いのような地図を見なくても長時間迷子にならずに移動できるところを選んでひたすら歩いている。
結果的に 10kg以上やせた ..元が標準体重だったんで割と健康を犠牲にしている。お金も犠牲になっているのでちょっと来年は近所で済ませないと。。実験内容も記事で整理したいけど、オンサイトデバッグとかセンサの波形記録とかネタとしては面白いものの体を張った記事を面白く演出する自信が無いので保留中。
おもちゃとしての遊びも悩みどころで、太陽電池 + スーパーキャパシタ駆動だと歩数計とBluetoothで限界。そもそも充電できるところに身に付ける必要がある時点で見た目がダメ過ぎる。なのでカメラ + GPSができる乾電池駆動かなぁと。。
今年は企画がなかなか固まらなかったのもあって既製品の改造とかエミュレーションで済ましてしまったので、来年はちゃんとプラットフォームの作り込みに入りたい。今年バカみてぇに浪費した交通費(1回往復で5000円 x1ヶ月に5回とか掛かっている)を削れば試作の予算は出せるはず。
過去には ストラップフォン のようなコンセプトが有ったものの、スマホと機能的に被るモノの"二台目需要"が本当に存在するのかというのは割と否定的な見方が多い気がする。ただ、 カバンに放り込んで存在を忘れる タイプのガジェットは可能性がある。。んではないかな。。と。。乾電池ならLi-ionと違って年単位で放置しても平気なので。
yuniframe
Yuniframeは細かいところで採用していてあんまり大きく動かせないのがあったけど、それが途切れたので2週間ほど掛けて依存ライブラリを更新した。
Yuniframe自体は 去年書いたように ポータビリティレイヤの構築に向って邁進している。去年はUnity WebGLビルドを使って現実的なゲームを確保することを目指していたが、今年はこれに加えて(WebGLがターゲットできる、)WindowsのDirectX9くらいの世代のゲームを移植できないかの検討を始めた。
... ただ、そのためにはWindowsのゲームをOpenGL ES上で動かす必要があって、その段階で結構苦労している。過去にはCodeweaversがAndroid向けのWineを作っていたりして実績自体はある筈ではあるけど、今回はgl4es( https://github.com/ptitSeb/gl4es/ )にOPENGL32.DLL互換レイヤをくっ付け、OpenGLより上はWineのものを直接生かす形で作業している。
そしてコレは まだ Yuniframe上に乗っていない。現状ではWineD3DのWindows版( https://github.com/adolfintel/wined3d4win )を使っているだけでゲーム自体はWindows上で動いている。もっとも、Wine自体の互換性は(ゲームに関しては)相当に優秀なので、GPUの機能性以降の心配はあまりしていない。ただ、流石にGPUだけはCPUエミュレーションではどうしようも無いのでWebフレンドリな実現方法を模索する必要がある。
Yuniframeのような研究、つまり ロバストな、クライアント向けWebAssemblyアプリケーションフレームワーク の実現が重要なのは、 ↑ で書いたような "マクドナルドのモバイルオーダーがPCでできない問題" の解決策として期待している点がある。
Disney+ は既にこのようなアーキテクチャ(ロジックをWebAssemblyに分離し、描画や動画等のプラットフォーム抽象化層を別に実装する)を取っている:
このモデルは多プラットフォーム展開を容易にする、ロジック部分をRustで記述できる、等のメリットはあるが、動画ストリーミング以外のアプリケーションには同一のフレームワークを使えないという課題がある。
より巾広いアプリ、いわゆるスマホeコマースアプリをWebブラウザのようなプラットフォーム上で動作させようとしたとき、WASIがPaymentなりWeb PushのようなAPIをカバーすることを待つより、 既存のメジャーなAPIを効率的に模倣 できるプラットフォームを用意することが望ましいのではないか。実際、WebGLはOpenGLを模倣してよくアプリケーションを集めることができたので。
また、スマホアプリをいわゆるHTML5アプリとして移植してもクラッシュ時の解析が困難になる。コンシューマー向けのアプリを多プラットフォーム展開するのであれば、(Disney+のように)ロジックの変換先にはJavaScript + DOMよりもWebAssemblyが選択されるはずで、そのためのプラットフォームというのが求められていると考えられる。
GoogleにせよAppleにせよ、高速なWebAssembly実行環境、およびリッチなAPI環境としてのWebブラウザをメンテナンス/普及させているわけで、この努力に 効率的にタダ乗りする 必要がある。
逆に、GoogleやAppleのようなプラットフォーマーは移植を阻害するためにAPIやパッケージングのプラットフォーム依存度を高める方向に変えていくだろう。実際、 AppleはXcode14以降でLLVMバイトコードの提出を取り止めている し、GoogleのIntegrity APIは直接ネットワークと関連する機能ではないものの Google Playの一部でありサーバーと通信しないと機能しない 。
来年
まぁ往々にしてチャンスというのはモノにできないタイミングでやってくるわけだけど、そこで諦めてしまうと終了なんで。。
ソフトウェア・ロジスティクス
"ソフトウェア・ロジスティクス" は2000年代後半に造語したソフトウェアの提供戦略で、過去には偉い人にもプレゼンしたりしたものの 全く ウケず、どうやったらウケるのか模索を続けている。
ただ、現状はここ10年で最大のチャンスだと思っていて、来年は分析用のWebアプリの製作とかもうちょっと他人を説得する活動に重きを置けると良いかなと。
ソフトウェアは地理的に偏在する人間が作る以上ハードウェア製品と同様の物流戦略が必要になるという考え方がある。つまり:
- バグを仕込みやすい人間を対策しないと品質向上の阻害要因になる
- 開発拠点が世界に分散している場合、時差を考慮して開発/検証部隊を配置することで効率的なデリバリーを実現する
- リードタイムを折り込んで発注 -- ソフトウェアでは仕様の策定と承認 -- を行うことで納期の確度を上げる
- FOSSや購入(外部調達)したソフトウェアのライセンス管理や別ラインへのコンタミネーションを防止する
- 各種経費が不透明である: アプリケーションアップデートの配信費用、クラッシュレポートの解析費用、SNSのモニタリング費用 などのいずれも、ソフトウェア品質起因のコストとなり得る
- ...
... といった観点を分析するための道具作りが必要で、それらを 連携して 動作させるために、ソフトウェア・ロジスティクスとして1箇所で纏めて扱えるようにするべきだと考えている。
個々のソリューションは死ぬ程市場に供給されている。Coverityのような製品はセキュリティ警告を個人にアサインできるし、SBOM(Software BOM)のような他人が作ったソフトウェアをサプライチェーンとして管理するソリューションも十指に余るほどある。
問題意識としては2つあって:
- ビルドシステムに直結する観測ツールが不足している & 品質が十分でない 。例えばCoverityはGitのようなVCS履歴を参照してソースコードの変更を個人にアサインすることはできるものの、gitのblameは本質的にファイル名変更等に弱く、アノテーションを手動修正するための統一的な方法が無い。
- ソフトウェアのライフサイクルを真にカバーできるツールが無い 。多くの企業ではJIRA等のツールで人間にタスクをアサインし、進捗を管理している。しかし、SBOMのようなデータを分析してJIRAに対して起票を行うのを人間によるオペレーションに頼っている。
個人的には前者の問題にもうちょっと真剣に取り組みたい。過去には ビルドトレースのような提案 もしているけど、ビルドシステムへの分析の挿入は、製造現場における改善と同様に重要なものだと信じている。
後者は現状良いアイデアがない。ソフトウェアによるソリューションを追求するのではなく、これらを見られる人間を育成して円滑なオペレーションを目指す方が良いのかもしれない。実際、元々のロジスティクスにせよさらにその原語の兵站にせよ、人間が担う部分はそれなりに大きい。
AR
今年はPICO4の発売とか大手企業のVRChat参入とか色々あってVRがニュースになった印象がある。しかし、個人的にはVRと(いわゆる)メタバースよりもARの方が可能性があると思っていて、来年や再来年くらいのスパンでAR元年が来るんじゃないかなと考えている。結局のところ人間は現実から逃れられないので。
人間って物理的に存在しているんです。
VRは(ゲームのような完結型のコンテンツを除くと)結局コミュニケーションプラットフォームの囲い込み競争になってしまった感はあるが、ARでそれを起こさないためのキー技術は何なのかという点を模索して行きたい。
現代のARはカメラ画像に上手くCGを合成することに囚われ過ぎているきらいがあると思う。AR的なアイデアは通常のWebブラウジングとかもっと広いスコープでも通用するものがあるはずで、大衆に支持される次のリアリティを提案することが中心的な努力になると考えている。
Discussion