ラズパイ財団側にある Clubs データベースの ID と、coderdojo.jp の Dojo ID を紐付ける `***_id` を用意したい

[yasulab]

• 関連: zen_id を使って Zen の Dojo ID と coderdojo.jp の Dojo ID を紐付けたい #494
• 補足: 上記 Issue を書いていた当時は CoderDojo 専用の DB (Zen DB) だったが、2024年から CoderDojo 以外の非営利クラブも含めた包括的な Clubs DB という仕様に変わったため、基本的には新たに設計し直す必要があり、それに伴い Issue も新たに作成し直しました。

😭 コレがないので困っていること

例えば coderdojo.jp に新規 Dojo が追加されても、DojoMap 側にある名前突合用の CSV を手動で更新しないと、地図上には反映されない。

• 新規追加フォーム: https://coderdojo.jp/signup
• 名前突合用のCSV: https://github.com/coderdojo-japan/map.coderdojo.jp/blob/main/dojo2dojo.csv
  • 現状のワークアラウンドとしては https://coderdojo.jp/stats#references にある Spreadsheet を参照し、Japan / Zen の名前のセルをコピーして、上記 CSV を更新することで、新規 Dojo が反映されます。
  • CSV データ更新の例: Update dojo2dojo.csv data map.coderdojo.jp#17

💖 コレができると嬉しいこと

上記のような DojoMap の新規 Dojo 追加が自動化できるようになる（はず）

Clubs DB の Club データ例: https://gyazo.com/5efc01e408d2e0c90dc167f3db47fcd3 (CoderDojo 黒潮町)

🚧 コレができるようになるために必要なタスク

• 1. zen_id global_club_id カラムを Dojo モデルに追加する
• 2. 全ての Dojo の global_club_id を db/dojos.yaml に追加する
• 3. 追加した global_club_id と Dojo ID で突合し、Dojo 名を 日→英 または 英→日 に変換できる仕組みを用意する

上記の作業が一通り完了すると、DojoMap などのデータを手動で更新する必要がなくなり、自動で更新できるようになるはず...? 🤔💭

（ただマイクロサービスっぽくなっちゃって後々辛くなりそうので、DojoMap のリポジトリを coderdojo.jp に統合する、というアプローチもありそう 👀💭 けど別にまとめてやる必要はなさそうだし、どっちみち上記の作業は Clubs DB とのデータ同期に必要になるので、後回しでも特に問題はないかも?）

実際に統合した例「DojoCast」 📻

• DojoCast の元リポジトリ: https://github.com/coderdojo-japan/dojocast
• DojoCast 統合後の URL: https://coderdojo.jp/podcasts

[yasulab]

@claude Review this issue's plan? ultrathink.

[claude]

Claude finished @yasulab's task —— View job

---

タスクリスト

• 現在のコードベース構造を確認
• 提案された実装計画をレビュー
• フィードバックを提供

実装計画のレビュー

提案された計画について、以下の観点から詳細なフィードバックを提供します。

### 1. 全体的なアプローチについて

提案されている「club_idカラムを追加して Clubs DB と紐付ける」というアプローチは妥当です。現在の手動更新プロセスを自動化することで、運用効率が大幅に改善されると考えられます。

良い点:

• 既存のデータ構造（db/dojos.yaml）を活用する方針
• 段階的な実装アプローチ（カラム追加 → データ追加 → 統合）
• 明確なゴール（DojoMap の自動更新）

### 2. 技術的な観察と提案

現在のコードベースを確認したところ、以下の点に注意が必要です：

現在の構造:

• Dojoモデルはdb/dojos.yamlからデータを読み込む仕組みが既にある
• dojo_event_servicesで外部サービス（connpass、doorkeeper等）との連携実績がある
• DojoMap は/events.jsonエンドポイントからデータを取得している

改善提案:

1. カラム名について: zen_idからclub_idへの変更は、Clubs DB の仕様変更を反映した良い判断です
2. データ型: club_idは文字列型（string）で定義することを推奨（外部システムのIDは数値とは限らないため）
3. インデックス: 検索性能を考慮し、club_idにインデックスを追加することを推奨

### 3. 実装手順の詳細化

提案された3つのタスクをより具体的に展開すると：

タスク1: club_idカラムの追加

# db/migrate/xxx_add_club_id_to_dojos.rb
class AddClubIdToDojos < ActiveRecord::Migration[7.1]
  def change
    add_column :dojos, :club_id, :string
    add_index :dojos, :club_id
  end
end

タスク2: データの追加

• 全300+ Dojoのclub_idを調査・収集する必要がある
• 一部のDojoは既にURLにzen.coderdojo.comへの参照を持っているので、これを活用できる可能性
• データの一括更新スクリプトが必要

タスク3: 統合の仕組み

• 新しいサービスプロバイダー（lib/event_service/providers/clubs.rb）の作成を検討
• 既存のdojo_event_servicesの仕組みを活用することも可能

### 4. 追加で検討すべき事項

1. データ同期戦略:

   • Clubs DB との同期タイミング（リアルタイム vs バッチ処理）
   • APIレート制限への対処
   • エラーハンドリング

2. 移行期間の対応:

   • 既存のCSV更新プロセスとの並行運用期間
   • データ不整合時のフォールバック

3. テスト戦略:

   • 単体テストの追加
   • 統合テスト（Clubs DB APIのモック）
   • 本番環境での段階的ロールアウト

4. 監視・アラート:

   • 同期失敗時の通知
   • データ不整合の検知

### 5. 代替案の検討

記載されていた「DojoMapをcoderdojo.jpに統合する」案について：

メリット:

• マイクロサービスの複雑性を回避
• データの一元管理
• デプロイ・メンテナンスの簡素化

デメリット:

• 移行作業の工数
• 既存のDojoMap利用者への影響
• URLの変更による混乱

推奨: まずはclub_idによる連携を実装し、その後必要に応じて統合を検討するのが現実的です。

まとめ

提案された実装計画は適切で、段階的なアプローチも妥当です。技術的な詳細を詰めることで、より確実な実装が可能になると考えられます。特に、既存のイベントサービス連携の仕組みを参考にすることで、実装の品質と保守性を高められるでしょう。