<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>chicchi.work Articles</title>
    <link>https://chicchi.work/articles/</link>
    <description>ちっちの技術記事。</description>
    <language>ja</language>
    <item>
      <title>GitHub ActionsのMavenビルドを速くする：setup-javaのcacheを正しく使う</title>
      <link>https://chicchi.work/articles/2026-09-19-github-actions-maven-cache/</link>
      <guid isPermaLink="true">https://chicchi.work/articles/2026-09-19-github-actions-maven-cache/</guid>
      <pubDate>Fri, 18 Sep 2026 15:00:00 GMT</pubDate>
      <description>JavaプロジェクトのCIで、毎回Mavenの依存ライブラリをダウンロードしていませんか。 GitHub-hosted runnerはジョブごとに基本的に新しい環境から始まるため、何もしなければMavenが依存関係を再取得する時間が発生します。GitHub Actionsでは `actions/setup-j</description>
    </item>
    <item>
      <title>RedisのTTLとEvictionを混同しない：Spring Bootのキャッシュ設計でハマるポイント</title>
      <link>https://chicchi.work/articles/2026-09-18-redis-cache-ttl-eviction/</link>
      <guid isPermaLink="true">https://chicchi.work/articles/2026-09-18-redis-cache-ttl-eviction/</guid>
      <pubDate>Thu, 17 Sep 2026 15:00:00 GMT</pubDate>
      <description>Redisをキャッシュとして使い始めると、よく出てくるのが次の2つです。 - TTL（Time To Live） - Eviction（メモリ不足時のキー追い出し） どちらも「Redisからキーが消える」ため混同しやすいのですが、発動する条件はまったく違います。 この記事では、Spring Boot + Re</description>
    </item>
    <item>
      <title>EventBridge Schedulerの失敗を取りこぼさない：Retry PolicyとDLQを実務目線で整理する</title>
      <link>https://chicchi.work/articles/2026-09-17-eventbridge-scheduler-retry-dlq/</link>
      <guid isPermaLink="true">https://chicchi.work/articles/2026-09-17-eventbridge-scheduler-retry-dlq/</guid>
      <pubDate>Wed, 16 Sep 2026 15:00:00 GMT</pubDate>
      <description>定期バッチを Amazon EventBridge Scheduler から Lambda や ECS に投げていると、最初は「指定時刻に起動できればOK」と考えがちです。 しかし本番運用では、次の問題を考える必要があります。 - 一時的な障害でターゲットを呼び出せなかったらどうするか - 何回まで再試行する</description>
    </item>
    <item>
      <title>PostgreSQLのEXPLAIN ANALYZE入門：インデックスが効かない理由を実行計画から読む</title>
      <link>https://chicchi.work/articles/2026-09-16-postgresql-explain-analyze-indexes/</link>
      <guid isPermaLink="true">https://chicchi.work/articles/2026-09-16-postgresql-explain-analyze-indexes/</guid>
      <pubDate>Tue, 15 Sep 2026 15:00:00 GMT</pubDate>
      <description>SQLが遅いとき、いきなりインデックスを追加していませんか。 PostgreSQLでは、まず `EXPLAIN` / `EXPLAIN ANALYZE` で「PostgreSQLがそのSQLをどう実行しようとしているか」を確認するのが基本です。 この記事では、実行計画の読み方を初心者向けに整理しつつ、インデッ</description>
    </item>
    <item>
      <title>Springの@Transactionalでハマる4つの罠：自己呼び出し・例外・REQUIRES_NEWを整理する</title>
      <link>https://chicchi.work/articles/2026-09-15-spring-transactional-pitfalls/</link>
      <guid isPermaLink="true">https://chicchi.work/articles/2026-09-15-spring-transactional-pitfalls/</guid>
      <pubDate>Mon, 14 Sep 2026 15:00:00 GMT</pubDate>
      <description>Spring BootでDB更新を書くとき、`@Transactional` を付ければ「失敗したら全部ロールバックされる」と考えがちです。 ただし、Springのトランザクションにはいくつか重要なルールがあります。知らずに使うと、`@Transactional` を付けたのに効いていない、例外が出たのにコミ</description>
    </item>
    <item>
      <title>Lambda × SQSで1件の失敗に全件巻き込まれない：ReportBatchItemFailuresをJavaで実装する</title>
      <link>https://chicchi.work/articles/2026-09-14-lambda-sqs-partial-batch-response/</link>
      <guid isPermaLink="true">https://chicchi.work/articles/2026-09-14-lambda-sqs-partial-batch-response/</guid>
      <pubDate>Sun, 13 Sep 2026 15:00:00 GMT</pubDate>
      <description>Amazon SQSをAWS Lambdaのイベントソースにすると、Lambdaはメッセージを**1件ずつではなくバッチ**で受け取ります。 ここで意外とハマりやすいのが、10件中9件の処理に成功していても、1件の失敗でLambda関数全体を例外終了させると、**デフォルトではバッチ全体が再試行対象になる**</description>
    </item>
    <item>
      <title>Next.js 16のupdateTagとrevalidateTag、結局どう使い分ける？</title>
      <link>https://chicchi.work/articles/2026-09-13-nextjs-update-tag-vs-revalidate-tag/</link>
      <guid isPermaLink="true">https://chicchi.work/articles/2026-09-13-nextjs-update-tag-vs-revalidate-tag/</guid>
      <pubDate>Sat, 12 Sep 2026 15:00:00 GMT</pubDate>
      <description>Next.jsのApp Routerでデータ更新後にキャッシュを無効化しようとすると、`updateTag` と `revalidateTag` のどちらを使うべきか迷いやすいです。 特にNext.js 16ではキャッシュAPIが整理され、`updateTag()` が追加される一方、`revalidateT</description>
    </item>
    <item>
      <title>DynamoDBで『更新したのに古い値が返る』を理解する：結果整合性と強い整合性の使い分け</title>
      <link>https://chicchi.work/articles/2026-09-12-dynamodb-read-consistency/</link>
      <guid isPermaLink="true">https://chicchi.work/articles/2026-09-12-dynamodb-read-consistency/</guid>
      <pubDate>Fri, 11 Sep 2026 15:00:00 GMT</pubDate>
      <description>DynamoDBを使っていると、次のような現象に遭遇することがあります。 &gt; `UpdateItem` は成功したのに、直後に読み直したら古い値が返ってきた。 これは必ずしも不具合ではありません。 DynamoDBの読み取りは、デフォルトでは **結果整合性（Eventually Consistent Rea</description>
    </item>
    <item>
      <title>TypeScriptのasを減らす：satisfiesとの使い分けを実例で整理する</title>
      <link>https://chicchi.work/articles/2026-09-11-typescript-satisfies-vs-as/</link>
      <guid isPermaLink="true">https://chicchi.work/articles/2026-09-11-typescript-satisfies-vs-as/</guid>
      <pubDate>Thu, 10 Sep 2026 15:00:00 GMT</pubDate>
      <description>TypeScriptを書いていると、型エラーを消すために `as` を使いたくなる場面があります。 ただし、`as` は便利な一方で、使い方によってはTypeScriptの型チェックを自分で弱めてしまいます。 一方、TypeScript 4.9で追加された `satisfies` は、**「この値が指定した型</description>
    </item>
  </channel>
</rss>