pog3のつぼやき

オライリーの「Rustの練習帳」が発売されると同時に購入し、半分読んだところで忙殺されて、そして諸々やる気も失せて、放置していたが、ようやく再開した。

rust全般に言えることだけど、必要な情報にすんなりたどり着かないことが多く、APIの変化が激しいクレートとかでそれが起きるとうんざりして遠ざかってしまいやすい。このRustの練習帳はコマンドラインのプログラムをいくつも書きつつ馴染んでいこうよというスタンスで書かれているが、そこでキーの一つになるのがclapというモジュール。コマンドライン引数をきれいにまとめて管理するためのクレートでよくできていると思う。しかし、利用者からみてうれしい情報整理がされているとはとても思えない。そのうえで、本で書かれているバージョン2から現在のバージョン4までで破壊的変更が加わっているので、ほんとうんざりする。いや、していた。

このままうだうだしていても何も進まないので、1日かけるつもりで本腰を入れてドキュメントを眺めたり、サンプルコードを眺めたり、試したりすると、なんとなく見えてきたような気がして、ドキュメントの記述にはもやもやしつつも、半日くらいで簡単なコマンドライン引数をゼロからclapで定義して利用することはできるようになった。

ここまでで3章。以前読んだ8章までは特段難しい話もなかったはずなので、少しずつ手を動かしながらおさらいを兼ねて進めるのみ。のみを実行するのがまた(やる気の点で)難しいんだけど。

いつの間にか3月になってる。何もしない内に四半年過ぎちゃってるよ。

NVIDIA Jetson Orin Nano開発者キットを買ったことと、Raspberry Pi 5を買ったことくらいしか記憶にない。

あとは給湯器の交換と屋根の修理で散財したくらいか。

それなりに順調にRustの学習が進んでいる気がする。足踏みし続けずに済んだのは、Rustの身の置き所を掴んだと思えたことと、Rustの言語仕様がとてもシンプルであることが理由だ。

煽りのような「速い」「安全」といったお題目には萎えるが、その根拠が「ガベージコレクションを持たない」「スタック中心」「スコープを出るときにメモリを開放する」であることがわかったのでそりゃそうだと受け流すことができる。

ごちゃごちゃ書き込む必要のあるソースコードも、コンパイラがすべてをチェックできれば実行時エラーまで発覚を遅延させずに済むだろうとの発想からきているのだと思えば仕方ないとあきらめることができる。

さらに、Rustの特徴といえる言語仕様は、トレイトの後付けができることと、属性を持たすことができる列挙型の2つだけだとわかると、コンパイラのルールとそれ以外のルールや習慣とを明確に分離できるようになる。もやもやし続けることもない。

ここまでくれば、実際に何か書きながら、しっかり描かれたものを読みながら、言語仕様をつまみながら、馴染んでいくだけだ。

ちょっとサーバー障害になっただけで慌てふためく。サービス開始からそんなに経っていないのに、google並みに欠かせなくなってる。GoogleのbardやMicrosoftのbingにはそんな感覚が生まれないのに、不思議。やはり、バランスが絶妙なんだろう。

日常的に使うようになったので、粗がとても目立つけど、もう少しすれば自然に避けるようになるだろうから気にしない。

WordPressの更新で、何とかエラーが…と表示されたと思ったら、そのまま処理を継続して「更新成功」してしまった。

なんだったんだろうか。

かなり久しぶりにrust再挑戦。今度はdocker環境を使って(dockerの練習を兼ねて)ホスト環境を汚さず、何かあっても復旧しやすくするというお題もある。なにせ、システムドライブを拡張しようとして、コピーツールによるコピー失敗から起動不可、クリーンインストールという嫌な目にあったばかりだし。

それはそれとして、選んだ本は「プログラミングRust」オライリーの厚めの本。今の自分にはなじみやすい気がする。とはいっても50ページも進んでないけど。以前の経験からガッツリ理解、記憶してから先に進むなんてことは微塵も考えない。vscodeのdevcontainerでrust環境のコンテナを始動、cargo newでプロジェクトを作り、そのプロジェクトを開きなおす。そのうえでプログラムを書いて動作を確認。エラーが出たらChatGPT、GitHub Copilot Chat、Rust公式ページ等を頼りつつ折り合いをつけていく。

ちょっとした目論見があり、pythonのpsycopg2に対応するrustのpostgresクレートを使って、別のコンテナで立ち上げたpostgresに接続した。その後、aws rdsでpostgresqlのインスタンスを作って、それにも接続した。たんに接続確認だけだけど、少し進んだ気がする。

次は、pythonでやろうとしていたクラス化に相当する構造体へのトレイト実装に進みたい。その次はpythonのpandasに相当するpolarsクレートだ。最後にgrib2のデコードをやれば基本は抑えたことになる…かな。楽しみではあるけれど、いったいどれだけ時間がかかることやら。うまくいくならコストダウンとサービス性向上を両立できるし、将来的にも見通しが明るくなるので元は取れる。

WindowsのDocker Desktopではディスク使用量の増加に伴って自動で領域を拡張してくれる機能が有効になっている。wsl2対応後はそういうものらしい。

しかし、いただけないのは、拡張した後は手動でも縮小できないということ。とても面倒な手続きを踏めばできるという記事もあるけど、これを普通と呼ぶのは間違ってる。

システムドライブの残りが100GB近辺まで減ってしまったが、いらないものを消して、当面必要のないものを外に移して、残り400GBまで復活させたけど、この先ずっと気にしていかなければならないのは気が滅入る。それで使わなくなってしまったら、せっかくいろいろ試せるDocker Desktop環境を入れたことが何の役にも立たず、それどころか面倒になっただけである。

何年かのうちにはマイクロソフトが対応するだろうと期待して、目先の対処としてシステムドライブの容量を増やすことにした。

Docker Desktopを使ってコンテナを起動した後、ホストOS直で開発しているのと同じような操作感でコンテナ内で開発できる。

Dockerfileまたはcomposeを用意しておき、Reopen in Containerを選択するとコンテナの作成・起動・接続を自動でやってくれる。接続の際に、/workspace/プロジェクト名のディレクトリを作ってホストのプロジェクトルートとバインドマウントしてくれる。

ただし、Dev Containersが最後にコマンドを実行するため、compose.yamlに書いたコマンドが無視される(実行されない)ということには注意が必要。anacondaコンテナでjupyter notebookを起動する設定になっているcompose.yamlでも、Dev Containersで起動してvscodeと接続した時点でjupyter notebookは起動していない。同じコマンドで手動起動してもいいけど、シェルスクリプト化してcompose.yamlからもDev Containersが作った.devcontainer/docker-compose.ymlからもそのスクリプトを実行するのがいいのではないかと思う。

__getitem__メソッドを定義するとインスタンスをインデックスでアクセスできるようになる。リストを返す関数の機能を拡張するときに、この定義を持つクラスのインスタンスを返すよう変更したら、呼び出し元の既存コードを変えずに済んだ。便利。

WordPressの更新ログってプラグインを入れないと残らないのか？