#electron

2 件の記事

ERR_CONNECTION_CLOSED が出たときに、まず見分けたいこと
ERR_CONNECTION_CLOSED が出たときに、まず見分けたいこと
`ERR_CONNECTION_CLOSED` という文字列だけを見ると、ひとつの原因に見えてしまいます。ですが、今回の issue 群を見る限り、少なくとも二つの出方があります。 ひとつは、Cowork の macOS Desktop でチャット用の webview がネットワークを失って、そのまま戻らなくなるケースです。報告では、エージェント側の処理は続いているのに、画面側だけが壊れたままになり、送ったメッセージが灰色の「ghost bubble」として残るとされています。AskUserQuestion も描画されず、自動で拒否されたように見える、と書かれています。これは [#65382](https://github.com/anthropics/claude-code/issues/65382) の報告です。 もうひとつは、Windows の auto-updater で、Electron のネットワーク層だけが `ERR_CONNECTION_CLOSED` を返すケースです。報告では、`curl` と `node https.get()` では同じ更新先に届くのに、Elec
papoo.work
Swift化より、まず設計を疑ってしまう
Swift化より、まず設計を疑ってしまう
読んで最初に思ったのは、「それ、ほんとうに移植したいのはアプリなのか？」でした。Claude Code に今の Claude デスクトップアプリを Swift で“そのまま”作り直させる、という話は一見すごく攻めた実験に見える。でも、そこで問題にしているのが Electron かどうかだけなら、話はだいぶ浅い気がします。 記事を読んで引っかかったのはそこです。ネイティブ UI って、単に速くて軽いことではなくて、Mac の流儀に合わせていることでもあるはずです。たとえば AppKit や SwiftUI で包み直しても、画面の情報の置き方や操作の流れが雑なら、使い心地の悪さは残る。John Gruber が言う「しょぼいレシピを、より良い材料で作り直しても、まずいまま」という感覚はかなりしっくりきました。フレームワークの問題と、製品設計の問題を分けて見ないと、いくら AI に書かせてもあまり意味がないんですよね。 もうひとつ面白かったのは、「検証」が本体だという指摘です。大変そうな仕事を AI に投げるとき、どうやって途中で正しさを確かめさせるかが重要だ、という話はかなり実感があります
papoo.work