Forem: Kenji Suzuki

Restoring files with git

Kenji Suzuki — Thu, 20 Nov 2025 00:43:34 +0000

git restore --source=main -- path/to/fileA.js

Rebase and Always Take the Upstream Version

Kenji Suzuki — Wed, 19 Nov 2025 02:43:47 +0000

git rebase main
git checkout --theirs {path}
git add .
git rebase --continue

Error checking for GCE startup scripts

Kenji Suzuki — Sun, 26 Oct 2025 01:58:08 +0000

sudo journalctl -u google-startup-scripts.service --no-pager

Cloudflare WorkersのレスポンスをCDNにキャッシュさせたかったが、WorkersがCDNそのものだった

Kenji Suzuki — Sun, 14 Sep 2025 07:41:16 +0000

https://github.com/announcing-app/announcing ではimmutableなレスポンスを返すように意識して設計している
https://blog.katsubemakito.net/firebase/cloudfunctions-cdn-cache
上記のイメージでWorkersのレスポンスをCDNにキャッシュさせて、Workersの実行回数を減らしたい

export default {
  fetch() {
    const data = { message: 'Hello at ' + new Date().toISOString() };
    const res = new Response(JSON.stringify(data), {
      headers: {
        'content-type': 'application/json',
        'Cache-Control': 'public, s-maxage=86400, immutable',
      },
    });
    return res;
  },
};

上記のようなコードを書いてもキャッシュされない(毎回日付が変わる)
- AIに聞いてもとりあえずこういうコードを書いてくる
WorkersはCDNの後にぶら下がっているのではなく、CDN(Edge)そのものの上で動いている模様
https://developers.cloudflare.com/workers/reference/how-workers-works/
このページをちゃんと理解できてなかった
試しにカスタムドメインのDNSにCNAMEで~~~~.workers.devを設定したら、すぐエラー(Connection timed out(522))が返ってきたので、やはりoriginのように扱うのは無理そう
Workers内でCache APIを使うのが正解の模様
- https://developers.cloudflare.com/workers/runtime-apis/cache/
Cache APIにより、キャッシュ無効化は管理しやすくなる
Workersのリクエスト回数をケチろうとしてはいけない
- (それでも十分安いとは思うが)
実行コードを軽量にすることを努力する
- メモリ128MBのIsolatesはそれなりにシビアに考えたほうがよさそう

生成AI時代のベテランと若手

Kenji Suzuki — Sun, 14 Sep 2025 02:45:16 +0000

https://hibis.connpass.com/event/361994/ のイベントを聞いてきた
当たり前のことを当たり前にやることが大事というアタリマエのことを確認できた
- ドキュメントの整備
- コードレビューは必須
- 段階的な対話 etc

その中で「若手が臆せずチャレンジできるようになった」という話が印象に残った

「ベテラン」と「若手」とは

実現することに対して以下のような人で年齢ではない

ベテラン -> なにが必要かイメージできる(あれやって、これ調べて、たぶんこのへんでつまづいて...など)
若手 -> イメージできない部分が多い

それぞれの効果

AIエージェントの恩恵が大きいのは若手
- 手軽な相談相手
- 総合的な能力はAIエージェントのほうが上
ベテランは調べるタスクは楽になった
ただしベテランは生産性についてはAIエージェントがうまく働かなかったときの手戻りで相殺されやすい
- 元々ストレートにゴールに向かえるため

どうするか

若手はAIエージェントの助けを借りてひたすら成果物を作る
ベテランはひたすらそれをレビューする
若手はベテランから正解を学び、ベテランは若手からAIエージェントのノウハウを学ぶ(共に創る)

というサイクルができれば理想的だろうか

これまでは若手を育てるのにロープで引きずり上げたり、下から押し上げたり、またはずっとそばにいるよ的な労力のかかる方法が多かったが、AIエージェントがちょうどいい階段になってくれそう

Cloudflare workersのリバースプロキシ

Kenji Suzuki — Sat, 13 Sep 2025 07:23:15 +0000

workersのキャッシュを調べていて以下のようなサンプルがあってパニックになった。

export default {
  async fetch(request: Request) {
     return fetch(request)
  },
}

これだとループするだけに見える。
プロキシ関連なのでrequestにoriginのURLが入ってくるなにかがあるのかと思ったが少し違った。

workers.mydomain.com
workers.myorigin.com

というようなドメインがあり、mydomain.comのCloudflareのDNSレコード設定で、workers CNAME workers.myorigin.comというような設定をして、proxiedをONにすると、workers.mydomain.comがworkers.myorigin.comのリバースプロキシとなる。
さらにWorkers Routesの設定でworkers.mydomain.comにworkersを紐づけると、workers.mydomain.comのアクセス時にそのworkersが実行される。
workers内でworkers.mydomain.comをfetchすると、CNAMEのworkers.myorigin.comへのリクエストになる、という仕組みだった。

dev.toにインポート

Kenji Suzuki — Wed, 20 Aug 2025 08:05:54 +0000

雑多なメモの記録にdev.toを使うことにした
- 短文でもよさそう
- テック系以外も大丈夫そう
過去の投稿日にすることはできないようなので、本文に日付を入れた
とりあえず地道に投稿してたがlimitに引っかかるようになったので、バッチでimportしたくなった
devto-cliを試したが使いづらかった
自前で用意することにした
- https://github.com/suzulabo/devto-posts
- ChatGPTの出力を手直し
5秒のインターバル開けても3投稿くらいでFailed to post article: 429 Too Many Requestsのエラーになった
60秒開けたら最後までできた
今後は普通にWebコンソールから入力する

SentryのUptime Monitoring

Kenji Suzuki — Wed, 20 Aug 2025 07:51:36 +0000

2025-08-17

最初の一個が勝手に追加されて 1m 毎にリクエストが飛んでくる
Issues->Alertsから設定できる

FCMの404メッセージ

Kenji Suzuki — Wed, 20 Aug 2025 07:50:36 +0000

2025-08-08

{
  error: {
    code: 404,
    message: 'Requested entity was not found.',
    status: 'NOT_FOUND',
    details: [
      {
        '@type': 'type.googleapis.com/google.firebase.fcm.v1.FcmError',
        errorCode: 'UNREGISTERED'
      }
    ]
  }
}

sveltekit - snapshotのrestoreのdataが`{}`

Kenji Suzuki — Wed, 20 Aug 2025 07:49:35 +0000

2025-08-06

VirtualScrollList で発生
条件で生成されたり、しなかったりすると発生するのかも
要検証

+layout.tsと+error.svelte

Kenji Suzuki — Wed, 20 Aug 2025 07:48:34 +0000

2025-08-03

+layout.ts の error は上位の+error.svelte に流れる
同じ階層の+error.svelte を使うには+page.ts から error する必要がある

cloudflare workersのdeployでエラー

Kenji Suzuki — Wed, 20 Aug 2025 07:47:34 +0000

2025-07-16

packages/reader deploy:  ⛅️ wrangler 4.22.0 (update available 4.24.3)
packages/reader deploy: ─────────────────────────────────────────────
packages/writer deploy:  ⛅️ wrangler 4.22.0 (update available 4.24.3)
packages/writer deploy: ─────────────────────────────────────────────
packages/writer deploy: ✘ [ERROR] Build failed with 1 error:
packages/writer deploy:   ✘ [ERROR] Could not resolve "minimatch"
packages/writer deploy:
packages/writer deploy:       .svelte-kit/output/server/chunks/hooks.server.js:22328:34:
packages/writer deploy:         22328 │             globMatcher = require("minimatch").minimatch;
packages/writer deploy:               ╵                                   ~~~~~~~~~~~
packages/writer deploy:
packages/writer deploy:     You can mark the path "minimatch" as external to exclude it from the bundle, which will remove this error and leave the unresolved path in the bundle. You can also surround this "require" call with a try/catch block to handle this failure at run-time instead of bundle-time.

https://github.com/getsentry/sentry-javascript/issues/16613
sveltekit のアップデートで治る模様
catalog:を使ったバージョンアップの挙動が意味不明
pnpm-workspace.yaml をアップデートしても monorepo に反映されない
writer で outdated すると反映されているが、reader で outdated すると反映されてない
reader で update すると reader の outdated で反映されているが、writer が戻るというよくわからない状況が発生
pnpm update -r @sentry/sveltekit @sveltejs/kit --latestという感じでアップデートするのがよさそう