hogashi.*

日記から何から

ドラッグアンドドロップ中のDOMの様子をdevtoolsで見たいときsetTimeoutでdebuggerを発動すると便利

 devtools を使うと、 HTML 中の要素の並びやスタイルを調べたり、その場で変更してみたりできる。しかし、ドラッグ中の要素のスタイルをいじりたい、となると、 devtools を開いているだけでは難しい場合がある。その状態で devtools をある程度操作しないといけないが、マウスカーソルをそっちに持っていくと見たい状態ではなくなってしまう、という困り方。

 簡単な例として、ドラッグアンドドロップで順序を変えられるリストに、ドラッグ中だけ色を反転するスタイルを当ててある。

ドラッグして順序を入れ替え
  • 一味唐辛子
  • 二子玉川
  • 和三盆

 動画(GIF)で貼っておくとこういう感じ。今回だと、ドラッグ中だけ .sortable-chosen という class 名が当たるので、ドラッグアンドドロップをやめると該当のスタイルを devtools でいじることができない。

ドラッグ中だけclass名が当たるため、ドラッグアンドドロップをやめるとスタイルをいじれない様子

 そういうときは setTimeout で自動で debugger を発動させると便利。 debugger - JavaScript | MDN
 Console タブで以下のように setTimeout を 2秒後とかに設定して実行しておき、画面内にマウスカーソルを持っていってデバッグしたい状態にしてキープする。 2秒たったら debugger が発動して画面がその状態で止まるので、 devtools を好きに操作できる。

setTimeout(() => { debugger; }, 2000);
2秒後に自動でdebuggerを発動させることで、ドラッグ中で停止してスタイルをいじれる様子

 これは必ずしも setTimeout じゃなくてもよくて、クリックを起点に element.addEventListener('click', () => { debugger; }) とかしてもいい。操作の中のどこで停止させたいか、に沿って、使いやすい方法で debugger を発動させると便利です。
 当たり前だけど、ソースコード中に debugger 文を書くと、最も狙ったタイミングで発動させられると思う。今回書いたのは、その場でちょっと見たいときや、ソースコードのどこでこうなっているかわからないときなど、ブラウザ上から発動したほうが楽なときに使いやすい方法でした。

Claude Codeと人間で行ったり来たりを通知じゃなく音楽でやるツールつくった

 agent-b2b というグッズをつくった。 Claude Code と人間が行ったりきたりするときに、 cmux で通知を受けるとかのかわりに、鳴ってる音楽が変わることで気づける back to back みたいなことができたらいいかもと思い、 Claude Code でつくった。今回エディタを開いていない。 GitHub - hogashi/agent-b2b: back to back between human and agent · GitHub

agent-b2b の操作盤

 README に貼ってるデモ動画はこんな感じ。音が鳴るので注意。 Claude Code が考え中はメロディがあり、人間待ちになるとキックとベースだけになる、とかができる。どれ流すかは設定できる。

youtu.be

 npx agent-b2b すると、 localhost で Web サーバが立つ。ブラウザでアクセスすると音を鳴らすページが開き、 Claude Code の hook を設定しておくと、状態が変わったときに POST されて WebSocket を経由して音楽が変化する。
 チェックをつけ外ししたり、シーケンサをいじったりして遊びつつ、 Claude Code とのコーディングを楽しんでみてください。

 通知がきて呼び戻されるよりは自然にストレスなく戻れるのではないかみたいな仮説があるけど、本当にそうかは不明。あと、この短さのループでこの素朴さでは飽きるので、もっとちゃんと音楽でやれるようにしてみたい。誰か fork などして拡張してくれ!!

 ちなみにシーケンサ自体で遊ぶのが普通に楽しいので、 GitHub Pages にデプロイしておいた AGENT-B2B - Back-to-back beats with your AI agent 。触ってみてください。お気に入りの設定ができたら、 export して保存したり人にあげたりしてみてください。

OSSあたたか日記

 あたたかい開発者の方からの細やかな気遣いに嬉しすぎて涙している。小さな小さな OSS でも、こういうあたたかさを支えに生きていくものだなと思う……。

github.com

 文脈の説明:

  • hogashi は VSCode 拡張機能として、 Git 管理されたコードベースのファイルを開いたときのカーソル位置に当たる場所を GitHub で開くためのパーマリンクをクリップボードにゲットできる、というグッズをつくっている
    • hogashi/repo1 の README.md の 3行目を開いてたら https://github.com/hogashi/repo1/blob/deadbeef.../README.md#L3 がコピーされるみたいなこと
  • これのつくりとして git remote を参照するように丁寧に作ったところ、偶然 GitLab 管理な repo でも動作していたらしい
    • hogashi は知らなかった
  • 件の方が GitLab でも (オンプレ版でも) 使えて便利なので、それを README に書かないか? と issue/pull req をくれた
    • Web サービス GitLab のほうはまだしも、オンプレ版 GitLab は手元で試せる環境ないから、あんまりちゃんとサポートできないかも、と伝えたところ、↑のような情報をくれて、ありがてえな……という状態

仕事でコーディングAIに褒められたくないのでやめてと伝えて個人用メモリに書いてもらった

 仕事でコーディングAIを使っていると、こういうほうがよくない? みたいな指摘をしたとき、良い視点ですね、とか言ってくる。これが嫌だなと思う。良いなら最初から出してくれよ、という気持ちなんだと思うから、 AI の未熟であり人間の傲慢だろう。しかし嫌。気持ちを大事にすることも大事。

 普段使っている Claude Code に直接やめてほしいと伝えると、個人用のメモリに覚えておいてくれるらしい。そうしてみた。 Claude Code 自身もお世辞と表現しているが、僕の感覚としてはそこに違和感はない、お世辞だと思う。

❯ claude codeを使っているとき、指摘などすると「良い指摘ですね」とか「鋭い観点です」とかユーザを褒めるようなことを言うことがある。これをやめるようにできないか?

⏺ はい、これは CLAUDE.md やメモリに指示を追加することで対処できます。

いくつか方法があります:

1. プロジェクトの CLAUDE.md に追加 — チーム全体に適用される
2. 個人のメモリファイルに追加 — あなたの環境だけに適用される

個人の好みなので、メモリファイルに追加するのが適切だと思います。追加してよいですか?

内容としては以下のような指示になります:

- ユーザーを褒めない(「良い指摘ですね」「鋭い観点です」など)。指摘や質問にはそのまま対応する。

⏺ User answered Claude's questions:
⎿  · どこに設定を追加しますか? → 個人メモリ

⏺ 個人メモリに追加します。

⏺ Recalled 1 memory, wrote 1 memory (ctrl+o to expand)

⏺ 追加しました。次回以降のセッションでも、指摘や質問に対してお世辞を言わずに直接本題に入るようになります。

 これで試そうとしたら、個人用のプロジェクトごとの設定になっていたらしくて難しい。いつでも褒めてほしくないから、常に機能する設定に移してと伝えて直してもらった。先進的な技術に置いていかれているような気持ちになるこの瞬間のことを、いつも物悲しく思っては、先が思いやられる。


 日々すべての暮らしにおいて、褒めてほしい場面とそうでない場面があるはずで、日常会話をしたいと思ったときに、いい感性じゃんとか言ってもらえるのは嬉しいことがあるかもしれない。少なくとも仕事の上ではそういうのを廃してほしかった。
 あと当然人間同士のコミュニケーションでは、お互い考慮できていないことが存在しうることがわかっているし、気遣いをすることの楽しさがあるので、褒めるのも褒められるのも好き。この差には色々な成分が含まれていて、考えるとたくさん出てくる。そういうのを再認識するきっかけにはなっている。

Perlでmap/grep/sortのブロック内でミスってreturnしてたら怒るPerl::Critic::Policy公開した

 Perl::Critic::Policy::ControlStructures::ProhibitReturnInMappingBlock - Do not "return" in mapping blocks (map, grep, sort) - metacpan.org を公開した。 map/grep/sort のブロック内でミスって return を書いてしまうと、外側の sub を抜けてしまって困るので、そういうの書いてたら怒ってくれるやつ。

 やったことは単純で、先人 id:utgwkk 作の、 do 内で return してるのを怒ってくれる Perl::Critic::Policy::ControlStructures::ProhibitReturnInDoBlock - Do not "return" in "do" block - metacpan.org を fork し、 do のところを map/grep/sort で動くようにしただけ。 utgw さんの当時の記事はこれ perlcriticのポリシー書いた - 私が歌川です 。サードパーティ Perl::Critic::Policy つくるの、お手軽でかなりいいなと思った *1

 ブロックを取るものが網羅できているか Claude Code に聞くと、 map/grep/sort は対象としつつ、 if/for/while などは対象外とすべきだろうと言われて面白かった。 if などは普段意識してなかったけどたしかにブロックで、かつ return は (外側の sub を抜けるために) 意図的に使う。それらの違いは「写像と走査」であろうという鋭い指摘を id:onk からもらったので、モジュールの命名も MappingBlock としている。

*1:持ってなかったのでこれを機に PAUSE のアカウントもつくった