ハクソク

世界を動かす技術を、日本語で。

忙しい開発者のための呪術

2025年7月22日原文(maddie.wtf)

概要

Anubis はウェブサイトをAIによる スクレイピング から守るための Proof-of-Work 方式の保護システム。 個人利用には影響が少なく、大量アクセス時に負荷をかける設計。 Hashcash に着想を得た仕組みで、メールスパム防止技術を応用。 将来的には ヘッドレスブラウザ の識別強化を目指す。 特定の JavaScriptプラグイン が動作を妨げる場合がある点に注意。

Anubisによるウェブサイト保護の仕組み

  • Anubis はサーバーをAI企業による 過剰なスクレイピング から保護するために導入
  • 一般ユーザーには Proof-of-Work 課題を課すことで、アクセスを制限
  • Hashcash 方式を参考にした設計で、個人利用時の負荷は最小限
  • 大量スクレイピング時には 計算負荷 が蓄積し、コスト増加
  • 一時的な ダウンタイム やリソースの不可用性の防止策

今後の開発方針と注意点

  • 現状は 暫定的な対策 としてProof-of-Workページを表示
  • 将来的には フォントレンダリング等の特徴 でヘッドレスブラウザの識別強化を計画
  • 正規ユーザーにはProof-of-Work課題を省略できるよう改善予定
  • JShelter などの一部JavaScriptプラグインがAnubisの動作を妨げる場合あり
  • 不具合時は該当プラグインの 一時無効化 を推奨

Anubisのバージョン情報

  • 現在の Anubis バージョン： v1.20.0

Hackerたちの意見

チームをジュジュツに移行しようと頑張ってるんだけど、なかなかうまくいかないんだ。やっぱり、gitの一般的だけど複雑な操作をわかりやすく示したページがあればいいなと思ってる。ここでのエレベーターピッチみたいな感じで、スティーブのチュートリアルほど深くなくていいから、もう少し詳しく説明してほしい。もしかしたら、デモをやってみて、みんなに見てもらって質問してもらうのがいいのかもしれないね。

└

gitはあんまり好きじゃないんだよね。ずっとmercurialを使ってたし。でもそれは10年前の話。今じゃgitが頭に染みついちゃってる。全体的にはまあまあうまくいってるけど、Jujutsuが本当に時間をかける価値があるほどのメリットを提供してるかはよくわからない。初期設定の面倒くささ（例えば、見にくい色とか、自分好みのスクリプトやエイリアスを設定すること）を考えると、余計にね。

└

操作のリストは多くないけど、jjとgitの一般的な操作の比較が、私にはピンときたんだ。 https://lottia.net/notes/0013-git-jujutsu-miniature.html

└

いいアイデアだと思うのは、gitの一般的だけど複雑な操作をちゃんと見せて、jujutsuではどれだけ簡単になるかを示すページだね。実際、一般的なgitの操作がjujutsuで簡単になるわけじゃない。時にはgitのバックエンドとの不整合のせいで、ちょっと難しくなることもある。むしろ、gitではほぼ不可能、もしくは非常に不便な操作をjujutsuでは簡単にできるんだ。だから、あまり誰もやらないことになる。これを説明するのが難しいのは、みんなが「そんな新しいワークフローがあるよ」って言っても、彼らは「必要ない」と思ってるから（代替手段があるし）、プログラミングが得意な人にはその考えが嫌悪感を引き起こすんだよね。

└

これがあなたが探しているかもしれない素晴らしいリンクだよ https://v5.chriskrycho.com/essays/jj-init/ https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj... https://ofcr.se/jujutsu-merge-workflow

└

次の部分、きっと気に入ると思うよ！別に投稿されると思うけど、ここにリンクしてあるページの下の方にも載るはず（早ければ数日以内にね）。

自分がちょっと鈍いなって感じるのは、自動的に変更をリビジョンに追加することがまだうまく理解できてないから。開発中に使うファイルをローカルで変更することがあるんだけど、その変更をコミットするつもりは全然ないんだ。普通のgitでは、そのファイルをステージしないから、リモートリポジトリに誤って変更をプッシュする心配はないんだけど、jjではその変更をどうにかしてアンステージしないといけないみたい。習慣の問題かもしれないけど、すべてをデフォルトでコミットするんじゃなくて、自分がコミットしたいものを明示的に言いたいんだ。もしかして、jjを完全に誤解してるのかな？

└

このワークフローが欲しいなら、jjの@（gitのHEADに相当）をgitのインデックスとして扱って、コミット時に手動で@-に変更をまとめるといいよ。git add --patchと同じ感じでね。

└

それは正しいよ、そしてそれをやめようとしてる習慣でもある。合理的な考え方は、追跡されていない状態でコードを実行するのはやめるべきだってこと。変更が重要ならコミットすべきだし、そうじゃなければコミットしない方がいい。そうしないと、開発中に実際には存在しなかったコードのバージョンを記録することになるからね。これが特に厄介なのは、リポジトリ全体の設定とローカル専用のバージョンを区別しないツールがあるから。VSCodeは大きな問題で、‘launch.json’しかなくて、ホストごとのカスタマイズに適した‘launch.local.json’がないんだ（例えば、ポート8888で何かをすでに実行しているから9000にマッピングする必要があるってこと。だから、環境の quirks をコミットするべきじゃないよね）。

└

jjでは、変更を分けるためにjj splitを使うことが多いよ。選択した部分が最初のリビジョンになって、残りの部分が2番目のリビジョンになるんだ。たくさん作業してから、小さくて扱いやすいリビジョンに分けることが多い。もし独立した作業のスレッド（例えば、他の場所のバグ修正やドキュメントの修正）なら、並行リビジョン（別のブランチ）に分けることもある。jjでは明らかにワンライナーだけど、gitでは面倒なブランチ切り替えやスタッシングが必要になる。git addスタイルのワークフローも使えるよ。jj newで新しいリビジョンを作成して、もう一度やって、変更を加えたら、jj squash -i/--interactiveで含めたい部分を選ぶんだ。変更を続けて、満足するまで前のコミットにまとめていけばいい。概念的には、@（現在のリビジョン）と@-（前のリビジョン）をそれぞれ作業コピーとステージされたコピーとして考えてみて。

└

普段は作業してから、jj splitでコミットしたい変更をレビューするんだ。これでワークフローはgit add -pみたいに見えるよ。良いメンタルモデルは、最上部のコミットはどこにもプッシュされないことが多いってこと。作業コピーみたいなもので、スタッシングも「無料」でできる（新しいコミットを作るためにメインに戻る？すべてのWIPはそのブランチに残るから、メインに持ち越されない！）。

└

jjの自動ステージングは、必ずしも望ましいわけじゃないね。jjのドキュメントや宣伝者たちは、デフォルトで簡単にオフにできるってことをもっと明確にすべきだと思う。これを~/.jjconfigに追加すればいいんだ：[snapshot] auto-track = "none()"

Hacker Newsで議論の続きを見る