蛾とサソリの二匹出てくるボスがいるんだけど、調子よく殴っていてこれはいけるのでは、という気持ちになったら合体して走り回ってめちゃくちゃになって負けました。モンハンにそういうやついたね。いたいた。
途中で「兆し」のやつが襲ってくるやつランダム発生だと思うんだけど、やっぱりこいつの水バシャーってやってくるやつが避けられない。ボス戦だと地形に起伏があるのでひたすら下がって地形で回避ができるんだけど、平地みたいなとこで水泡が出て召喚されるとうまくいかない。ガードしても物理じゃないので大きく削られてしまう。あれ、前に転がったら回避できたりするのか...?
そういうことを考えて準備してるときは出てこないんだよな。で、忘れたころに出てくる。知ってる。ギギギ。
gitのコマンド体系の良さは「現在の作業ディレクトリの状態」を常に利用者に意識させることにあると思う。たぶん、これが利用者のメンタルモデルとあってるからうまくいっている。
もともと存在するプログラマのメンタルモデル。ソースコードには修正が連なるひとつの trunk(幹)があり、それに対して自分が作業しているのが途中から分岐した branchであるぞ、という世界の理解があるので、git の操作に慣れるのは正規化されはするけど、まったく新しい不自然な概念を学ぶことにはならない。
でもこれがうまくいくのは端的には非凡なセンスのなせる業という気もする。最近だと uv と nix がセンスいいなと思った。使っているとそのかたちに矯正されていく感じがする。あるコマンドをたたくと自然に次にやることが頭に浮かぶ。というのは、自分の置かれている状態が更新されるということで。それが現実世界とズレる不安が小さい。
react-reduxとかTEAもそういうとこあった。しばらく使っていると、UIの更新を一つの状態モデルへの更新差分のストリームをランタイムが処理するイメージが頭に構築されていくし、それはWebフロントエンド以外でもそういう見え方をするようになっていく。すると以前あんまりしっくりこなかったIOモナドみたいなのがぐっと身近に感じられるように...などと連鎖していく。
そういう道具を使ってると、この道具センスいいな～、となんとなく思っちゃうんだけど、これはかなり自分中心の相対的な感覚だと思うんだよな。自分のものの見方をアップデートしてくれる、ブレない軸をもったなにかのことを、センスいいなと感じる感覚がありそう。
例えばこんな感じにするとよいらしい。意外と設定コンソールから設定箇所を発見することができず、ctrl + shift + ,で開く settings.json のファイル修正が必要だった。当然ほしい設定項目だと思うけどな～。
{ "profiles": { "defaults": { // アクティブ（フォーカス中）の見た目 "background": "#0C0C0C", "foreground": "#CCCCCC", "opacity": 100, "useAcrylic": false, // 非アクティブ（フォーカス外）の見た目 "unfocusedAppearance": { "background": "#202020", "opacity": 85, "useAcrylic": false } } } }
Alt + Shift + + / - にペイン分割、Alt + <Arrow Keys>での移動がデフォルトキーバインドでは割り当てられているのだけど、これで分割ペイン環境で快適に生活ができます。
今 LG 45GX950A-B を使っていて、これは45インチウルトラワイド曲面ディスプレイなわけです。
曲面ディスプレイの正面に座ってふだんはパソコンカタカタしているのですが、最近めちゃくちゃ音が反射してるなということを感じるんですよね。
部屋の配置がこうなっていて、
真後ろのスピーカーからの音が完全に自分に向かって反射・集約されていることに気がつきました。
ビデオ会議のときに自分の声が明らかに画面に反射しているな、と思うことがあったんですが、音楽の反響が強く変化していることにはわかってなくて、ただなんとなくスピーカーの後ろの壁との距離を調整したりしながら、「残響が気になる...」と試行錯誤していました。犯人はお前か。大型テレビとか窓もルームアコースティックに影響でかいっていいますもんね。
アンプとスピーカーをデスクトップに配置すればいいような気もしますが微妙にサイズが合わないんですよね。ギギギ。あとニアフィールド過ぎではないかという気持ちがあり。
公式にドキュメントがある。PROMPT_COMMANDでエスケープシーケンスを発行して現在のディレクトリをターミナルに伝えるといいでしょうと。なるほど、それらしい。でも、動かない。なぜ。ギギギ...となっていた。
うんうんうなっていたのだけど、こちらのツイートにたどり着いた。
Windows Terminalでwslのタブを複製したときにカレントディレクトリも移動する設定がだめで困っていたが、２つあるプロファイルのうち、起動設定が「ubuntu.exe」となっているプロファイルはだめで、「C:\Windows\system32\wsl.exe -d Ubuntu」のほうはちゃんと動くらしいhttps://t.co/PDbPdNbe8J
— Atsuo Ishimoto (@atsuoishimoto) 2025年2月8日
起動設定が「ubuntu.exe」となっているプロファイルはだめで、「C:\Windows\system32\wsl.exe -d Ubuntu」のほうはちゃんと動くらしい
なんですって～
あんまり意識してなかったので実行バイナリどこにあるのかとみてみた。powershellは which ではなく where.exe なんですね。面白い。where が LINQの組み込みキーワードに吸われているのも面白い。
PS C:\WINDOWS\system32> where.exe wsl.exe C:\Windows\System32\wsl.exe C:\Users\takas\AppData\Local\Microsoft\WindowsApps\wsl.exe PS C:\WINDOWS\system32> where.exe ubuntu.exe C:\Users\takas\AppData\Local\Microsoft\WindowsApps\ubuntu.exe
WindowsApps/ 以下にある wsl.exe と System32/ 以下にあるやつが別物?
PS C:\WINDOWS\system32> C:\Windows\System32\wsl.exe --version WSL バージョン: 2.6.3.0 カーネル バージョン: 6.6.87.2-1 WSLg バージョン: 1.0.71 MSRDC バージョン: 1.2.6353 Direct3D バージョン: 1.611.1-81528511 DXCore バージョン: 10.0.26100.1-240331-1435.ge-release Windows バージョン: 10.0.26200.7623 PS C:\WINDOWS\system32> C:\Users\takas\AppData\Local\Microsoft\WindowsApps\wsl.exe --version WSL バージョン: 2.6.3.0 カーネル バージョン: 6.6.87.2-1 WSLg バージョン: 1.0.71 MSRDC バージョン: 1.2.6353 Direct3D バージョン: 1.611.1-81528511 DXCore バージョン: 10.0.26100.1-240331-1435.ge-release Windows バージョン: 10.0.26200.7623
いや別に違いはなさそうだ。実際、以下の設定にしたらうまくタブの引継ぎが期待通り動作しました。最高です。(新規タブ、というよりは duplicate tab と split pane のときですが問題ない) Windows Terminalはかなり出来が良いので、作業ディレクトリの引継ぎが機能するならほとんど不満はないです。
開始ディレクトリを指定しないと Windows 側のそれが引き継がれてしまうのが難点ではあります。でもまあ許容範囲かな。
そういえば、ちゃんとコンテキストメニューを表示するようにするオプションも生えてました。ただ、最初ぶうぶう言ってましたがここしばらくで慣れてしまったので、右クリックではコピー/ペーストに戻してしまいました。ターミナルでのマウス操作ってウインドウスクロールとコピーする以外にあんまりなかった。
「右クリックでメニューを表示する」があって安心。
ワークフローシステムの構成を考えてまして。
完了ノードが必要な上流ノードの処理をリクエストする構成が美しいんだけど、その形式だとワークフロー設計者の手続き的なイメージと乖離が生まれないか、と思うなどしていた。たとえば「10分待つ」というノードがあった場合。ただ、その10分待つノードの副作用が実行されるのは、そのノードの前工程の処理が終わってないと実行可能にならないので、つまり「10分待つ」ノードは自分自身を実行可能にするために上流に要求を出し、それが解決されたら thread.sleep() でもなんでもすればよい。と考えればすっきりするじゃん。はい。
async def task(inport1: Task, inport2: Task): (input1, input2) = await asyncio.gather(inport1,inport2)) return await process(input1, input2)
こういう素朴な形で表現が十分に可能ですね。はい。
で、こういう表現でまとめておくと、簡素な遅延評価スタイル関数型プログラミングの記法で記述できるのと、すでに十分に発達している型システムの推論評価ができて便利なのでは。
作っていたワークフローがエラー値の伝播と結果バリアントの表現どうしようかなって点について詳細を詰めていたら、いわゆるサーガパターンに収束しそうになってきて終了。
こういう「よくある」やつを作らせるとほんとにすぐ作ってくる。
作ってる最中の半分くらいは用語について悩んでいた。「だいたいこんな感じ」でやってると無限によくわからないものが出来上がってくる。
最近、画面作ってあれこれする仕事をしてないのでこのあたりの用語が思い出せずに、いろいろ「えーと、カーソルがあるあたりで、ドラッグしている最中だとマウスの近くに操作するためのアイコンが表示されてほしい」「左のワークフローをビジュアル表示しているエリアと、右側のJSON詳細表示のところの境界線についてマウスで操作可能であることをあらわすマークみたいなのを」などと冗長な説明をしており...。
で、いつも通り、というと変なんだけど、エラー系と繰り返し・分岐のような構成をどう表現するといいのか考え始めて詰まってしまう。Unityとか古くはQuartz Composerなどのビジュアルプログラミングのエディタはほんとに考え抜いて作られている感があるけど、それでも少し複雑なものをワークフローとして表現しようとすると人間の理解を阻む何かが生まれる感じがするのよね。
