2022年10月の日記

芥川章受賞作。
途中で放置してあったのを読み終えた。
何とも言えない。
一風変わった職場恋愛の話という感じだろうか。
サラリーマンの世界で閉じている。
何でこの作品を読もうと思ったかというと、ちょっとした、どうでもいい理由があった。

ここのリストから試していった。
9割くらい消化した。
いくつかは問題が発生して実行できかった。

来年3月に発売されるRE4に合わせて、3までやっておくことにした。
最近RE2とRE3のセットになったのを購入した。
ずいぶん前に、1のHDリマスターと0というのを購入して放置したままになっている。
とりあえず1HDを起動してみた。
1は全くプレイしたことがない。
それどころか、Biohazardのどれもまともにプレイしたことない。
ゾンビを倒していくゲームなのかと思ったが、謎ときメインの脱出ゲームみたいな感じになっている。
新鮮で楽しい。
RE4までにPS5をなんと入手したいところだけど、どうなるだろうか。

Packtのクレジット回収のためにちょっとだけのつもりだったのだけど、なかなか良い感じなので最後まで読むことにした。
とりあえず1、2章を読み終えた。
2章では基礎的だけど、関数型プログラミングというかHaskellに慣れていないとなかなか難しいところがあった。
マージソートとエラトステネスの篩が、遅延評価の特性を存分に生かしたアルゴリズムになっている。
じっくりコードを読んで一応は理解した。
これを自力で思いついたり、自在にこのようなものを書けるかと言われると、まだまだトレーニングが足りない。

GTKをやりたかったのだけど、チュートリアルを探して徘徊しているうちに終わってしまった。
断片的なものしか見つからない。
GTK+3からやろうと思っていたけど、これから作るアプリケーションで3を採用することはないだろう。
4から始めたほうが良さそうだ。
2はEOL (End of Life)となっているようなので、もうやらなくてもいいだろう。

昨日の続きのGitのビデオを見ようと思ったら、サーバーのエラーで見れなかった。
まだノルマが残っていたはずなので(これもサーバーの不具合と思われる現象で、あといくつなのか確認できなかった)、代わりに本で稼ぐことにした。

• Haskell Cookbook
  

1章だけ読み終えた。
なかなかハイペースで、良いテンポで進んでいく。
今、まだ「Programming in Haskell」を読んでいる途中で、最近止まってしまっている。
相乗効果を期待して、並行して読んでいくことにする。

しばらくさぼっていたが、ノルマ回収のために見ることにした。

• Git Essentials: Become a Git and GitHub Ninja
  

セクション2途中まで見た。
ちょっと初歩的過ぎる気がしないでもない。
でも「エッセンシャル」というタイトルなのだから、このくらいが妥当だろう。
セクション3から「Advanced Git」となっている。
目次を見る限りそれほど高度な話題ではない。
ちょうどいいくらいの内容だ。

やりたいのだけど、余計なことばかりに手を出して、結局あまりやらずに1日が終わる。

昨日、少し2のチュートリアルを読んだ。
今日もほとんど何もしなかったのだけど、3のチュートリアルを少しだけ読んだ。
GitHubにあるこのチュートリアルを読んでみる。
これはsphinxというドキュメント生成ツールのソースとなっている。
sphinxはPythonのプログラムで、インストールする必要がある。
make htmlとやると、美しいHTMLドキュメントが生成される。

ゲームのライブラリではなく、汎用のGUIのライブラリでゲームを作ってみることを考えている。
例えば、GTK+、Qt、wxWidget、FLTKなどを使う。
目的はゲームを作ることを題材として、それらのライブラリを学んでいくことだ。
同時にゲームの仕組みを研究するという一石二鳥を狙ったものでもある。
(二兎を追うものは一兎をも得ずという諺もある。)
今日はほとんど何もしなかったのだけど、GTK+をちょっと触ってみた。
「gtk tutorial」で検索してでてくる、このサイトを読んでみた。
しかし、いまさらGTK+2をやる意味はあるだろうか。
過去を知ることにも意味はあるかもしれない。
システムにはGTK+2はインストールされていて、まだそれを利用するアプリケーションもある。
ならば、やっておく意味はないことはない。
GTK+1はどうなのだろう。
格ゲーをやるのにストリートファイター1からやる必要はない、2からで良い。
それと同じで、1はやらなくても良いのだろうか。

• いろんな言語のバインディングを試す #5 まとめ
  

これでバインディングを試すの回は完了。
というか、このシリーズ自体を終えることにした。
本当は、だらだらと100回くらい続けるつもりでいた。
しかし、あまりに再生されなさすぎで、別に終了してもいいか、という気になった。
前回、前々回のは1週間で0回という有様。
あえて目立つタイトルやタグを付けずにいたのもある。
内容がつまらない以前に、検索にヒットせず目にもつかないだろう。
あと、ゲームを作っていきながらraylibを摘み食いするような形にすると、なかなかraylibを使い込んでいくことができない。
「raylibを使ってみる」というタイトルに相応わしくない感じがしてきた。
それよりは「アクションゲームを作った (raylib使用)」みたいな感じの方が適切に思える。
そんな訳で、このシリーズは終わりにする。

Nautilusに続いて、TerminatorもFcitxが効かなくなった。
GNOMEターミナルは問題ない。
調査していると、Terminatorのセッションでは、GTK_IM_MODULEが空になっているようだった。
他の端末ではちゃんとfcitxがセットされている。
Solusでは、システムデフォルトのユーザー環境設定ファイルが/etcではなく、/usr/share/defaults/etcにまとめられている。
この辺りを中心に、GTK_IM_MODULEを空にセットしているものがないかを調べる。
その他にも色んな場所を3時間くらいかけて調べたが、何も見つからない。
Webを徘徊していたら、問題が特定できた。
現在インストールされているTerminatorのバージョンは2.1.2となっている。
これは、現時点で最新で、3日前にリリースされたばかりのバージョンだ。
バージョン2.1.2の変更の概要を見てみると、次のような記述があるのを見つけた。

Added hotfix for #78 that deletes GTK_IM_MODULE environment variable by @ozzdemir in #574

これだった。
NautilusとTerminatorの問題の原因が同じところにあると思い込んでいた。
システムの設定に問題があると目を付けていたため、なかなか発見できなかった。
Terminatorの実行ファイルはPythonのスクリプトファイルなので、直接覗くことができる。

$ ag GTK_IM /usr/bin/terminator
59:if os.environ.get('GTK_IM_MODULE') is not None:
60:    del os.environ['GTK_IM_MODULE']

なるほど、確かにGTK_IM_MODULEを潰してしまっている。
付焼刃でバグを潰した結果、別のバグを生むという典型的なバグの好例になってしまっている。
では、Nautilusの方はなぜFcitxが効かなくなったのだろう。
これも、新しいバージョンでの変更が原因だった。
現在インストールされているバージョンは43.0となっている。
いつからこのバージョンがインストールされたのかは知らない。
予想では、先々週あたりにちょうどNautilusで日本語が入力できなくなった辺りで、GTK3からGTK4に切り替わったバージョンに更新されたのではないだろうか。
Solusには、Fcitxのバージョン4しか用意されていない。
関連するパッケージとして、fcitx-gtk2とfcitx-gtk3というのがある。
しかし、fcitx-gtk4はない。
これはおそらく、GTK4を利用するアプリケーションではFcitxの入力ができないことを意味するのではないか。
fcitx5-gtkのプロジェクトには、gtk4がが含まれている。
Solusでは、頻繁にアップデートがある割に、このような重要なところが抜け落ちてしまっているケースにたまに遭遇する。
Terminatorの方は、別の端末に乗り換えることを検討する。
NautilusはFcitx5が追加されることを期待したい。
あるいは、Fcitx5をソースからインストールすることになる。
これはちょっと大変そうなのであまりやりたくない。

DistroWatchを覗いたら、Ubuntuとそのフレーバーが一斉にリリースされていた。

昨日が発売日だった。
まだ新しいマザーボードは出ていないもよう。
現行世代のが使えるので、Ryzenに比べて安く揃えることも可能。
RyzenのAM5のものはX670が5万↑、B650が3万↑といった感じ。
どうせ高いCPUを買うなら、せっかくなのでマザーボードも新しい世代のものにしたいという欲が湧いてくる。

7500円くらい。
これまでKindleで購入した中では最高額になった。
それでも紙の方を買うより半額程度に抑えられている。

!!!!この記事はただの雑記です。何の信頼性もありません。決して参考にしないで下さい。!!!!

久々にQtのWebサイトを見た。
何か、Qtのプロダクトマップというのができていて、製品やライセンスによって、どのコンポーネントが使用できるのかを分かりやすく確認できるようになっていた。
ここで、ライセンスにLGPLv3を選択すると、Qt Creatorが外れてしまう。
GPLにすると有効になる。
それで、あれ、Qt Creatorを使ったらGPLが強制されるの？と疑問に思ってしまった。
Qt6になって変わたのか？とも考えたが、よく考えればそうではない。
Qtをアプリケーション開発に使用するのにはGPLからLGPLv3の下で使用できると書いてある。
これは以前と変わっていない。
おそらく、まず間違いなく、Qt Creator自体がGPLでライセンスされていて、その条件の下で使用できるということだろう。
Qt Creatorで書いたコードにもGPLが適用されるということはないはずだ。
例えば、GPLを採用している代表的なソフトウェアとして、Emacs、Gimpなんかがある。
これらを使用した場合を考えてみる。
Emacsで書いた文章やソースコードは必ずGPLにしないといけないのだろうか？そんなばかげたことがあるはずない。
Gimpで加工した写真や描いたイラストなどを公開するときにはGPLを適用しないといけないのだろうか？そんなばかげたことがあるはずない。
Qt CreatorがLGPLv3を選択したときに、外れてしまうのはそれと同じことだろう。
(オープンソース利用での)Qt Creator自体はGPLでライセンスされている。
Qt Creatorを使ってできた成果物、主にソースコードになるだろうが、それをGPLにしないけないというわけではない。
Qt CreatorそのものがGPLだということだろう。
これがどういう意味を持つかというと、例えば、Qt Creatorを再配布したいときや、Qt Creatorを改変(おそらくは拡張)して、対価を得たいとき(GPLはこれを禁止してはいないはず)なんかだろう。
この場合は、Qt Creatorは当然GPLだし、一緒に配布するものもGPLになるだろう。
配布先にQt Creatorのソースコードや、一緒に配布するもののソースコードにアクセス可能な状態にしなければならない。
このようなケースはそれほど多くはないだろう。
Qt Creatorを改良して、それをを公開あるいは販売したいというのは、よっぽど野心的な開発者に限られると思う。
もっとよくありがちなのは、普通にQtアプリケーションを開発して、そのアプリケーションを配布することによって対価(金銭とは限らない)を得たいというケースだろう。
このQtアプリケーションは、おそらくQtのライブラリとリンクされることとなる。
Qtのライブラリも一緒に配布しなければならない場合もあるだろう。
その場合、配布するQtのライセンスは、オープンソース版として、GPLだけでなくLGPLv3を選択できるはずだ。
LGPLv3を選択する場合、Qt以外の部分で、自身が開発したアプリケーションそのものについては、他に制約がなければだが、任意のライセンスを選択できることになる。
注意深く開発すれば、自身が開発したアプリケーションのソースコードを公開しないでいいようなライセンスを適用することも可能となっている。
とはいっても、GNUライセンスのフリーソフトウェアを使用する開発者なら、多くの場合、ソースコードを公開する方が利益になると考えているだろうから、クローズドソースにしたいというケースは少ないだろう。
自分の場合、以前Qtを使用したアプリケーションの開発では、QtをLGPLv3で、アプリケーションをMITでという奇妙な組み合わせで納品した。
自分が開発したアプリケーションのソースコードを配布することには、全く何の障害も抵抗もなかった。
それならGPLを採用すれば良かったのだが、GPLだとクライアント側に不都合が起きる可能性を否定できなかったので、もっとゆるいライセンスにしたかった。
それが正しい選択だったのかどうかは分からない。
しかし、Qtのライセンスに違反していないはずだと自信を持って納品した。
これだけだと話は簡単そうだけど、WindowsでVisual StudioのC++を使わずに、MinGW-w64を利用したので、それに含まれるGCCやライブラリなどのライセンスも絡んでくるとかなり複雑になってくる。
よくよく調べていくと、ライセンスは巧妙に、不便が発生しないようにうまく連携されている。
話をQt Creatorに戻して、もしQt Creatorを使うけど、Qtに関係しないアプリケーションを作る場合という使い方も普通に考えられる。
つまり、Qtのライブラリに一切リンクしないというケースになる。
Qt CreatorはC++のIDEとしても優秀で、現実的な選択肢だ。
この場合、Qt Creatorでビルドしたアプリケーションを配布する場合はどうなるのだろう？ということを考えてみる。
これはたぶん、Emacs上でビルドしたアプリケーションを配布するのとまったく変わらないのではないだろうか。
つまり、そのアプリケーションが使用するライブラリやコンポーネントのライセンスに従わなければいけないという点を除けば、自由にできるということ。
C++のアプリケーションなら、おそらく、少くともlibstdc++あるいはlibc++のどちらかを利用するのがほとんどだろう。
C++の標準ライブラリは、ヘッダーにインターフェイスだけでなく、本体が記述されている部分が多く、実行時のリンクだけではなくコンパイル時にもプログラムが取り込まれることに注意したい。
libstdc++はGPLv3だが、例外が認められていて、リンクするだけでアプリケーションもGPLにしないといけないということはない、ということになっている。
これも巧妙な、興味深い話題なのだけど、ここでは何も書かないでおく。
それらのライセンスに従えば、Qtのライセンスと、つまりLGPLv3やGPLとは無関係ではないだろうか。
そうであることが理想だ。
そうでないと、Qt CreatorでコンソールのHello Worldを書いただけで、そのプログラムはQtのライセンスに縛られてしまうという意味不明なことになってしまう。
現実はどうなのだろう。

なぜか調子を合わせたように、いくつかのPCが明らかにハードウェアの問題で起動しなくなる、あるいはひどく不安定になった。
だめになったのは2台で、もう10年以上経過しているので、仕方ないといえばそうだ。
さらに最近まで現役だったモニターも不調で使用に耐えない状態になった。
残念に思うよりも、埃っぽい部屋の過酷な環境で良くがんばってくれたと労うべきだろう。

ラズパイ4のキットに付属していたHDMIケーブルの、microの方の端子が曲って、直そうとしたらどうしようもなくなった。
ラズパイ400をちょっと傾けたときに負荷がかかった。
キットには2本付属していて、そのうち1本はずっと未開封のままで、今日開封したばかりだった。
最初、ちょっとショックだった。
しかし、よく考えると、この程度で死んでしまうようではどのみち使いものにならない。
このケーブルはラズパイ4用のものであって、キーボード型の400のものではないということだろうか。
それでも耐久性なさ過ぎだろうという気がする。
ケーブルが悪いのか、ラズパイ400の構造が悪いのか、何ともいえない。
キットはOKDOのもので、信頼がおけそうなものだけど。
学んだことは、400は膝の上置いて使ったりせず、安定した場所で、できるだけ動かさずに使った方が無難だということだ。
400の方が逝かなかったのが不幸中の幸いとしておこう。

ラズパイ用にHDMIケーブルを3本確保しておいた。
ついでに何かお買い得なものがないか探していたら、つい長々と物色してしまった。
Kindleでいくつか。

• GPU Zen 1, 2
  
• Functional Programming, Simplified
  

GPU Zenは、あなたへのオファーに出てきて、5%だけだがポイントバックされるとでたのと、両方合わせて1500円程度と安かったので買ってしまった。
あと、またやたら安くなっていたハードカバーの本を見つけて買ってしまった。

• C++ Template Metaprogramming in Practice
  

「c++ template」とか検索したら出て来た。
テンプレートメタプログラミングでディープラーニングのフレームワークを構築するという、野心的な内容で興味が湧いた。

あともう1冊だけ買っておきたいのがある。

• Real-Time Collision Detection
  

2004年のかなり古い本だけど、これに代わるものは見当たらない。
もっと早くに読んでおくべきものだった。
紙のバージョンはやたら高いので、Kindle版を買うことにする。
今日はもう残高が足りなくなってしまったので、明日チャージして購入する予定。

遠出して、というか用事があったのでそのついでに本屋に行った。

• 大学数学 入門の教科書 上・下
  
• ハイスコアガール DASH (3)
  

せっかく来たのだけど何も買うものがない…というのは言い過ぎだけど、今回は割と安い買物だった。

Solusには、KDEゲームのパッケージがないようだ。
SnapかFlatpakを使わないといけなそうで、不便に思える。
Debianのゲームは充実している。

型と型クラス。

Solusのパッケージに参考になるゲームはないか探していたらtaiseiというのが目に入てきた。
説明には「A free and open-source Touhou Project clone and fangame」と書かれている。
ホームページでWeb版をやってみたが、本家に劣らない完成度だ。
githubでソースコードも公開されている。
クオリティも高い。
良いものを発見した。

トレーニングのため、シンプルなゲームを作りたいと思って、カタログみたいなのを探していた。
とりあえず、GNOMEのゲームをインストールしたくて、セットになったパッケージ、あるいはリストを探していた。
Ubuntuのgnome-gamesパッケージが見つかった。
Solusでは、セットになったパッケージはなくて、個別にインストールしないといけないようだ。
また、フリーのゲームを紹介している良いサイトを見つけた。
ここでもGNOMEのリストは見つかったし、おまけで別の良いゲームのコレクションが見つかった。
フルネームは「Simon Tatham's Portable Puzzle Collection」という名前で、eopkgではpuzzlesというパッケージ名になっている。
しばらくこれのクローンを作っていこうと思う。

他にもいくつか参考になる候補がある。

• Debianのdebian-gamesパッケージ
  
• KDE Games
  
• Snapでインストールできるゲーム
  
• Flatpakでインストールできるゲーム
  

Lisp系の言語を3つをやった。

• Racket
  
• Common Lisp
  
• Guile
  

Racketは、パッケージマネージャーからインストールするだけですぐ終わった。
IDEのようなものも付属していて、楽しそうだ。
初めてLispを学ぶのにも良い環境ではないだろうか。
Common Lispは、ちょっと苦戦した。
Quicklispというパッケージマネージャーが利用できる。
cl-raylibのセットアップは、Quickilispの環境に手動で追加する形になる。
依存するパッケージがcffi以外にもある。
READMEに書かれていなくて、発見するのに手間取った。
以前Land of Lispを読んだので、少しは、本当にほんの少しはやれるかもという自信があった。
でも全然、現実のプログラミングに対応できるほどは身に付いていないようだった。
Quicklispの存在を知らなかった。
Quicklispを利用しない場合、どのようにしてライブラリを配置したりロードするのかも分かっていない。
Guileは、このシリーズの中で一番大変だった。
まず、Guile自体のビルドが45分かかるった。
言語の見た目に反して重量級のソフトウェアとなっている。
eopkgでインストールできるのは、バージョン2.0となっている。
バージョン3系列が必要なのと、2系列としても古いので、ソースからビルドすることは避けられなかった。
やたら時間がかかるものの、手順はそれほど難しくもなかった。
追加で依存するパッケージを2つほどeopkgでインストールしただけで、割とすんなりいった。
問題は、raylib-guileだった。
birthdaywareとなっていて、実用目的というより記念品的なプロジェクトとなっている。
Makefileが不完全で、いろいろ模索しなければならなかった。
その過程で色々と学ぶことができて勉強になったので、かえって良かった。
本当はClosureもやっておきたかった。
Javaのバインディングがあるので可能だろうと踏んできる。
しかし、半日くらいかけてやっていたので、疲れた。
まだClosureの本を買ってから全然やってないので、今やる必要もないかと思いやらなかった。
詰め込みすぎるのも良くない。
今日は撮影も合わせると、1日中このビデオに取り組んでいた。
一応、完走できて満足している。

また別言語のバインディングをやった。
これで3回目。
Hare、Haxe、Vと、それほど有名とは言えない言語を選択した。
Vは割とすんなりいった。
HareとHaxeはかなり苦戦した。
Hareのバインディングも、Haxeのバインディングも、あまり実用的ではないかもしれない。
実験的なバインディングだという認識でいる。

NautilusってのはGNOMEのファイルという名前のファイルマネージャーのこと。
ファイル名の変更とか、検索で日本語が入力できなくなった。
メインで使っているユーザーは、普通に、というほどではなく、変換ウィンドウが変な場所に表示される、一応は入力できる。
動画撮影用のユーザーや、新規に作成したユーザーでも入力できない。
ちょうど今日、システムの更新を行ったので、それがきっかけとなったことが考えられる。
少くとも、前回動画を撮ったときは大丈夫だったはず。
まったく解決の糸口が掴めない。

ビデオを撮ろとしていたが、結局やらなかった。
最近いろいろできていない。
アルゴリズム、数学序説、Haskellを毎日やるはずだった。
うまく回っていない。
どうも並行して何かをするのが苦手なようだ。
並行プログラミングが苦手なのも関係するのだろうか。
いやないだろう。

ブックオブで2冊。
Swiftデザインパターンの本と、符号理論の本。
必要ではないけど、220円だったので買ってしまった。

リストが更新されていて、待望のHaskellが追加されていた。
対象のraylibは4.5となっている。
Haskellをやるモチベーションが上がってきた。

夜中3時頃に目が覚めて、そのまま起きていた。
変な時間だが、次の用意はしてあったので撮ってしまうことにした。
前回の続編で、Nim、Zig、OCaml、Odinでbasic windowを動かすというのをやった。
だらだらとしゃべってるだけ。
思ったより面白いものにはならかった。
他の言語もやっておきたいところだけど、こんな調子ではあまりやる意義はないような気がしている。

他言語のバインディングを使っていくというのをやった。
Node.js、Lazarus、Dでやってみた。
ただウィンドウを表示するだけ。
もうちょっと掘り下げないと面白くはならないだろう。

Zig、OCamlをやってみた。
Zigはまだ新しい言語で、環境が整っていないようだ。
パッケージマネージャーがまだなくて、熱望されている。
raylibのバインディングは2つある。
raylib-zigとraylib.zig。
raylib.zigの方は、Zigのバージョン0.10.0を要件としている。
公式のリリースは0.9.0で、満たしていない。
おそらくgithubの開発版でないとだめなのだろう。
raylib-zigは、それ自体がライブラリとなっているのではなく、プロジェクトを生成するためのスクリプトとなっている。
raylibのソースとバインディングを含むプロジェクト一式を生成する。
raylibのソースのサイズが427MBとかなっていて、これがプロジェクトごとに含まれてしまう、あまり実用的ではない。
OCamlの環境は整備されている。
opamというパッケージマネージャーで、任意のバージョンのOCamlのコンパイラをインストールすることができる。
raylibもこれでインストールできる。
ビルドツールはduneという。
duneファイルの記述にちょっと手間取った。
複数の実行ファイルを生成したい場合、modulesというセクションを記述する必要がある。
OCamlの言語も環境はとても洗練されている。
現実のプロジェクトの使用にも完全に耐え得るものだと思える。
一方、関数型プログラミングであるといこともあって、学習コストが高いようにも思える。

どの言語でやるか決められなくて、気になるのを試していた。

• Node.js
  
• D
  
• Nim
  

Node.jsでは、raylibはnpmでインストールできて、かなり簡単に始められる。
npm init して npm install raylib とするだけで良い。
たぶん、オリジナルのCを除けば、一番気軽に始められるのではないだろうか。
Dには、dubというパッケージマネージャーがある。
以前、もうずいぶん前になるけど、Dに触れたときは、パッケージマネジャーは存在していなかったように思う。
dubの使い勝手は抜群で、最近の言語のパッケージマネージャーにも全く見劣りしない。
しばらくしないうちに、どんどん進化していくものなのだなと思わせてくれた。
Nimは、2008年に登場した言語のようで、新しい部類ではあるものの、そこそこ前から存在していた。
全く知らなかった。
Solusのパッケージマネージャー(eopkg)からインストールできるバージョンはやや古く、raylibのバインディグンが必要とする要件を満さない。
最新のバージョンをインストールするには、choosenimというのを使うのが良さそうだ。
最新バージョンだけではない、任意のバージョンのNimをインストールできる。
パッケージマネージャー、ビルドツールはnimbleという。
特に理由はないのだけど、なんとなく、次にこのシリーズでやるならNimかなと思っている。

アクションゲームを作る MoonScript編 #7 (完)

やっとMoonScriptでアクションゲームを作るシリーズが終わった。
1ヶ月間も放置していた。
ずっと気にかかっていたので、無事終えることができてほっとしている。
今は縛りから完全に解放されたので、何でもできる。
次からは、1回で完了するようなもっと軽いのにしたい。
ゲームを作ることよりも、raylib自体のことにもっと焦点を絞っていきたい。
言語ももっと色々試したい。
長期戦になるのを選択しないように気をつけよう。
raylibでゲームを作るのは継続する。
その過程を漏れなく動画にするのは大変な割に、他人が見ても面白くもないし、役にも立たない。
それを目的でやっているわけでもない。
動画のことを意識しつつ作成するのは効率も悪い。
ゲームを作るのは裏で進行しつつ、その中で発生する興味深いことを単発動画にしていくことを考えよう。
できるだけ毎日アップできるのが理想なのだけど、厳しいかもしれない。

今度こそ止まっているアクションゲームを再開して、完成させる。

いろいろ。
久々に新しいCDに手を出したのだけど、今回は大当たりだった。
南條愛乃さんのベスト盤にMelodies of LifeとWeight of the Worldが入っていてどきっとした。
どちらもカバーということだと思う。
やくしまるえつこ。
最高だった。
最近YouTubeでよく聞いているポップしなないで。
かなりの再生回数になっていたのでもしかしたら置いてあるのかもと思ってたところ、本当に置いてあった。
CDで聴くとまた違った印象を受ける。
The Strokesの新譜は輸入盤になっていた。
日本ではリリースされていないのだろうか。
どれも購入しても良いと思える。
買うかもしれない。

やっと手を再開することができた。
ゴールしたとき、ポールから滑り落りて、城の中に入っていくのがメインとなる。
あとは、ゲームオーバーやクリア後にRキーで最初からリスタートできるようにしたりした。
つぎはぎだらけでみっともない感じのするコードだけど、ひととおりゴールまで動作する。
デザインパターンを学習していたのが少し役に立ったか、CommandとObserverを意識して採用した。
あとはもう一度、本番の方で録画すれば、MoonScriptでアクションゲームは完了だ。

1、2章を読んだ。
めっちゃ面白い。
買ったのはずいぶん前で、ずっと読もうと思っていたのに読めずに時が過ぎていった。
今まで読まずにいたことが悔やまれる。
毎日1、2章ずつくらい読んでいくことにする。
特に何かを習得しようという目的があるものではない。
ただ何となく読んでおかないといけない気がするというだけのものだ。
面白いのでまったく苦痛はない。

\(\chi^2\)分布はちょっと難しい。
そうでもないかも。
ただ、正規分布の乱数を生成する関数が別項目に用意されて、それからまた別項目に、とネストしているので、後回しにすることにした。
カオスとアトラクトというのをやった。
数式もコードも簡単なのだけど、それによって生じる結果が何を意味しているのか理解するのは簡単ではない。
視覚的に体験するためのグラフィックスのコードも付属している。
これはraylibを使ってやった。
フラクタルトは違うもののようだが、再帰的な構造をしている。
なかなか趣深いものになっている。

• 12章 Compound (MVC)
  
• 13章 実世界でのパターン
  
• 14章 (付録) その他のGoFパターンの紹介
  

12章のCompoundはこの本で唯一GoFのパターンではない。
MVCのちゃんとした解説というのは読んだことがなかったので、この機会に読むことができて良かった。

13章は本書の中で唯一新しいパターンを取り扱っていない章。
言ってみれば、これまでの総括といった章。
デザインパターンを学んで、新しく手に入れた道具を使ってみたいと早る読者に対するアドバイスといったところ。
多くが陥りがちなパターン「初心者はどこでもパターンを使おうとする」ということが書かれている。
もし自分が初心者であって、経験を積むために敢えてそうしているという自覚があるなら必ずしも悪いこととは言えないようにも思える。
しかし、現実では多くの場合は無邪気な勘違いによるものがほとんどだったりする。
この章では、どのようにデザインパターンと向き合っていくのが良いか、パターンを使うためにパターンを使ってはいけないのならどうすれば良いのか、いつ使う機会があるのかについてのアドバイスがある。
これまでのパターン礼賛から打って変って消極的な感じもする。
ただのパターン布教本に終わらせず、有用なガイドブックとするためにはこうした現実に即した総括は不可決だ。

14章は付録ということで、本当におまけ的な解説だった。
あまり使われなくなったパターンとあるが、どれも役に立ちそうに思える。

この前に読んだオブジェクト指向のこころに次いで、デザインパターンの本を2冊続けて読んだことになる。
次はどうするかについて考えてみる。
現状、本を読んだだけで、まったくプログラミングしていないので、身に付いていないことは確かだろう。
「初心者はどこでもパターンを使おうとする」ということだが、どこかで使わなければ経験値が貯まらない。
どこで使うべきか。
それは実験的なプロジェクトから始めるのが良いだろう。
しかし、やっぱりパターンを使いたいから使うのでは、そもそもの動機が間違っていて、間違った設計方法を身に付けてしまうことにもなる。
ひとつヒントが書かれていてリファクタリングはパターンが活躍する場となっているようだ。
なぜ今デザインパターンをやり直そうとしていたかというと、今作っているゲームのコードがどうにも気に入らず、なんとかいい感じにできないかというのがきっかけだった。
デザインパターンにうまいことコードを作り直すことができないか、助けを求めていた。
そしてリファクタリングするべきコードは手元にある。
すると、今度はリファクタリングについて学ばないといけないのだろうか。
デザインパターンは過去に学んだことがあるので、記憶を掘り返すような部分があったが、リファクタリングは学んだことがない。
本をは持っているのだけど、未開封の状態だ。
やるべきかどうか、それが問題となる。
今作っているゲームにはオーバースペックな気がする。
ゲームを完成させる優先度を上げて、一旦完成させてからにするべきだ。
ということで、リファクタリングはまだやらないことにしよう。
まだオブジェクト指向とどう向き合うべきかの答えが出ていないので、まずはそこからとなる。
C++を使い続けるなら、オブジェクト指向をもっとがんばる価値がある。
C++はだんだんオブジェクト指向とは別の方向に向っているようなところがあるものの、まだまだ有効で現実的な解決策だ。
それにゲームと相性が良い。

C++以外の可能性もある。
Rustと、単にやりたいからという理由でHaskellも視野に入れている。
ということで、選択肢は3つだ。

1. C++
   
2. Rust
   
3. Haskell
   

そろそろ決断を下して、本気で取り組むべきときに来ている。
C++以外を選んだなら、もうオブジェクト指向をがんばる必要はない。

Proxy。
RMIをはじめとしてJava固有の話題が中心で、どうなのかなという感じがした。
色んな変種が存在することを知った。

有給で休みだったのだけど、ずっと寝てた。
やりたいことが色々あったのに無駄に過ごしてしまった。

Ryzen 7000が発売されたので、今度こそ買い替える機会かと思い、PCショップに行ってきた。
その場で買うかどうかは決めてなくて、とりあえず一度は覗いておこうというつもりで行ってきた。
置いてあるかどうかも分からなかったけど、ちゃんとあった。
Ryzenの価格はどのくらいなのかあらかじめ知っていたので、そんなに驚きはしなかった。
しかし、マザーボードがべらぼうに高い。
AM5のものは5万オーバーのしかなかった。
自分の感覚ではマザーボードは1万〜2万が相場なので、5万は厳しい。
さすがにいきなり購入には踏み切れなかった。
今ちょっと調べてみると、CPUと同時に発売されたマザーボードはX670というチップセットを採用しているものばかりのようだ。
これは比較的上位クラスのチップセットとなる。
ややコストダウンしたものはB650で、これは10月11日から順次各メーカーから発売されるようだ。
お気に入りのASRockのも10月11日に発売予定となっている。
しかし、B650のものでも4万前後となっている。
これでも高いように思える。
AM4のB550なら1万5千前後になっている。
このくらいが理想なのだけど、仕方ない。
B650が発売されたらもう一度、今度は購入に踏み切るつもりで行ってみよう。

State。
直感的で理解しやすい章だった。
ゲームでプレイ中とかポーズ中をStateパターンで管理するのはどうだろう。
どういう長所と短所があるだろう。
短所として思いつくのは、ゲームの本体がStateの中に埋没してしまうという点。
これは工夫しだいで回避できそうな気がする。
State自体にゲームを埋め込むのではなく、ゲーム本体のリファレンスを持つだけにして、ゲームに処理を委譲する。
工夫という程でもないが、そんな感じだろうか。
それでもゲームのシステム全体がStateに大きく依存してしまう形なってしまい、どうも違和感がある。
一度試してみてから判断しよう。

中途半端なところで止まっていた。
面白くて一気に読み終えた。
ににわかものの自分には手の届かない、そこそこ高度なトピックを扱っているはずなのに、不思議とすらすらと読めてなんとなく理解できたようになれる。
この本を購入した理由は、四元数のことをもっと知りたかったからだ。
ゲームプログラミング、3Dグラフィックスのプログラミングでは、四元数を制するものがゲームを制するといってもいい。
別に使えればそれでいいという考えもあるだろう。
しかし、頭一つ抜きん出たいというなら、基礎となる数学の理解は絶対必要となる。
この本では、四元数による回転についていくらかページが割かれている。
「やった!」と思ったところだが、どうも理解が追いつかない。
しかし、まったくお手上げという感じでもなく、雰囲気は伝わってくる。
それってまったく理解してないんじゃないかと言われればそうだろう。
真剣に取り組んだわけではなく、読みものとして軽い気持ちで読んだので、きっちり理解しようという準備もできていなかった。
もう途中で止まっていたところから、1年以上経過している。
もし、完璧に理解するまで進まないとやっていると、こういうことになる。
理解は不完全であっても一度は読み通してしまった方が良い。
その後、折を見て読み直すこととする。

一つ一つの章がかなり短い。
冗長な記述がなく、さくっと読み終わる。

8章

Template Method

9章

IteratorとComposite

大変分かりやすいのだけど、身に付いているかどうか、実戦で活用できるかどうは自信がない。
それに、こうして本でふむふむと情報だけ詰め込んでいく学習スタイルの弊害として、実戦でその方法に縛られてしまうことが考えられる。
もはやオブジェクト指向だけの世界で生きていけるほど現実は簡単なものではない。
元からオブジェクト指向が完璧な方法論だとは思ってもいなし、むしろ疑問をずっと抱いていた。
なのにその方法をまた学習して、実戦に応用しようなどというのは、自分の行動指針にさえ疑問を抱く。
と、そんなに思いつめずに、軽い気持ちで学んでいけば良いだろう。
どういったスタイルを確立するかは、一通り広く手を付けてからでも遅くはない。
おそらくオブジェト指向をメインに据えることはないだろう。

続きの11章から読もうとしたら、QuickCheckのバージョンの違いでテキストのコードが動かない。
調べれば良いのだけど、どうもそのような気分になれない。
1ヶ月近く空いてしまったため、どういう手順で進めていたのか思いだせない。
Spacemacsとstackを使っていたのは覚えている。
一度しっかりとstackのことを叩き込んでおかないといけない。
そうしないと効率が悪い。
Real World Haskellはタイトルの通り、現実のプログラムを書くことに焦点を当てている。
現実のプログラムを書くことでHaskellを学び、理解を深めようという狙いだ。
これは好みなやり方なのだけど、Haskellには向いていないかもしれない。
先に基本をみっちり叩き込んでから現実のプログラムを書くようにした方が良いように思える。
そういうわけで、Real World Haskellは一旦中断することにした。
代わりに、Programming Haskell (2nd edition)を読むことにした。
こちらは新しいし、広く読まれている標準的なテキストだ。
少し前に購入したものの、固くて難しそうな印象が合ったので、手を付けていなかった。
試しに1章だけ読んでみたら、今のところは全然そんなことなかった。
注意深く、不正確な記述がないように書かれていることが分かる。
そして、詳細に入り過ぎたり、ページ数が限られているので余計な話題がない。
大きく、Haskellの基本と高度な話題の2つに別れている。
まずは基本の方をもう一度きっちり学んでみよう。
現実に目を向けるのはそれからで良い。

階乗進数。

できるだけ毎日やるようにしているが、進め方に疑問を感じてきた。
Cはいい。
他の言語でやるとき、Cのをそのまんま書き換えたような作りになっている。
考えるのが面倒で、そうしているのだけど、どうにも正しいやり方になっているとは思えない。
特にEmacs Lispはひどいものになっている。
やるなら、ちゃんと適切なスタイルで書くべきだ。
元々の目的は、ついでにそれらの言語に慣れていこうというもので、それらの言語でアルゴリズムをどうやって書けば良いかを発見しようというものではない。
だから、今のようにだらだらと続けていても、当初の目的から外れるわけではない。
しばらく続けてきて、だいぶ慣れてきたというのもあって、単にそのまんま書き換えるだけではもの足りなさを感じてきている。
これは良い兆候と言えるかもしれない。
最初はどう書けばいいのか、例えばwhileループはどうやって書くのか、とかすら調べながらでないとできなかった。
それが自然とできるようになって、Cを書き換えるだけの簡単なお仕事です、という感じになってきた。
止めるつもりはない。
しかし、もうちょっと優れたコードにしたい欲が湧いてきた。
そうはいっても、毎日継続するために、ある程度時間を切ってやらないと続かない。
そのバランスがちょっと難しい。

今月はちょっと大きな転機となる行動を起すことになる。
色々活動しないといけない。
そうはいってもあまり深刻には考えていない。
なんとかなるだろうというくらい。

AdapterとFacade。