test

2025年11月23日日曜日

htmlの入力フォームにリアルタイム検索とFEP（フロントエンドプロセッサ）の挙動

htmlの入力フォームにリアルタイム検索とFEP（フロントエンドプロセッサ）の挙動。

https://youtu.be/NYJgymLON2Q?t=840

確かに昔はよく合った問題だが、最近は何も考えずに実装できてるよな・・・

俺の組んでいるsvelteで入力フォームでのFEP(IME等)の挙動が正常なので、実装を確認した。

「入力中（IME未確定状態）なのに、バックグラウンドで検索が走り、かつIME入力も邪魔されない」という点ですね。

これは以下の3つの要素が組み合わさって実現されています。

1. 入力を即座に検知する bind:value

Svelteの bind:value={query} は、ブラウザの input イベントを監視しています。

現代のブラウザでは、IMEで文字を打っている最中（未確定の「やま」の状態）でも input イベントが発生し、その内容がリアルタイムで変数 query に反映されます。

これにより、変換キーを押す前の「ひらがな」の状態で検索を開始できます。

2. 0.25秒の「待機時間」 (Debounce)

これがIME入力をスムーズにしている最大の要因です。

文字が入力されるたびに即座にAPIを叩くと、処理が重くなり入力がカクつく原因になりますが、この実装では「入力が止まってから0.25秒後に検索する」という制御（Debounce）が入っています。

「やま」と素早く打っている間は検索が走らず、打ち終わって一瞬手が止まったタイミングで検索が走るため、IMEの入力を邪魔しません。

3. 入力欄を「書き換えない」

検索結果（suggestions）が返ってきたとき、このプログラムは入力欄（query）の中身を一切いじりません。

単に候補リスト（ドロップダウン）を表示するだけです。

もしここでプログラムが「検索結果に合わせて入力欄の文字を補完する」ような動きをすると、IMEの未確定文字が確定されてしまったり消えたりしますが、「入力欄はユーザーに任せて、結果は下に表示するだけ」という実装になっているため、IME変換を継続したまま検索結果を見ることができます。

まとめ

Svelteの機能: 未確定の文字もリアルタイムで変数に取り込む。

Debounce: 入力中は検索を我慢し、手が止まったら裏でこっそり検索に行く。

表示の分離: 検索結果が出ても入力欄には触らないので、IMEが途切れない。

この組み合わせにより、「入力しながら（変換しながら）検索結果が出る」という体験になっています。

2025年11月22日土曜日

gemini3.0Proが、Claude4.5と比べると頭悪い

リリース直後から数日、同じような作業をgemini3.0proで行った・・・

gemini3.0Proが、Claude4.5と比べると頭悪い。

プログラムでちょっと難しい条件だと、間違った回答を頻発する。

これはcursorがよくない可能性もあるが、

（Windsurfでgemini 3proでも先に別場所の実装を確認しているように見えた、cognition aiの新開発の高速grepが効いてるっぽい）

同じ条件でclaude4.5 thinkingだと起きていないような気がする。

自分の体感で実際に計ってないので、正確性に欠けるが・・・メモとして残しておく。

2025年11月20日木曜日

cloudflare workersの実行時間制限

Cloudflare Workers の無料版と有料版における 実行時間（CPU 時間／壁時計時間） の主な制限は以下の通りです：

✅ 主な制限

無料プラン（Free）では「CPU 時間」が 10 ms／リクエスト が目安となっています。 Qiita+3Zenn+3Cloudflare Docs+3
- この「CPU 時間」というのは、実際にスクリプトが CPU を使って処理している時間であり、外部への fetch／待機時間などはカウントされません。 Stack Overflow+2Cloudflare Docs+2
有料（Paid／Standard）プランでは、CPU 時間をユーザーが設定でき、最大で 5 分（300,000 ms）／リクエスト まで設定可能というアップデートが行われています。 Cloudflare Docs+2Cloudflare Docs+2
壁時計時間（real-time／wall time。待機も含む）は、明確な厳しい上限がない場合が多く、「クライアントが接続を保っている間」は実行継続できるという記述があります。 Cloudflare Docs+1

⚠️ 注意すべきポイント

無料プランの「10 ms」というのは目安であって、必ずピッタリ 10 ms で打ち切りというわけではありません。ただし、常時これを大きく超えるような処理を実装すると、リクエストが失敗する・スクリプトが終了される可能性があります。 Answer Overflow+1
「CPU 時間」が 10 ms を超えても、処理の大半が外部呼び出し・待機であれば、無料プランでも実用に耐えるケースがあります。外部 API 呼び出し中は CPU を使っていないため、カウントされないためです。 Zenn+1
有料プランで “最大 5 分” というのも「CPU 時間」であって、壁時計時間での待機（たとえば外部 fetch を待つ時間）が含まれない点に留意です。 Cloudflare Docs

🎯 実際にどちらを使うべきか

簡単なエッジ処理、ヘッダー操作、認証チェック程度の軽量な処理なら 無料プランでも十分可能です。
ただし、画像処理・暗号化・大きな JSON の変換・D1/R2 を用いたデータ操作など「CPU を使う処理」がある場合は、 有料プラン を検討すべきです。
また、レスポンスに対して長時間待ちが発生する（例：長い API チェーン・大きなデータの読み込み）ようなら、有料プランで CPU 時間の上限を広げるか、別設計（バッチ処理・キュー処理）を検討した方が安全です。

✅ 最新の制限（2025 年時点）

Cloudflare Workers の公式ドキュメントによれば、**CPU 時間（CPU time）**とは「実際に CPU が処理をしている時間」であり、外部フェッチ／I/O 待ち時間などはカウントされない、という定義が明記されています。 Cloudflare Docs+1
同ページでは、デフォルトの CPU 時間上限が 30 秒（30,000 ms） で、設定を変更することで最大 5 分（300,000 ms） に拡張できると記載されています。 Cloudflare Docs+1
無料プラン（Free）について、10 ms 程度という言及が複数の非公式記事にあります：
- StackOverflow 解答： “A Worker may consume up to 10 ms on the free plan…” Stack Overflow
- Zenn 記事：「無料枠だと CPU 実行時間が10 msという制限があり…」 Qiita+1
- Publickey というまとめ記事でも「1リクエストあたり10ミリ秒までの CPU タイム」と紹介されています。 Publickey
有料プラン（Standard やそれに相当するプラン）で「最大 5 分まで CPU 時間を設定可能」と公式にアップデートされています。 Cloudflare Docs

⚠️ 注意すべきポイント・補足

「10 ms まで」は 保証された上限値 ではなく、無料プランでは「目安／推奨／典型的な範囲」であるという記述もあります。たとえば、「10 ms を超えると即失敗」という明確な記載ではなく、「10 ms 程度が普通だが超えると挙動が保障されない可能性あり」というものです。 koryporter.com+1
無料プランで 10 ms を超えても実際に動いている事例も報告されており、「10 ms 超＝必ずエラー」というわけではありません。 Qiita+1
また、「壁時計時間（wall-time／実際の経過時間）」については、CPU 時間制限とは別に「クライアント接続が続いている限り実行可能」という記述もあります。つまり I/O 待ちが多いような処理では「実経過時間」は長くなりうるということです。 Stack Overflow+1
プランや契約内容・リージョン・発展状況によって制限値が変わる可能性があります。公式ドキュメントで最新確認することが推奨されます。
「無料プランでも CPU 時間をユーザー設定できる」「5 分まで拡張できる」というのは有料プラン対象、かつ設定変更 (wrangler など) が必要という条件付きです。無料プランではこの拡張ができないケースが多いです。