feat: Move /events/latest → /dojos/activity to be more RESTful

[yasulab]

📍 概要

/events/latest を /dojos/activity に移動し、Rails Wayに従ったRESTfulなURL構造にしました。
さらに、/dojosページとの一貫性を持たせるためUIを統一し、非アクティブ判定ロジックを全サイトで一元管理するように改善しました。

✅ 実装内容

1. URL構造の改善

• 🆕 新しいルート /dojos/activity を追加（collection route）
• 🔄 旧URL /events/latest から301リダイレクト設定
• 📁 EventsControllerからDojosControllerへロジックを移動
• 🗑️ 古いコントローラー/ビューファイルを削除

2. UI/UXの統一化（/dojosページとの一貫性）

• 📊 カラム構成の改善
  • ☯️ 道場名 (ID 番号) - /dojosと同じ形式で表示
  • 🗓 掲載日 - /dojosと同じロジック（created_at）
  • 👥 開催日 - 直近のイベント開催日を独立カラムに（新規追加）
  • 📝 ノート - 60文字でtruncate
• 🎨 CSS共通化（DRY原則）
  • .stats-tableクラスに統一
  • 51行のCSS削除 → 30行に集約（-21行）
• 🔗 リンク先統一
  • 道場詳細ページ（/dojos/:id）へのリンク

3. データの明確化

• 掲載日と開催日を分離して表示
• 開催データがない道場は「-」表示
• 1年以上開催していない道場をハイライト（expiredクラス）

4. 非アクティブ判定の一元管理 🆕

• 定数化: Dojo::INACTIVE_THRESHOLD = 1.year をDojoモデルに定義
• 動的表示: /signupページの「１年間」を変数化
  • Before: 一定期間 (現時点では１年間)
  • After: 一定期間 (現時点では{{ INACTIVE_THRESHOLD }})
• 自動変換: 期間を日本語表記に自動変換（例: 1.year → １年間）
• Single Source of Truth: 閾値変更時に全ページが自動更新

5. コードの改善

• 同じ日付の道場を地理的順序（order）でソート
• 文言・説明の改善（リンク先ページ名を正式名称に統一）

🧪 テスト

• ✅ 新しいURL /dojos/activity が正常に動作
• ✅ 旧URL /events/latest からのリダイレクトが機能
• ✅ アクティブな道場のみが表示される
• ✅ 新しいカラム構成（掲載日・開催日）が正しく表示
• ✅ 道場IDが/dojosと同じ形式で表示
• ✅ /signupページの閾値が動的に表示される
• ✅ 全テストがパス (35 examples, 0 failures)

📊 コード改善効果

変更ファイル: 9ファイル
追加行数: +147行  
削除行数: -99行
差分: +48行（機能追加含む）
CSS削減: -21行（DRY化による）

主要な改善点

• DRY原則: CSS共通化、UI統一、定数の一元管理
• Rails Way: ビジネスロジックをモデルに集約
• 保守性: 定数化による変更の容易さ
• 可読性: 明確な命名と構造化
• 一貫性: 全サイトで統一された非アクティブ判定

🎯 なぜこの変更が必要か

1. Rails Way準拠: dojosリソースのcollection routeとして実装
2. 情報アーキテクチャ改善: 道場関連の機能は/dojos配下に統一
3. DRY原則の徹底: /dojosページとのCSS・UI統一、定数の一元管理
4. データの透明性向上: 掲載日と開催日を明確に分離
5. メンテナンス性向上: 閾値管理の一元化により将来の変更が容易

💡 影響範囲

• ✅ 既存の /events/latest へのリンクは自動的にリダイレクト（破壊的変更なし）
• ✅ ブックマークやドキュメントの更新は不要（301リダイレクト）
• ✅ 両ページ間で一貫したユーザー体験を提供
• ✅ 非アクティブ判定の閾値変更が全サイトに自動反映

📝 関連Issue/Discussion

• Rails Wayに従った設計改善の一環です
• YAGNI原則に従い、最小限の実装から段階的に改善しました
• DRY原則に従い、コードの重複を削減しました
• Claudeからのフィードバックを適用し、定数化によるメンテナンス性を向上しました

🔄 コミット履歴

1. feat: Move /events/latest to /dojos/activity following Rails Way
2. refactor: テーブルCSSを共通化してDRYに
3. feat: /dojos/activity のnoteカラムにtruncateを適用
4. feat: /dojos/activity に掲載日カラムを追加し、開催日と分離
5. feat: /dojos/activity に道場IDを表示（/dojos と同じ形式）
6. docs: /dojos/activity の説明文を改善
7. fix: ソート順を地理的順序に改善
8. refactor: 非アクティブ判定の閾値をDojoモデルに定数化
9. feat: /signup ページの非アクティブ期間を動的表示に

📸 スクリーンショット

Before & After

• /events/latest → /dojos/activity
• 掲載日と開催日の分離
• 道場ID表示の追加
• 非アクティブ道場のハイライト表示

✨ レビュアーへのお願い

特に以下の点についてフィードバックをお願いします：

1. UIの一貫性（/dojosページとの統一感）
2. 非アクティブ判定の閾値管理方法
3. ソート順（地理的順序）の妥当性

[yasulab]

@claude Review this PR if we can merge or need additional commits to merge? ultrathink

[claude]

Claude finished @yasulab's task —— View job

---

📋 レビュー結果

PRを詳細にレビューしました。全体的に優れた実装で、マージ可能と判断します。

✅ 良い実装 (参考になる箇所)

1. Rails Wayに沿った設計

• collection routeを使った/dojos/activityの実装は適切です
• 301リダイレクトで後方互換性を維持している点も良いです

2. DRY原則の徹底

• .stats-tableクラスへのCSS統一により、51行から30行へ削減（-21行）
• /dojosと/dojos/activity間でUIコンポーネントを共通化

3. データの明確な分離

# 掲載日と開催日を明確に分離
created_at: dojo.created_at,  # 掲載日（/dojos と同じ）
latest_event_at: latest_event.nil? ? nil : latest_event.evented_at, # 開催日

4. 適切なテストカバレッジ

• 新しいルートのテスト
• リダイレクトのテスト
• 表示内容の確認テスト

5. YAGNI原則の適用

• 最小限の実装から始め、必要な機能のみを追加
• 過度な抽象化を避けた実装

💡 提案 (より良い実装方法)

1. N+1クエリの最適化

activityアクションではincludesを使用してN+1問題を回避することを推奨します：

def activity
  @latest_event_by_dojos = []
  # N+1を避けるため、event_historiesを事前ロード
  Dojo.active.includes(:event_histories).each do |dojo|
    # ...
  end
end

2. ソートロジックの改善

現在のソートでは、同じ日付の場合にIDで並び替えていますが、より意味のある並び順（例：道場名）にすると良いでしょう：

@latest_event_by_dojos.sort_by! do |dojo| 
  sort_date = dojo[:latest_event_at] || dojo[:note_date] || dojo[:created_at]
  [sort_date, dojo[:name]] # IDではなく名前でソート
end

3. パーシャルの活用検討

将来的に、テーブル構造が他のページでも使われる場合は、パーシャルに切り出すことを検討してください：

<%= render 'shared/stats_table', dojos: @latest_event_by_dojos %>

4. 定数の活用

1年以上開催していない判定ロジックを定数化すると、メンテナンスが容易になります：

INACTIVE_THRESHOLD = 1.year

# ビューで
expired = dojo[:latest_event_at] <= Time.current - INACTIVE_THRESHOLD

🎯 結論

このPRは以下の点で優れています：

• ✅ Rails Wayに従った適切なRESTful設計
• ✅ DRY原則によるコード重複の削減
• ✅ YAGNI原則による段階的な実装
• ✅ 後方互換性の維持（301リダイレクト）
• ✅ 適切なテストカバレッジ

特に重大な問題やセキュリティ上の懸念はありません。提案した改善点は将来的な最適化として検討できますが、現状のままでもマージ可能です。

コードの品質は高く、Rails のベストプラクティスに従っています。👍