# OpenHackUのめも
## 目次
- [チームとしての目標](#目標)
- [何を作るか](#何を作るかを一言で表すと)
- 解決したい問題とそれに対するアプローチ
- [解決したい問題](#解決したい問題)
- [この問題がなぜ起きているのか](#この問題がなぜ起きているのか)
- [どう解決するのか](#どう解決するのか)
- [技術的な話](#技術的な話)
- [ルール](#ルール)
- [作るもの](#作るもの)
- [フロント](#フロント)
- [バック](#バック)
- [OGPについて](#OGPについて)
- [議事録](#議事録)
- [自己紹介](#自己紹介)

## スライド
https://docs.google.com/presentation/d/14nEuU1-ADM9ACzoro3CbynNo4Jexnhi7bHHzF85QwiA/edit#slide=id.gca5fac81b4_0_0

## 目標
- 賞を目指すより、発言しやすい雰囲気を作って開発を回していくことを優先
- Reviewを入れることでコミュニケーションと、責任の単一化を防ぐ
- とりあえず動くものを作ることを大事にしたい
- 凝りすぎて完成しませんでした！より動くものが大事

## 何を作るかを一言で表すと
@kaito-tateyama
幾つか案を出しておきました。最もアイデアに近いものか、もしくは他の表現を提示して欲しいです。

- GitHubよりも気軽に話せるSNS ← これ一番よい表現です
- コードがついたツイッター
- ソースコード特化型Q&Aサイト
- IT系のQ&Aで距離感を近くするSNS

## このアプリケーションが提供する機能
- OGPを用いて、ソースコードの該当部分を画像にしてSNSで提示できる機能
- GitHub以外にも気軽にコードをアップロードできる機能
- コードにコメントして、IssueやPRよりも手軽な感じで話せるプラットフォーム

## 解決したい問題
- サークル内で
- 「これを実現したいです」と言われても、ふわっとしすぎてて対応しづらい
- 逆にコードを具体的に提示されれば対応しやすい
- **GitHubのここのコードいいよねとかいう話をissueよりもっと気軽にやりたい。**
- GitHubの方式は堅苦しすぎる
- **GitHubとSNSの中間的な存在が欲しい**
- Twitterで
- 競プロのデバック募集や問題解決のためにリプを繰り返している場面がある
- AtCoderの質問をTwitterでやり取りするのもなぁという気持ち
- まとまっていれば、そこを見れば良くなる
- 別の場所でコードの該当行を表示してくれると対応しやすい
- 全体的に
- 個人開発、AtCoderで**個人で書いている人はレビューが貰えない**
- インターン等に参加してる人は社会人の人にレビューしてもらえる
- **レビューが欲しい**
- しかし
- ただ作った, 書いただけでは, **質問をしても回答してくれる人がいない問題**に陥る
- これらの問題に取り組む
- **TODO: 目的をどれかに絞ったほうが開発はしやすそう?**
- @kaito: 質問サイトにするとコードについて気軽に話す から離れそう。コード投稿サイトとしてみた方がよい？
- 僕自身AtCoderのユースケースを意識しすぎて質問特化になっていたが、コードを気軽に投稿し、issue/PRをたてるより気軽に話しかけられるという方に気を向けた方がいいかも
- ただ、コードについて話すことがそんなにあるか？という問題 & reviewが欲しいというそもそもの出発点から離れている気もする

## この問題がなぜ起きているのか
- **質問をしても回答してくれる人がいない問題**が何故起きているのか
- 質問がふわっとしすぎていて、回答しづらい
- わざわざ時間を使いたくない
- インセンティブが魅力的ではない
- 距離感が近くない人に回答するのは、はばかられる
- **GitHubの方式が堅苦しすぎる**のは何故か
- TODO: 議論の余地あり
- 本当にデザインの問題だけ？
- 仮に、GitHubのデザインに慣れていないのならばデザインを変えれば良い
- ここは意見調査をする必要がありそう
- @kaito: issue/PR立てるのってそのコードに機能を足したい、問題がある場合
- → そもそもGitHubはコードについて話すSNSではないので、GitHubの方式が堅苦しいというより機能が目指しているところが違う気がする？

## どう解決するのか
- 質問がふわっとしすぎていて、回答しづらい
- 質問する人がコードを具体的に提示してくれれば、回答する人は回答できる
- **質問を具体的にさせる工夫が何か必要？**
- 今いるフォロワーに対しては下記の手法で問題解決できそう
- OGP
- 質問と同時にコードを具体的にする
- わざわざ時間を使いたくない
- 時間を使ってまで回答したくなる魅力を作る必要がある
- インセンティブが魅力的でない(あまり良くない)
- お金をあげてみる？
- お金をインセンティブにすると質が低くなりがち
- 距離感が近くない人に解答するのは、はばかられる
- 距離感が近かったら回答してくれるかもしれない
- 距離感が近まるようなサポートをすれば良いのでは？
- SNS連携をして、繋がりを作る
- 「距離感が近い」とは
- 気軽に話せる
- 同じ趣味を持っている
- 応援する/されるの関係がある
- GitHubのデザインは堅すぎる
- レビューを気軽に出来るようなデザインにしたい
- 堅苦しくないデザインにする
- アイコンを堅苦しくなくするだけ？
- GitHubが堅いのってそういうところだっけ？

## 技術的な話
### ルール
- master branch protection
- commit, PRルール
- CI Linter, misspell
- コミットとIssueを紐づける
- Reviewルール
- レビューを決めておく

### ユースケース
以下の2つのみ？

- ユーザがこのサービスで質問して、別のユーザから回答をもらうまで
- 分からない問題が出てくる
- プラットフォームで質問を投稿する
- サービスに対する回答が来たらTwitter等で通知をする
- この通知を飛ばすために、**Twitter連携**が使える？
- ユーザが、別のユーザの質問に回答するまで
- 回答したい問題を選択する
- 質問に回答する
- 質問だけではない場合もありうる？
- コードについて話す
- 特に回答は求めない(SNSとしての使用)

### 追加で必要な機能
#### 絶対に必要な機能
- ログイン
- Twitterに絞ってもよさそう
- 投稿機能
- code, コメント, 出典URL
- markdown形式を利用できるようにする
- タグ(検索用)
- 一覧ページ
- 新着順で一覧表示(楽そう)
- タグでフィルタしたら一覧が出る
- Profile
- Twitterのでよい
- ユーザ名
- 説明文
- TwitterID
- Reply(回答)
- 行選択, コメント
- SNSボタン
- Twitterに共有する

#### 余裕があれば実装したい機能
- GitHub embed
- 大規模ソースコードに対応したいとき

### 作るもの
#### フロント
Vue もしくは Reactで実装する

1. 動的にOGPに生成されたコードの画像を設定する
- 動的にOGPを生成する
- Twitter等のSNSに投稿したときに見れるようにしたい
- 飛ばす先は単にコードを表示するサイト
- もしくはソースコードを保存している場所に飛ばす
- **ページ遷移があると嬉しい**
2. SNS風のページを作る
- ページデザインは[Kaitoさんが作ってくれたFigma](https://www.figma.com/proto/NYUYQbagvVF31K9466FI5H/OpenHackUdraft?node-id=125%3A42&scaling=min-zoom)を確認してください
- 左、右でページを遷移できる
- 必要なページは下記の通り
- 新規登録時のProfile入力ページ `/signup`
- 初めてログインした際に，このページに飛んでユーザープロフィールを入力する
- Profileページ `/user/[uid]`
- `[uid]` : サーバーから返される1~128文字の文字列
- Twitterのでよい
- ユーザ名, 説明文, TwitterID, その人の投稿を表示する
- `[uid]`が自分だったら、プロフィールを編集できるようにする
- 編集ボタンを配置
- ログインページ `/login`
- 「Twitter or Googleでログイン」のボタンが1つある
- ログインが成功すると投稿一覧ページに移行する
- ソースコード投稿ページ `/post/new`
- コード, コメント, 出典URLを入力する
- markdown形式を利用できるように、コード入力用のエディタを表示できるとありがたい
- 追加でタグ(検索用)を付与する可能性もある
- 投稿一覧ページ `/`
- 新着順で一覧表示
- バックエンドから受けとったデータを一覧で表示する
- 全て表示するとヤバそうなので、一ページに表示する数を決めておくとよさそう
- タグを追加した場合、タグでフィルタできる機能も欲しい
- タグでソートもできるようにしたい
- ソースコード詳細ページ `/post/[postid]`
- `[postid]` : 数値
- ソースコード本体と、それに対するコメントを見れるページ
- Twitter共有ボタン
- リプライを返すことが出来る
- Reply(回答)
- 行選択, コメント入力

##### まとめ

- 投稿一覧ページ `/`
- もりを
- ログインページ `/login`
- o-xian
- 新規登録時のProfile入力ページ `/signup`
- うーたん
- ソースコード投稿ページ `/post/new`
- ソースコード詳細ページ `/post/[postid]`
- Profileページ `/user/[uid]`

#### バック
Goで書く
Echo, GorpをORMとして使う

- コードに対してコメント可能なオリジナルSNSを作る
- その日の進捗を自動的にSNSに投稿する？
- ゆるふわなGitHubのようなイメージ
- **必要なAPIの設計をする**
- 必要な機能
- コメントに関する機能
- SNSにおいてコメントを行うことが出来る
- 取得/投稿/修正/削除
- コードに関する機能
- コードを取得することが出来る
- TODO: コードに修正を加えた場合の保存方法は？
- ユーザにコピーして貼り付けてもらう？
- 規約、プラットフォームに応じた対応とかいろいろな問題
- (特化するか否かは余裕があれば検討する)
- ログイン機能は未定
- コメント機能を付けるならログイン機能はあった方がよさそう？
- この場合アカウントに関する機能も必要になりそう

### 今後やること
- kaito: フロントエンドの仕様 どの場所クリックすると何が起こるという図 / バックエンド向けに、設計(機能だけでもOK) このたたき台を作ってくる
- フロント: OGPについて調べる、Reactを学ぶ
- おっしゃんが担当
- Next.jsでプロジェクトを立ちあげる
- TypeScriptに対応する
- バック: API仕様を決める

## 開発キックオフ 3/15
目次
- Hack Uとは何か？
- サポーター
- Zoom/Slackの使い方
- プレゼンについて

Hack Uとは何か？
- 学生が企画/開発/発表するイベント
- 学生がクリエイターになるきっかけ
- **3/18(木)** なんでも相談会 コンセプト、企画、技術、実装のアドバイス
- これは出席する。進捗確認も兼ねている
- 180秒のプレゼン、展示会で補足
- 発表は **3/27(土)**
- 開発期間は **3/15(月) - 3/26(金)**
- ただし、プレゼン資料提出は **3/24(水) 17:00まで** (厳守)
- 電子サイン方式の**参加同意書**に答えること。なるべくすみやかに提出

評価軸
- 新規性
- 技術
- 発展 そのプロダクトが及ぼす影響、波及するか
- 再現 ちゃんと動くかどうか

注意
- 対面での開発ダメ
- ライセンスを守ってOSSを使用
- プレゼンで漫画などの著作物を無断で利用しない(スライド提出時に審査)
- いらすとやは21点以上使えない、また、Yahoo!のイベントなので商用利用として考えること

心得
- モノづくりを楽しむためにチャレンジ
- 情報収集して、納得いくまで議論しよう
- 失敗して振り返って進もう
- 精一杯楽しもう

プレゼン
- 作品の開発と同じく重要
- 3段階の構成
- 何のために、何を作ったのか(目的) 背景は少なめにする
- 作品のデモは必ず入れる(動画は用意しておく)
- 仕組みの解説、工夫 (アピール)
- 発表者が注意すべきこと
- ハラスメント、不快な表現に注意
- 発表練習は必ずすること。作品知らない人に聴いてもらう(サポーターの方に協力してもらう)
- 時間
- しゃべる人は1人
- 冒頭30秒、デモ60秒、アピール60秒

## OGPについて

### [`vercel/og-image`](https://github.com/vercel/og-image)

無料版のVercelで動かす際は`README.md`に従って`vercel.json`を編集する必要がある

- vercel/og-imageを使ったブログOGPの簡単自動生成
- [Speaker Deck](https://speakerdeck.com/p1ass/generate-ogp-easily-using-vercel-og-image)
- [Qiita](https://qiita.com/p1ass/items/b8d5c1f3f4a5fd984d2c)
- [選ばれたのは Next.jsでした - Next.jsによるServer Side OGP ⽣成](https://speakerdeck.com/line_developers/next-dot-js-was-chosen-server-side-ogp-generation-with-next-dot-js)

### その他

- [NetlifyのPrerendering機能を使ってクライアントサイドのみの実装でOGP対応する](https://blog.microcms.io/ogp-with-client-side-javascript/)
- [Vercel + Next.js + PlaywrightでOGP画像を自動生成する](https://zenn.dev/tdkn/articles/c52a0cc7bea561)

### ねこさんヒアリング
HackU vol4で優秀賞取った[ねこ](https://twitter.com/marin_a___)さんが、HackUプロジェクトのOGPサービスを作ってました。以下のURLを参考にしたとのことです
- [Qiita：vercel/og-imageをフォークして自分だけのOGP画像生成サービスを作ろう](https://qiita.com/mkizka/items/f2d4836e4cfd241acccf)
- Vercelを使う
- [GitHub：marina-ki/open-hack-og-image](https://github.com/marina-ki/open-hack-og-image)
- ねこさんがHackUの時にデプロイしたリポジトリ
- [Qiita：[React+TypeScript+Firebase]FunctionsとHostingで動的にOGP表示するSPAを作った](https://qiita.com/stin_dev/items/41ac4acb6ee7e1bc2d50)
- Firebase Functionsでもできる

## Firebase

- 3/24の朝会でのえさんがサンプルコードを共有してくれた（ありがとうございます！）
- `login.html`と`firebase.html`はSlackのgeneralにあります

### 手順

1. `login.html`と`firebase.html`を適当なフォルダにまとめる
2. そのフォルダの中で適当にサーバーを立ち上げる
- `8000`番に立ち上げる例 : `python -m http.server 8000`
3. <http://localhost:8000/login.html>にアクセスすると動く！
- サインインが成功すると`firebase.html`にリダイレクトされる
- `firebase.html`では`document.write(idToken)`でtokenの中身がとりあえずそのまま表示されている
- これを`localStorage`に保存してあげて、諸々の処理のときに取り出せばよい
- `Authorization: Bearer <TOKEN>`の形式で

### その他

- `login.html`ではFirebase UIが使われているので、そこら辺については調べなおす必要がありそう
- Firebase UIがMaterial UIと干渉している都合上使えていないため...
- `login.html`の`firebaseui.auth.AuthUI(.)`など
- `yarn add firebase`をして以下のようにimport

    import firebase from 'firebase/app';
    import 'firebase/auth';

- `src/firebase.ts`を以下のようにすると便利そう
- `firebaseConfig`はFirebaseの設定（「プロジェクトの設定」の下部）から持ってくる
- （動作確認はしていないです）

    import firebase from 'firebase/app';
    import "firebase/auth";

    const firebaseConfig = {
      ...
    };
    firebase.initializeApp(firebaseConfig);

    export const provider = new firebase.auth.TwitterAuthProvider();
    export default firebase;

## 議事録
気づいた人が誰か書いてください

### 3/28 振り返り
- [今回使ったjamboard](https://jamboard.google.com/d/1tv6_lRcV3YBap0d51x3QAlkw3gcXUiqBQJbix0yHoRk/viewer?f=2)
- [Fun/Done/Learn](https://qiita.com/viva_tweet_x/items/7e279f41f4388d9162ef#:~:text=Fun%2FDone%2FLearn%E3%81%A8%E3%81%AF&text=Fun%2FDone(Deliver)%2FLearn,%E3%81%A8%E3%81%84%E3%81%86%E3%82%B7%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AA%E6%89%8B%E6%B3%95%E3%81%A7%E3%81%99%E3%80%82)を試しにやってみる
- FDL出して、かぶったやつは多くの人が感じたこと

kaito
- SRE的に、開発者に武器を渡すのは楽しい
- migrationの共有 GitHub Actionsなど人の手でやるべきでない
- 23卒Slackから出てるのは意識していた
- バックエンドに権限を渡せばよかった
- いろいろ学べた

morio
- 最初の方はまったり実装楽しかった
- 最後の方も新鮮だった(?)
- backend信頼出来て開発できたのはよかった
- 当日5時までのところでトップページのデザイン改善ができたのはよかった。
- ページの実装 デザイン
- コピペでいいところを汎用的にできたのがよい
- バックエンドとの疎通は感動した
- デザインでUIがユーザフレンドリーになるには？を考えていた
- やったこと/使ったことがないやつを学べた
- チーム開発をしていないので運用が分かった
- うーたんさんが通話に誘った

task
- これ大丈夫ですかと尋ねるのはよくないかもしれないが必要な立場
- 何が作りたいか、どういうことが解決できるかをtaskとkaitoが話し合ったのはよかった
- こういうプロダクトが作りたかったから、というプロダクトトップダウンの議論は楽しい
- 自分が作ったものが基盤となって動く喜び
- 形だけのレビューだけではない のえさんが優秀
- バックエンドはテストを書いていた。テストは大事。
- チーム開発の経験 確認をする人間の立ち回り 声をかけられないまでためこんでしまう kaitoは完璧主義でためこんでしまうので声をかけていた
- errorの使い方 のえさんに指摘された 一般化
- CIの設定 テストの設定
- クリーンアーキテクチャははじめてだった
- ハッカソンの流れ 開発するよりいかにそこまでで詰める、真髄が大事
- フロントのタグの管理がよいな バックエンドを参考にした 優先度高い低いは大事

o-xian
- Nextjsいけるやろと思ったらちょっと厳しかった
- バックエンドとの疎通は経験になった

u-tan
- gitの使い方学べた
- チーム開発楽しかった レビューを指摘されたのが楽しかった 個人ではできないので
- 通話ですぐに聴けるのも重要 1時間溶かすくらいなら聴いた方がいい
- API通信 データを引っ張ってくるgetしか経験がなかった DBにデータを入れることができた。apiも難しいことではないことが分かった。
- 他の人に迷惑かけないよう頑張るより、聞いた方がよい

まとめ
- 技術とチーム開発系の二つがよかった
- 振り返りエントリを書こう
- コミュニケーションについては相談しようが大事 朝会の機会はよかった

### 3/25
kaito
- slide
- OGP
- editorの一部切り取りみたいな感じにする
- 1-indexed
- 上から10行、折り返しなし
- OGPとデプロイを今日やる
- Nextのcustomサーバを使うので、僕がプルリクを投げる。デプロイのときはnode serverをcaddyで通してみたいにする？

morio
- 詳細画面
- 二分探索を使っているらしい これ展示会でアピールしよう

o-xian
- ログインはu-tanさんが実装した
- ロゴ
- フロント側で何しているか把握したい

u-tan
- ログイン
- User表示部分をやっている
- バックエンドとのつなぎこみが厳しいのでヘルプ

noe
- postに関連するコメント周り
- taskさんのreview
- コメントの投稿や個々の削除

### 3/24
kaito
- slideやばいので昼までに一回Slackに投げる

morio
- 詳細画面
- けっこういい感じにできている
- コメントする画面のUIが難しい

task

### フロントと共有したいこと
+TwitterIDは@を抜いた処理を想定している
+timeStampの形式
### 昨日やったこと
・スライドに入れる構成図
・APIのgh-pages追加(のえさんに後でお願い)
・POST /postの実装
### 本日やること
・GET /post/{postID}の実装
・GET /postの実装
### コメント
・スライドは昼に出来たら、Yahooの方に下記の3点を聞いてみると良いと思いました
　= 不足している点
　= 修正してほしい点
　= 追加するとよりよくなる点
### ききたいこと
フロント側の欲しいAPIエンドポイントの優先度

u-tan
- Docker環境構築
- axiosでmodule not found エラー

noe
- コメント周りのAPI
- review
- callbackでログインからの戻りの振り分けが難しい(強制プロフィールページか別の画面か)
- backendで別のAPI作る必要があるかも
- Slackにのえさんがデバッグで使っているコードがあるのでそれを参考にしつつやる
- login.htmlにConfigがある
- htmlだけでバックエンドなしで試せるのでまず試そう

### 3/23
kaito
- slide
- front docker
- OGP

o-xian
- UserProfile
- dockerの環境整える
- ロゴ

u-tan
- 記事投稿時のPreview
- docker

noe
- User endpoint get, create, update
- 今日はコメントのAPI
- 午後からいない

note
- 13時からフロントエンド frontでもくもく(docker環境構築)

### 3/22
- morio
- うーたんさんのレビュー
- シンタックスハイライターの調査・うーたんさんとの共有
- ソースコード
- バックエンドに聞きたいことが
- postidで投稿をgetするとき、int64で指定する。この数が大きいときや文字列はどうなる？
- task:まだわからない。変なリクエスト来たら弾く。範囲以外の数字が来たときは、postが存在しません、みたいな。
- フロントは意識しないて大丈夫です。
- o-xian
- ロゴ作成
- 2つ作ってみた！
- generalチャンネルに2つ上げました
- Profile画面の実装を行う
- 投稿一覧ページの上にユーザーの情報を記載する形

- うーたん
- 記事の投稿ページ作成
- 新規登録したときに来るプロフィールページの修正
- PRの確認
- プレビュー画面を作る予定
- ソースコードのプレビュー画面いる？
- morio) 作らなくて良いと思う
- 無理に作ることを増やさなくてよい

- task
- 昨日、一昨日、HackDay出てました。2日くらい全く作業できなくてまじで申し訳ない
- 結構たまっていたのえさんのレビューやった
- postを一覧をかえすバックエンドを書く
- GET /post
- post作成用のエンドポイントを実装する（できれば）
- POST /post

- のえ
- ユーザーの取得の実装をしていた。taskがレビューしている状態
- GET /user/{userID}

## kaitoさんに確認したいこと

- スライドの進捗
- ストーリー作る方向
- 提出の期限が水曜までなので、その日までに開発もひと段落させていく必要があるのでは
- 今後のスケジューリング（いつまでに何を終わらせるか）
- FrontのDockerのやつ
- Front、Backの疎通

### チームフロントエンド+kaito-utan案

- コロナになる前はPC見せて友人のコードが気軽に見れた
- オンラインになってから、アプリを進めましたとかの進捗しか報告できない。質問もふわっとしがち
- これを解決する、気軽にコードを共有して会話できるサービス
- コロナを絡めないと？
- コロナになって個人開発が増えた
- 1人だとレビューが欲しい!
- issueやPRって送るの大変じゃないですか
- 友達(Twitterフォロワー)とコードについて話したいときは、もっとカジュアルに共有したい
- **既存のアプリではできないことを強調**
- Twitter : コードの共有が難しい
- GitHub : 堅苦しい
- Q&Aサイト : ~怖い~勇気がいる
- **「距離感」がキーワード？**
- 前は「距離感」が近めだったけど
- 今は「距離感」が遠目
- このアプリを通して仲良くなるアプリなら！
- URLだけ貼り付けられることは無い
- ソースコードで語り合う
- コードで生まれるコミュニケーション
- 1人で書いたコードをみんなと共有して語り合おう
- みんなのコード OmnisCode
- 私のコードを皆にも
- フォロワー！コードレビューしようぜ！
- コードで繋がる人と人 あなたとわたしのOmnisCode

## タイトル
- コードで繋がる人と人 あなたとわたしのOmnisCode
- さぼてんとゆかいな仲間たち

## 何が問題となっているのか
- コロナになって個人開発が増えた
- **個人開発だと相談しあえるほどの友人が増えないので、レビューが貰えないこと**が問題
- 比較
- Twitter
- メリ: 気軽に使えて知り合いを増やしやすい
- デメ: コードの共有が難しく、浅い関係になりやすい
- GitHub
- メリ: コードの共有には向いている
- デメ: 堅苦しく、気軽に使うことが難しい
- Q&Aサイト
- メリ: 回答してもらえることが多い
- デメ: 回答の質がバラバラで怖い

## 何を作ったのか、どのように解決するのか
- 説明しながらデモを流す
- 2ステップ
- コード投稿までの流れ
- 1. Twitter/Googleアカウントでログインする
- 2. コードを入力して投稿する
- コメントまでの流れ
- 1. Twitter/Googleアカウントでログインする
- 2. コードの一部を選択してコメントする

## 技術説明
- それっぽい図を作る

## まとめ

std::cout << ":)" << std::endl;

<!--- thx!!! --->

### 3/21

kaito
- OGPに手を付けています
- CDはプルリク投げた
- CDが完了した段階でフロントチームにdockerを学んでもらってバックエンドとの疎通をやる

morio
- 一覧一通り完成 PR投げてる
- 詳細ページをこれから
- 詳細ページのhighlighter(prisma, react syntax highlighterを検討)

o-xian
- loginページ
- フロントエンドチーム共同で作業
- loginのレスポンシブ
- ロゴがほしいので作る

うーたん
- 投稿ページ
- プロフィールページ(強制的に出てくるとこ)の修正
- markdown to htmlライブラリを入れる

のえ
- User get処理をしている
- テストのときのdockerでdbをたてる

メモ
- domain決定(taskさんなしで決めてしまったごめんなさい)
- omniscode.one
- サービス名が入っていた方がよい、com, org, net, dev, jp, oneの中で考えて安くて`o`がそろって見た目がいい

### 3/20 朝mtg
kaito
- CDやる

o-xian
- (メモとり忘れた @kaito)

u-tan
- (メモとり忘れた @kaito)

noe
- firebase loginは**Twitter連携のみ**にしたい(googleだとデフォルトアイコンが名前になってしまうので)
- API User URLはバックエンドから送る

### 3/19 朝mtg
morioさん

- 問題一覧ページと一つ一つのコンポーネントを作成
- **editorにどのライブラリを使うと良いのか聞きたい**
- タイトルが長いときにアカウント名と重なってしまう問題を解決したい
- ユーザ名をタイトルの下か上に置けば解決できそう

kaitoさん

- docker imageを保存して使うリポジトリ周りの設定をしていた？
- フロント向けdocker講習会をする予定
- どのくらいの時間なんだろうか

o-xian

- material-uiで色々と大変だったとのこと
-

### 3/17 朝mtg
kaito
- インフラ権限周り調べた
- やること
- 監視
- GCR

o-xian
- フロントの共通設定(色)
- やること
- ログインページの実装
- PR review
- API通信(フロントエンドとバックエンドのつなぎ部分に詳しくないので技術調査)

u-tan
- material-ui
- やること
- API通信 UI以外のところをやる

noe
- firebaseの認証実装
- やること
- firebaseに実際にアクセスして動かす
- User周りの実装

なんでも相談会
- 何を解決したいか
- バックエンドからデータをとってきたい
- サポーターに相談したいこと
- フロントエンド: Next.jsでREST APIを扱う方法について、サポートをもらいたい
- インフラ: デプロイ後に何が起きるか心配なので、そのとき質問投げるかもしれません(デプロイは早めにやってCD回す予定)
- バックエンド: firebase動かしてみないと分からないので、そのとき聴くかも
- アイデア、コンセプトを説明して、意見をもらう(発表でどこをアピールするとよいか、疑問に思ったところはないか)
- 発表会に向けての現状(終わったこと、やること)
- 終わったこと
- 作るもの
- 初期セットアップ(使うフレームワークなど、技術選定)
- やること
- コードを書く
- スライドづくり(なぜ作ったか、何を作ったかの導入部分はできそう)

追加のメモ
- 展示会が大事(技術的な質問、こだわりを尋ねられる)
- ソロの審査員が来て色々聞かれる
- 発表練習は3分に収めるのが大事
- o-xianはブログとか静的なサイトの経験が多く、バックエンドとの連携は経験が少ないので手探り
- OGPについてはねこチームのねこさんに聞いてみる
- o-xianが参考にしたリンクありますか～くらいの軽い感じで聞いてみる
- o-xianは来週水曜休み スライドの追い込みに参加できないのを把握しておいてほしい

### 3/16 朝mtg
kaito
- サーバたてた。dockerなどを入れる
- 相談
- デプロイはどうする？ dockerを使うのか/使わないのか
- 結論
- private registry(GCR)を使う。github actions(CD)でデプロイが回るようにする
- 開発はローカル、デプロイはdockerで、Dockerfileなどもろもろはkaitoが頑張る

morio
- PRのレビューと、OGPについての調査
- 相談
- OGPの実装、リポジトリやホスティング先を分けるか？
- 結論
- OGPはみんな分からないのでhackmdにOGPについて調べたことを書いてもらう
- 別ホスティングにするかも？

o-xian
- Nextセットアップをした
- 相談
- バックエンドとフロントエンドの連携
- 結論
- のえ: yamlのapiは今作っている途中なので、早めに完成させます

u-tan
- cloneして動くかやった
- TypeScript書いてみた
- 相談
- モブプロお願いします(一緒にコード書く機会が欲しい)
- 結論
- フロントエンドチームでモブプロを行う

noe
- API仕様書を書いた(YAMLを書いた)
- taskさんがgoのプロジェクト構成をしてくれた
- 相談
- firebase
- jamboard見ながら説明。フロントにfirebase処理を書いてもらう(Auth)
- あとフロントに、firebaseでログインした後callbackでdisplaynameなど設定できる画面にリダイレクトしてもらう処理を書いてもらう
- firebase: kaitoの開発用アカウントを利用してAuthenticationをやる
- UI(機能)の変更
- コードを修正できた方がよいので、PRぽくやる。
- コメント(Reply)が2種類になる
- Ownerと他人が可能: コードハイライトしてコメント
- Ownerのみ可能: コミット コードを修正して、差分を表示させるコメント
- クリックしたら現段階の最新コードが表示される
- 一番上のコードは、文脈を維持するために元のを残しておく
- 一番上のpostのコードはデフォルトで不変で、「最新を見る」ボタンを用意しておくと、上のpostを見た人が最新コードにすぐアクセスできるようになる。

相談まとめ
- morio: hackmdにOGPについて調べたことをまとめ
- backend&frontend: yamlで連携取る
- frontend: モブプロ
- firebase authenticationをkaitoが設定(分からないので調べておく)
- コードを修正できた方がいい → APIが変更になるので、フロントチームはAPI待ちの部分もある

### 3/15
- 現状の共有をしていく
- Figmaを見ながらhackmdの内容を共有し、イメージを作ってもらった
- 休む日の確認
- [スプレッドシート 編集可能リンク](https://docs.google.com/spreadsheets/d/1uN5uR3SpqiZu3D7lf8z4AqJKFoBO-JVYEN2WaxVfStI/edit?usp=sharing)
- 進め方
- 毎日午前 10:00 - 10:30 相談タイム
- 基本的にSlackのスレッドを使う(23卒の方のチャンネル), discordは通話するときのみ用
- 通話で決まったことはSlackかhackmdに書くようにする
- @kaito はdiscordにいるようにするので、通話したい人は入ってやりましょう(1人が集中できる人は無理にとはいいません)←ここは運用次第なので、やってみてアレならやめるノリで。
- SNSやQ&Aなら質問箱に近い？もしくはコード共有に的を絞るとZennに近い？
- 特にZennを意識していた(kaito)
- Zennのscrapと似てる?
- 発表では、「zennに加えてOGPの機能を追加して共有しやすくしました」という
- 現状のサービスとの比較、差分を提示することで新規性をアピールできる
- GitHub Reviewとzennのいいとこ取りができている？
- コード共有SNS
- めっちゃいい言い回し
- TikTokなら動画
- Twitterならツイート
- このサービスならコード
- コード(OGP)を見たときにすぐに見たくなる
- AtCoderなら問題名を見て、それを開くか否か決める
- ツイートに問題名と点数は書いておいた方がよさそう
- ツイートに含める
- kaito tateyama
- Terraformの設定をする
- リポジトリ作る
- CI/CD
- task
- golangの初期プロジェクト立ち上げ、directory構成
- のえ
- OpenAPI定義書を書く→taskやkaitoに見せて不備を修正する
- OpenAPIで設計する
- 一旦設計する
- 受け渡しはJSONにする
- おっしゃん
- Next.jsで初期プロジェクト立ち上げ
- TypeScript対応
- ESLint/Prettier導入

### アイデア発想
- 抽象度を高めることで、物事の本質を見抜き新しい発想やアイデアを得る
- 技術を一言で言えるようにすると良い
- 何が課題で、どう解決するかを明文化する
- +αで組み込む

### プレゼン勉強会
- プレゼンは
- 誰でも絶対に役に立つ
- 誰でも絶対に上手くなる
- 誰でも一生使い続けられる
- プレゼンのコツ
- 一番大事なことは**相手を動かすこと**
- 手段としてプレゼンを使う
- 常に聞く人のことを意識する
- 何を話せば楽しんでくれるのか、相手の興味、属性、世代、理解度を考える
- 結論から離していいのは、前提条件を知っている場合のみ
- なぜ、**この人**から**今**、**自分**は**この話**を聞く必要があるのか
- 全部でなくとも、１つでも入れると良い
- 共有出来ていない場合は、前段の話を20%くらい入れると良い
- 発表時間が90秒でも入れるべき
- 開発する時からプレゼンを意識すると良い
- できる限り早く準備を始めると良い
- デモ動画は必須で入れると良い
- 聞き手を意識したプレゼン

## 初回以降の流れ
- ある程度勉強期間を設けるのは?
- 誰が何を担当するか
- どこからスタートするか
- 段階的な目標地点を細かく決める
- ステップごとに成果物ができるのが理想

## 自己紹介
### o-xian(HN: おっしゃん)(本名：小野山翔大)
- フロント担当
- 九州工業大学 プロ研 副代表 B2
- フロント(React)
- サーバサイドの趣味でやる
- 絵を描ける(すごい)
- デザインが出来る

### 大森裕介(HN: うーたん)
- フロント担当
- 公立千歳科学技術大学 B2
- HTML/CSSから初めて色々やってる
- フルスタックを目指したい
- [portfolio](http://utan.php.xdomain.jp/)

### Shota IWAMOTO(HN: morio)
- フロント担当
- 慶応B4 卒論前
- AtCoder2000ちょい
- ハッカソンでフロント寄り
- 今まではVueをやってきたのでReactをやっていきたい
- 素のVueを触ってきた
- BlenderやUnityなどもやってる

### Hiroya ONOE(HN: のえ)
- バック担当
- 京都大学工学部情報学科 B2
- 深層学習の勉強をして, インターンなどに行っていた
- 最近Goに興味が移ってきて, 最近はWeb系にもに興味が湧いている

### Takashi MIMA(HN: task)
- バック担当
- 芝浦工業大学 B4
- 興味分野はWeb系とセキュリティ系
- 好きな言語はGo, 研究のためにPythonを書いてる
- 趣味は散歩

### kaito-tateyama(HN: かいと)(本名: 谷昌典)
- インフラ、バック担当
- 元東大 広島大学 B2
- インフラとバックエンド
- 音楽が好き
- Porter Robinson
- AWSをどんな感じで勉強したの？
- [この本](https://booth.pm/ja/items/1318735)がおススメ

## Fun
kaito
- Dockerfileの削減
- イメージサイズ削減ができた
- Dockerの説明をfrontに説明した
- 説明するのが好き
- SRE的には嬉しい

morio
- 一覧ページ
- わいわい実装できた
- チーム開発は短期間しかなかった
- 「最初の方は」
- 強い人とできた
- バックエンドやインフラがやってくれてるだろうと、思ってしまう
- 今やらんと迷惑かな？
- （途中からFUNじゃない）
- トップページのデザイン、共有ボタンの実装
- 許可を取らずに実装するのは？
- kaito) バックエンドもそう
- morio) フロントはユーザの目につく、
- 一番責任が重い？
- kaito) ホントはでざいん案からやるべき
- 本番環境へのデプロイ
- マイグレーションの更新
- やってみないと分からない
- Actions
- SNS
- デザイン、
- 初めて使ったフレームワーク
- Vueにしなかった理由、Nextの時代がきそう
- フロントのことで話が出来る
- 実装
- nextやべぇとなった

完璧主義なのが良いところ
SecHackで僕もめっちゃ助けられた
声をかけるとやってくれる

- 開発前日に要件定義の議論が出来た
- 「こういう話をもっと早くしたかった」
- これぐらいのラインが高い
- 何も出来ていないのに
- 人のことを考えながら行動できる
- f1-microだと厳しそう
- すぐに聞くの大事！！！←これ
- 自分で溜め込むと最終的に他の方の迷惑になる

技術面

-

コミュニケーション面

- 質問大事