How to Contribute

開発の流れ

1. Issueを自分にアサインする
   • 他の人と作業が被るのを防ぐ
2. 手元に最新のdevelopブランチをpullする
3. 適当な名前でブランチを作る
4. コード書く
5. 見て欲しいタイミングでPRを書く
   • 「この方向であってますか?」
   • 「ここどうすればいいですか?」
   • 「できました!」
   • etc...
6. 見て欲しい人をReviewerにする
   • 急ぎならSlackでメンションする
   • 見て欲しい人 =~ 元々そこを実装した人など

※ やろうとしている事に該当するIssueがない場合、直接PRを作ってもいいが無駄手間になる可能性があるのでIssueを作ってからのほうが良い

参考ドキュメント

• GraphQL Official Spec https://graphql.github.io/graphql-spec/
• Rails https://railsguides.jp/
• graphql-ruby https://github.com/rmosolgo/graphql-ruby/blob/master/guides
• RSpec https://relishapp.com/rspec/rspec-core/docs
• Vue https://jp.vuejs.org/
• Vuetify https://vuetifyjs.com/en/

全体を通して気をつけること。

• エラーハンドリングは完璧に行う
  • 黙って失敗するのは最悪、対処不可能
• その機能でトラブルが発生した際に対処が困難な物は作らない
  • 無いほうがマシ 参加者も運営も実行委員も等しくミスオペする

APIを作る上で気をつけること

1. アクセス制限について

情報へのアクセス制限を簡素にするため以下を考慮して開発すべき

1. 基本的に未ログインでは一切の情報にアクセスできない
2. 基本的にGraphQLからのみデータが取得可能
3. 基本的にデータ取得制限はreadable.rbに集約されている
4. 基本的にデータの追加・更新・削除はacl.rbに集約されている

具体的には

• GraphQLのQueryで値を返す際は Notice.readables(team: self.current_team!)
• Mutationの実行時は適当な位置で Acl.permit!(mutation: self, args: {})
• Mutationの戻り地は notice.readable(team: self.current_team!)
• 削除系のMutationの戻り地は少々特殊で notice.filter_columns(team: self.current_team!)

2. デフォルト値について

原則としてデフォルト値は設定してはいけない。
デフォルト値が設定されていると、開発時にどこでデフォルト値が設定されるかを考える必要がある。 デフォルト値が設定される可能性がある箇所はDBスキーマ・モデル・APIのインターフェース・UIなど複数あり中途半端にデフォルト値を作ると複雑になる。 デフォルト値を作るのはUIのみにするべき。

3. エラーハンドリングについて

意図しない挙動は必ずエラーハンドリングを行う。 e.g. case文のelseや一部のif文など

例外を発生させるときはRubyに元からある例外クラスを使わずに自作する。 UnhandledClassなどの汎用的なものが既に自前で用意されているなら、それを使っても良い。

例外を投げるときは原因が分かるような作りにする。 e.g. invalid value ではなく invalid value ("hoge hoge") など

その他

• レスポンスで配列を返した場合、原則として順序は未定義
  • 必要ならUI側で明示する