サービスを印象付けるロゴを作りましょう
サイトの左上に貼るのに使ったりします。

現在のPostの数を返すAPIを作ってもいいし、GET /api/postsで、投稿リストと一緒に返してあげるのもありだと思います。

もし余裕があったら、投稿と同時に件数が増えるようにできると理想ですね。

#21 Step 2
前提: #69

やること

• SSL/TLS を使うように nginx の設定を書き換える
• Docker で証明書が読み取れるようにディレクトリのマウント設定も変える

関連: #61

@batora9 が発見したバグ

投稿すると、タイムラインの時刻表示が変になる

更新すると直る

Cloudflare!!!!!!!!!!!!!!!

#12 ができていること前提です

• 投稿から投稿へ連携するためにretweet_idをPostテーブルに追加しよう
• リツイートができるようにしよう
• リツイートが表示できるようにしよう

Bun や dbmate, Gormなどのテーブルスキーマなどをバージョン管理する「マイグレーション」を導入して効率的に管理しよう

#13 ができていること前提です

GET /api/usersでどうでしょうか

前提: #56

#56 では、読み込みが失敗したときに「エラーが発生しました」と表示されるようになりました。
ですが、ユーザーからしたらなぜエラーが発生したのか、どうしたら解決できるのかがわかりません。

そこで、なぜ失敗したのかも表示してみましょう！
例えば「サーバー内でエラーが発生しました」「ログインしてください」「ページが見つかりません」「リクエストがタイムアウトしました」... などなど

http://133.130.107.69/ が現在のサイトのURLです。maxitter.maximum.vcでアクセスできるように設定しましょう

#12 ができていること前提です。

JWTが一番やりやすいのでこれでやりましょう。

• ユーザーテーブルにemail + passwordフィールドを追加
• 認証用のミドルウェアを作成
• JWTをLocalstorageで管理してヘッダにつけてポストする機能を作成

Material UIのAppbar https://mui.com/material-ui/react-app-bar/ を使ってサイトにヘッダーを作りましょう。
#6で作ったロゴを使ってもいいです。

前提: #20

• 管理者向け API 作成
• user ban 機能
• post delete 機能
• analytics 機能

など、サービス管理に必要な機能を追加した管理者画面を作成してみましょう！

ユーザー機能を作りましょう。認証は難しいので別Issueにします。

実装する機能が多いのでタスク分けします。

• #13
• #14
• #15
• #16
• #17
• #18

絶対面白いと思う

MUIのダークモード対応について調べてみよう

概要

前提: #31

今の時代、ほとんどのサイトで SSL/TLS を用いた HTTPS 通信が主流になっています。
これはざっくりいうと、ブラウザとホストの間を暗号化して、盗聴されてもだいじょうぶ！にする技術です。

技術について詳しくは説明しませんが、「SSL/TLS 証明書」というものが必要になります。
基本的にはお金をかけて取得するものなのですが、 Let's Encrypt を利用すると無料で取得することができます。

現在プロトコルは http なので、 SSL/TLS 証明書を取得し nginx の設定をすることで https にしましょう！

タスク内容

• #69
  • ローカルに対して証明書は発行できないので、オレオレ証明書を発行する
  • README.md ファイルに発行手順を書いておく (各自やらなければいけないので、わかりやすく書く)
• #70
  • SSL/TLS を使うように nginx の設定を書き換える
• #71
  • 公開鍵ペアを生成
  • 公開鍵を @a01sa01to か @sor4chi に送り付けて SSH 接続できるように設定してもらう
• #72
  • サーバー上でコマンドをたたいて証明書を発行する
  • 自動で更新するように設定する

現在、このリポジトリには Branch Protection が設定されておらず、書き込み権限のある人ならば development, production ブランチに Push できる状態になっています。
これでは、バグが埋め込まれた状態だとしても本番環境に反映されてしまいます。

そこで利用できるのが、 GitHub の機能「Branch Protection」です。
これは、リポジトリのブランチに対して、 development, production ブランチへの Push 前にプルリクエスト (PR) およびそのレビューがないと Push できないようにしたり、ちゃんとビルドできないコードではマージできないようにしたりする機能です。
詳しくは GitHub の Docs をご確認ください: https://docs.github.com/ja/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches

実際に development, production ブランチに対して Protection を設定しましょう！
なお、 production ブランチは development ブランチよりも制限をかけたほうが良いです。

すでにバックエンドから日付データが送られてきているので、それを使って各ツイートの下に投稿日時を表示しよう
JavascriptのDateを使って YYYY/MM/DD HH:mm表記にしてみよう

現在のタイムラインはIDの辞書順になってしまっているので、うまく最新時刻順に変更してみよう

前提: #33

#33 でビルド・デプロイができるかどうかチェック出来たら、次は「テスト」を組み込んでみましょう。
これによって、ビルド時・デプロイ時のエラーのみならず、バックエンド・フロントエンドのバグも見つけることができます。
また、これまで完成していた機能が、新機能によって動かなくなってしまった！ということも防ぐことができます (リグレッションテストといいます)

テストを作成し、まず手元で確認、それができれば GitHub Actions でテストを走らせるように設定してみましょう！

#13 ができている前提です

POST /api/users/newでどうでしょう

これ絶対重いやつ

Cloudflare などは便利なもので、ブランチに Push すると勝手にビルドして、ビルドに成功したらそのプレビューを表示してくれます。
saitamau-maximum/website で PR を出したときにコメントが付きますが、それも同じです。

ブランチに Push されたらそれを検知して自動でビルドし、その結果をデプロイしてプレビューを生成する機能を作成してみましょう！

#15 ができていること前提です

#45 の修正

CREATE INDEX posts_latest_idx ON posts (created_at)

#21 Step 3
前提: #69, #70

やること

• 公開鍵ペアを生成
• 公開鍵を @a01sa01to か @sor4chi に送り付けて SSH 接続できるように設定してもらう

PR は必要ないですが、後々見て何したかわかるように、この Issue にやったこと (コマンドとかローカルの設定とか) をコメントを残していってください！

前提: #2 ✅

#2 (PR: #38) により、 GetPosts で呼び出している SQL に ORDER BY created_at DESC LIMIT 20 をつけることで、「 created_at で降順で並び替えたうち、上の 20 個を返す」すなわち最新の投稿 20 件のみが返されるようになりました。
変更部分は以下です。

ですが、データを並び替える ORDER BY という処理は時間がかかります。
競プロで sort は $O(N \log N)$ かかることを習ったと思いますが、毎回毎回ソートして出力、といったことをしていると、データが $10^8$ くらいあった場合、 20 個返すだけでも数秒かかってしまいます。

index を貼って、高速化につなげましょう！
index ってなに？の話は下のコメントを見てね

前提: #33 ✅ (PR: #41)

現在、PR を提出すると GitHub Actions でビルドチェックが走ります。
Actions タブ から、どれかの実行ログを見てみましょう。

Frontend-build のほうが影響は大きく、 Install Frontend Dependencies を見てみると、数十秒かかっていますね。
でも、ローカルで開発する時、 npm ci を実行すると 1 回目は時間かかるかもしれませんが、 2 回目以降は一瞬ですよね。
これは node_modules ディレクトリが作成されており、そこを更新する作業であるためです。

GitHub Actions では、毎回毎回環境がリセットされてしまうため、 node_modules ディレクトリがなく、毎回時間がかかってしまいます。
時間がかかると待ち時間が無駄ですし、 GitHub Actions は課金制なので料金が請求されてしまうこともあります (Public リポジトリだと無料ですが...)

そこでキャッシュを使います。
actions/setup-node では、キャッシュするためのオプションが用意されています。
これを用いて、キャッシュを設定しましょう！

参考: actions/setup-node のリポジトリ (https://github.com/actions/setup-node)

Docker composeのオペレーションスクリプトを修正と強化したい

必要なフィールドはとりあえず

• id
• username

で、もし余裕があれば拡張しても大丈夫です！

現在は全ての投稿が見れる形になっている。
これでは投稿が増えていくにつれてだんだんサイトが重くなっていってしまう。
そこで最新の20件だけを取得するようにして、それを返してあげることで効率化しよう！

現在はデフォルトの「Vite + React」というタイトルになっています。
これをとりあえず「Maxitter」に変えてみましょう。

画像が投稿できるようにしましょう

• #43
• 画像投稿用のフィールドを新設
• 画像投稿用のAPIを生やす
• 画像投稿のリクエストロジックを書く

現在フロントエンドはJavaScriptで動いていて、これでは型がないため開発がとても大変です。
そこで型システムをフロントに導入してより保守的な開発ができるようにしましょう。

#3 ができていること前提です

https://mui.com/material-ui/react-pagination/
Material UIではページネーションコンポーネントが提供されています。
これを使ってバックエンドのページネーションAPIと連携して実際に動くものを作ってみましょう。

#19 ができていること前提です。

ユーザーを登録するフォームを作りましょう。

nginxコンテナ/var/www/html/imagesとローカルのbackend/public/imagesをマウントボリューム
goコンテナのapp/public/imagesとローカルのbackend/public/imagesをマウントボリューム
してnginx <-> go間を接続します

概要

現在、「更新する」を押して /api/posts を叩きに行っていますが、リクエストに失敗 (HTTP Status Code が 4xx, 5xx) しても、「読み込み中」の表示のままになっています。
失敗したら「更新する」に直して、「読み込み時にエラーが発生しました」といった表示を出すようにしてみましょう！

スクリーンショット

リクエストに失敗

「読み込み中」から変わらない

ヒント

HTTP Status Code 4xx, 5xx が出ない！といった場合、 GetPosts 内をいじって意図的に返すようにすればよいです。
ただし、その変更は Commit しないようにしてください！

参考リンク

• HTTP レスポンスステータスコード - HTTP | MDN

#21 Step 4
前提: #69, #70, #71

やること

• サーバー上でコマンドをたたいて証明書を発行する
• 自動で更新するように設定する

PR は必要ないですが、後々見て何したかわかるように、この Issue にやったこと (コマンドとかローカルの設定とか) をコメントを残していってください！

#2 ができていること前提です

最新の投稿1ページだけでは過去のツイートが見れませんよね。
ということでページネーションを実装して過去の全ての投稿が遡れるようにしましょう！
GET /api/posts?page=2のようなAPIを実装するイメージでやるとやりやすいと思います。

例)
1ページ20件の投稿が表示されるとして
例えばデータベースに ID 1 - 50 の投稿があったら(ID大きい方が最新)
GET /api/posts?page=1 => 50 - 31
GET /api/posts?page=2 => 30 - 11
GET /api/posts?page=3 => 10 - 1

となるように設計してみよう

現在はSPAのReactアプリになっているので、これをReact Routerなどを使ってPESPA式にしましょう。

これをすることで機能追加が容易になるでしょう。

Nginxのフォールバック設定が必要になりますが、とりあえず今回は導入できればいいです。

新機能を追加しても、設定ミスや構文ミスなどがあってビルド・デプロイできなければ意味がありません。
しかし、いちいち PR を受けてブランチを切り替え、ちゃんとビルドができるかどうかをチェックするのは手間です。

そこで、 GitHub Actions を利用し、ブランチに Push されたら自動的にビルドできるかチェックする CI (Continuous Integration) を作成してみましょう！
なお、ビルドができればとりあえずおっけーです。ビルド時以外のバグについてはここではチェックされないことに注意してください。
ビルド時以外のバグ (?) もチェックしたい場合、 #34 もやりましょう！

#21 Step 1

内容

• ローカルに対して証明書は発行できないので、オレオレ証明書を発行する
• README.md ファイルに発行手順を書いておく (各自やらなければいけないので、わかりやすく書く)

やること

• README.md の更新

#14 ができていること前提です