Merge branch 'develop'

Author: BreadMotion

WebSite/content/blog/blog_00026.en.md

@@ -108,4 +108,4 @@ Combined with screen sharing and channel-based organization, the experience can
 One can only hope that more members of one's environment adopt Zed...  
 Even without that, Zed remains an excellent IDE, but for this specific feature, broader adoption would enhance its utility.
 
-Wishing you a productive and pleasant experience using Zed.
+Wishing you a productive and pleasant experience using Zed.

WebSite/content/blog/blog_00028.en.md

@@ -355,4 +355,4 @@ sequenceDiagram
 
 That’s it for this article. Next time we'll cover another GoF pattern with C++ examples and mermaid diagrams. The implementations shown here are simplified for learning; evaluate requirements (threads, lifecycle, testability) carefully before adopting in production.
 
-— Pan-kun
+Thanks for reading — Pan-kun!

WebSite/content/blog/blog_00028.md

@@ -337,10 +337,10 @@ s0.Say();
 
 ## まとめ
 
-- シングルトンは「ただ1つのインスタンス」を保証する便利なパターンだが、設計上のトレードオフを必ず考慮する必要があります
-- C++ では C++11 以降の関数内静的変数（Meyers'）がお手軽で安全な実装方法の一つである
-- 明示的な制御が必要な場合は `std::call_once` を使うと良い
-- 大規模なシステムやテスト性が重視されるシステムでは、依存性注入やファクトリなどの手法を検討することを推奨する
+シングルトンは「ただ1つのインスタンス」を保証する便利なパターンだが、設計上のトレードオフを必ず考慮する必要があります。
+C++ では C++11 以降の関数内静的変数（Meyers'）がお手軽で安全な実装方法の一つです。
+明示的な制御が必要な場合は `std::call_once` を使うと良いでしょう。
+大規模なシステムやテスト性が重視されるシステムでは、依存性注入やファクトリなどの手法を検討することを推奨します。
 
 参考・出典を記します
 

WebSite/content/blog/blog_00029.en.md

@@ -235,4 +235,4 @@ References:
 
 That's it—stay tuned for future articles covering Abstract Factory, Builder, and other creational patterns. The sample code here is simplified for learning; evaluate carefully before adopting patterns in production.
 
-— Pan-kun
+Thanks for reading — Pan-kun!

WebSite/content/blog/blog_00030.en.md

@@ -242,4 +242,4 @@ References (primary)
 
 That's it — I'll cover another GoF pattern next time. The sample code here is simplified for learning; evaluate and adapt thoroughly before using in production.
 
-— Pan-kun!
+Thanks for reading — Pan-kun!

WebSite/content/blog/blog_00031.en.md

@@ -162,4 +162,4 @@ References:
 
 I'll cover another GoF pattern next time. The code samples shown here are simplified for learning purposes — review and adapt them to your production requirements before use.
 
-That's all from Pan-kun!
+Thanks for reading — Pan-kun!

WebSite/content/other/blog_00032.en.md

@@ -8,7 +8,7 @@ recommended: true
 thumbnail: assets/img/ogp.png
 ---
 
-Hello! Pan here.
+Hello! I'm Pan-kun.
 
 This post covers the Builder pattern from the GoF (Gang of Four) design patterns.
 I explain it practically with sample code in C++, how to design it, when to apply it, and important caveats.
@@ -135,4 +135,4 @@ References and sources:
 
 That's it for this post. Next time I'll cover another GoF pattern. The code shown here is simplified for learning purposes — when adopting patterns in production, make sure to adapt them to your project requirements.
 
-Thanks for reading — Pan.
+Thanks for reading — Pan-kun!

WebSite/content/other/blog_00033.en.md

@@ -0,0 +1,157 @@
+---
+title: GoF Design Patterns - Adapter
+date: 2026-02-04
+category: Coding
+description: A practical guide to the Adapter pattern from the GoF collection：concepts, when to use it, a C++ implementation example, implementation notes, and references.
+tags: [Coding, DesignPattern]
+recommended: true
+thumbnail: assets/img/ogp.png
+---
+
+Hello! I'm Pan-kun.
+
+This post covers the Adapter pattern from the GoF (Gang of Four) design patterns.
+I explain it practically, including a C++ sample, how to implement it, when to use it, pitfalls to watch out for, and a Mermaid diagram for visualization.
+
+## Introduction
+
+The Adapter pattern provides a wrapper that connects incompatible interfaces, allowing an existing class to be adapted to the interface expected by clients.
+
+Benefits:
+- You can adapt existing code or third-party libraries to a new interface without changing their implementation.
+
+Drawbacks:
+- Proliferation of wrappers can scatter design responsibilities and reduce readability and maintainability.
+- The added indirection can also introduce runtime overhead.
+
+## Use cases
+
+Common scenarios where you would create an Adapter include:
+
+- Integrating a legacy API or library into a new application interface.
+- When different modules expose incompatible interfaces but you cannot modify the existing implementation.
+- Creating a thin boundary that makes it easy to swap implementations during testing (though using mocks can be simpler when applicable).
+
+## Structure
+
+An Adapter implements the Target interface and internally invokes the Adaptee's operations while performing any required conversions.
+
+```mermaid
+classDiagram
+    class Target {
+        <<interface>>
+        +request()
+    }
+    class Adaptee {
+        +specificRequest(params)
+    }
+    class Adapter {
+        +Adapter(adaptee)
+        +request()
+    }
+    Target <|.. Adapter
+    Adapter o-- Adaptee : adapts
+```
+
+## C++ implementation example
+
+Below is a concise C++ example.
+
+```cpp
+// Example: the client expects to call Target::request()
+struct Target {
+    virtual ~Target() = default;
+    virtual void request() = 0; // method the client expects
+};
+
+// Existing (unchangeable) class
+class Adaptee {
+public:
+    void specificRequest(const std::string& params) {
+        // Complex call in an existing API
+        std::cout << "Adaptee::specificRequest with " << params << std::endl;
+    }
+};
+
+// Adapter: implements Target while adapting Adaptee
+class Adapter : public Target {
+public:
+    explicit Adapter(std::shared_ptr<Adaptee> adaptee)
+        : adaptee_(std::move(adaptee)) {}
+
+    void request() override {
+        // Perform necessary translation before calling adaptee
+        std::string translated = translate();
+        adaptee_->specificRequest(translated);
+    }
+
+private:
+    std::string translate() {
+        // Actual translation logic; simplified here.
+        return "translated-params";
+    }
+
+    std::shared_ptr<Adaptee> adaptee_;
+};
+
+// main.cpp usage
+auto adaptee = std::make_shared<Adaptee>();
+std::unique_ptr<Target> target = std::make_unique<Adapter>(adaptee);
+target->request(); // the client only knows Target
+```
+
+Key points:
+- Perform data-format conversion, error handling, and method mapping as needed.
+- There are inheritance-based and delegation-based adapters; choose according to your use case.
+  In short: inheritance-based adapters leverage class inheritance, while delegation-based adapters implement an interface and forward calls to a contained object.
+
+## Implementation notes
+
+1. Keep translations simple
+   - Avoid loading the Adapter with excessive logic or business rules; that inflates its responsibility.
+   - If possible, extract translation logic into a separate module.
+
+2. Make ownership and lifecycle explicit
+   - In C++, pointer types determine the relationship between Adapter and Adaptee.
+   - Manage ownership clearly to avoid leaks and double frees.
+
+3. Consider performance
+   - Heavy translations on hot paths become performance bottlenecks.
+   - Consider caching translated results when appropriate.
+
+4. Preserve testability
+   - A thin Adapter is easier to unit-test.
+   - Make Adaptee mockable where practical.
+
+5. Provide logging and robust error handling
+
+## Common anti-patterns
+
+Typical bad practices when applying this pattern:
+
+- Putting substantial domain logic into the Adapter.
+- Adding Adapter layers indiscriminately across a project, deepening call chains.
+- Ignoring semantics lost during conversion or exceptional cases thrown by the adaptee.
+
+## Practical adoption checklist
+
+- Can you modify the existing code directly? If not, an Adapter is a reasonable choice.
+- Is the translation logic simple? If it's complex, consider an intermediary service or a Facade.
+- Do frequency and performance constraints tolerate the translation cost? If not, evaluate alternative designs.
+- Is there a test strategy? Ensure you can use mocks or integration tests as needed.
+
+## Conclusion
+
+The Adapter is a practical and commonly used pattern for bridging incompatible interfaces. However, careless proliferation of Adapters can complicate design. Make responsibilities explicit and localize translation logic when you use this pattern.
+Pay special attention to ownership, exception and error handling, performance, and testability when implementing an Adapter.
+
+References:
+
+[!CARD](https://sourcemaking.com/design_patterns/adapter)
+
+[!CARD](https://en.wikipedia.org/wiki/Adapter_pattern)
+
+That's it for now — next time I'll cover another GoF pattern.
+The examples in this article are simplified for learning purposes; evaluate them carefully against your requirements before adopting them in production.
+
+Thanks for reading — Pan-kun!

WebSite/content/other/blog_00033.md

@@ -0,0 +1,155 @@
+---
+title: GoFデザインパターン - アダプタ編
+date: 2026-02-04
+category: Coding
+description: GoFコレクションにおけるアダプタパターン実践ガイド：概念、使いどころ、C++の実装例、注意点と出典を実用的に解説します
+tags: [Coding, DesignPattern]
+recommended: true
+thumbnail: assets/img/ogp.png
+---
+
+こんにちは、パン君です。
+
+今回は GoF（Gang of Four）のデザインパターンのアダプタ編になります。   
+サンプルコード（C++）、作り方、使うタイミング、注意点、mermaid図による可視化などを含めて実用的に解説します。  
+
+## はじめに
+
+アダプタは互換性のないインターフェース同士をつなぐ ラッパー を提供し、クライアントが期待するインターフェースに既存のクラスを適合させるためのデザインパターンです。
+
+利点としては  
+既存コードや外部ライブラリを変更せずに新しいインターフェースへ適合できることです。
+
+欠点は  
+ラッパーが増えると設計が分散し可読性や保守性の低下を招くことです。  
+また、間接化によるランタイムのコスト増も発生します。
+
+## ユースケース
+
+代表的に下記のようなケースで作成されるパターンです。　　
+
+- 古い API / ライブラリを新しいアプリケーションインターフェースに統合したいとき。  
+- 異なるモジュール間でインターフェースの不一致があるが、既存実装を変更できないとき。  
+- テスト時に実装を差し替えるための薄い境界を作りたいとき（ただし Mock を使える場合はそちらの方が簡潔な場合もある）。
+
+## 構造
+
+Adapter は Target のインターフェースを実装し、内部で Adaptee の操作を呼び出して必要な変換を行います。
+
+```mermaid
+classDiagram
+    class Target {
+        <<interface>>
+        +request()
+    }
+    class Adaptee {
+        +specificRequest(params)
+    }
+    class Adapter {
+        +Adapter(adaptee)
+        +request()
+    }
+    Target <|.. Adapter
+    Adapter o-- Adaptee : adapts
+```
+
+## C++ 実装パターン
+
+以下は簡潔な C++ の例です。
+
+```cpp
+// 例: クライアントは Target::request() を使うことを期待している
+struct Target {
+    virtual ~Target() = default;
+    virtual void request() = 0; // クライアントが期待するメソッド
+};
+
+// 既存の（変更できない）クラス
+class Adaptee {
+public:
+    void specificRequest(const std::string& params) {
+        // 既存 API の複雑な呼び出し
+        std::cout << "Adaptee::specificRequest with " << params << std::endl;
+    }
+};
+
+// Adapter: Target を実装しつつ Adaptee を適合させる
+class Adapter : public Target {
+public:
+    explicit Adapter(std::shared_ptr<Adaptee> adaptee)
+        : adaptee_(std::move(adaptee)) {}
+
+    void request() override {
+        // 必要な変換を行ってから adaptee を呼ぶ
+        std::string translated = translate();
+        adaptee_->specificRequest(translated);
+    }
+
+private:
+    std::string translate() {
+        // 実際の変換ロジック。ここでは単純化。
+        return "translated-params";
+    }
+
+    std::shared_ptr<Adaptee> adaptee_;
+};
+
+// main.cpp
+auto adaptee = std::make_shared<Adaptee>();
+std::unique_ptr<Target> target = std::make_unique<Adapter>(adaptee);
+target->request(); // クライアントは Target のみを意識する
+```
+
+ポイントとして  
+必要に応じてデータ形式の変換、エラーハンドリング、複数メソッドのマッピングを行うようにしましょう。  
+また、継承ベースと委譲ベースがありますが、ユースケースに寄って使い分けしてください。  
+端的に説明すると、継承ベースはクラスの継承を活用し、委譲ベースはインターフェースの実装です。  
+
+## 実装上の注意点
+
+1. 単純な変換に留める  
+   Adapter に過度のロジックやビジネスルールを詰め込みすぎると責務が肥大化します。  
+   可能なら変換ロジックは別モジュールに切り出しましょう。  
+2. 所有権とライフサイクルを明確にする  
+   C++ ではポインタの種類により Adapter と Adaptee の関係が変わります。  
+   リーク・二重解放を避けるために明示的に管理しましょう。    
+3. パフォーマンスの考慮  
+   頻繁に呼ばれるパスで重い変換を行うと性能ボトルネックになります。  
+   必要なら変換済みキャッシュを検討しましょう。    
+4. テストしやすさを保つ  
+   Adapter を薄く保つことで単体テストが簡単になります。  
+   Adaptee をモック可能にしておくと良いです。    
+5. ログ・エラーハンドリングを整備する  
+
+## よくあるアンチパターン
+
+下記はこのデザインパターンを利用する際に起きる悪い例です。
+
+- Adapter に大量のドメインロジックを入れる。  
+- プロジェクト全体で無差別に Adapter 層を追加してしまい、呼び出しチェーンが深くなる。  
+- 変換で失われる意味や例外ケースを無視する。
+
+## 実務での採用判断チェックリスト
+
+- 既存コードを直接変更できないか？（変更不可なら Adapter が妥当）  
+- 変換ロジックは単純か？ 複雑なら中間サービスやファサードでの整理が必要か？  
+- 頻度・性能要件は許容できるか？（変換コストが高ければ別設計を検討）  
+- テスト戦略は確立できるか？（Mock や Integration テストの整備）
+
+## まとめ
+
+アダプタは「互換性のないインターフェースを橋渡しする」ための実用的かつよく使われるパターンです。  
+ただし、Adapter を安易に量産すると設計が複雑化するため、責務を明確にし変換ロジックを局所化して使うことが重要です。  
+実装では所有権、例外・エラー、性能、テストのしやすさを特に注意してください。  
+
+参考・出典を記します
+
+[!CARD](https://sourcemaking.com/design_patterns/adapter)
+
+[!CARD](https://en.wikipedia.org/wiki/Adapter_pattern )
+
+それでは、次回は別の GoF パターンについても解説していきます。  
+この記事で紹介した実装は学習目的に簡素化しています。  
+実プロダクションで採用する際は要件に合わせて十分に検討してください。  
+
+以上、パン君でした！