構想

[yutokyokutyo]

背景

refs: https://mics-nagoya.jimdo.com/

現状のフロー

1. HPから申し込みをしてもらう(名前, LINE_ID, 自己紹介, 意気込みを入力)
2. 申し込みをいただいた情報をもとに管理者がフィルターをかけて良さそうな人だけLINEで友だちになり返答する
3. 管理者と参加者でLINEでコミュニケーションをした後、イベント当日に現地に来てもらう
4. 初回のイベントに来た人にだけLINE@(イベント情報等のメンバーへの一斉周知に使う)のアカウントを教えて友だちになってもらう
5. 2回目以降はHPにあるイベント情報をもとに現地に来てもらう？

5月 18日 (木), 午後7時 ～ 午後9時
場所	
名城公園テニスコート
地図
カレンダー	
bluebird14141414@gmail.com
説明	
場所
名城庭球技場
http://www.nago​yalawn.jp/acces​map.html

時間
１９時〜２１時

テニスです！
ラリー&試合をし​ていきます！

楽しく運動しましょう！！

目的

• 現状イベントの企画＆立案は管理者主体となっている。管理者がイベントを立ててユーザーに来てもらっているという構図
• しかしこの構図では人数規模が大きくなりすぎて管理者の負担が大きくなってしまっている
• そこでイベント管理アプリケーションを作ることで、ユーザーが自立して勝手にイベントを立てることができるため、管理者の負担がなく勝手にコミュニケーションして勝手に楽しんでもらえるようになる。
• したがって、管理者主体の構図からユーザー主体の構図に変えることができる

ページ候補

• ユーザー登録
• ログイン
• ログアウト(複数アカウントを持つことはないから基本ない？)
• ユーザー情報編集
  • プロフィール画像登録
  • 現在参加しているイベント
  • カレンダー
  • 退会
• イベント登録
• 編集
• 削除
• イベント一覧ページ
• イベント詳細ページ
  • 参加
  • キャンセル
  • 参加しているユーザー一覧
  • コメント欄

[yutokyokutyo]

イベント一覧ページ

[yutokyokutyo]

イベント登録ページ

• イベントタイトル
• サブタイトル

• イベント画像

• 場所

• 詳細

[yutokyokutyo]

ペーパープロトタイプ

ざっくりこんな感じかなぁ。

[yutokyokutyo]

追加したい機能

• 自分が参加しているイベント1週間前、前日、当日にはメールでイベント内容について送信
  • スマホのpush機能使いたい
  • https://ics.media/entry/11763
• Facebook or LINEでのサインアップ機能＆ユーザー情報連携

[yutokyokutyo]

GA

• 現HPのセッションを見るとスマホ使用率が約87%
• スマホ > レスポンシブ > PC で考えたほうが良さそう

[yutokyokutyo]

サインアップ&ログイン

サインアップ&ログインは鬼門だなぁ。

• 通常のサービスと異なるのは、ユーザーの登録には 審査 というプロセスが入ること
  • 審査: 団体のポリシーと掲げている大事にしてほしいことに共感できそうかどうか、長くこのコミュニティに属していくれそうかどうかのマッチングを見る
• そのため、通常どおりサインアップとログインを行うだけでは仕様を満たせないので策を練る必要がある。

ペーパープロトタイプ

サインアップ(応募ページ)

1. ユーザーは名前, メールアドレス, 自己紹介, 意気込みのコメントを入力して 応募 ボタンを押す
2. 管理者にメールが届きその情報を元に管理者が審査

• メールにはユーザーが入力した情報と認証用URLが記載

3. 審査通過後、管理者がメール内の認証URLをクリック

• このタイミングでDB(Authenicate Table?)にメールアドレスを保存

4. ユーザーに「OKだよ！」と承認メールを送信してサインアップ完了

ログイン

1. ユーザーはFacebook認証ボタンを押す
2. Facebookからは name, email, profile_image を抜き取る
3. Facebookから得た email と既にDBに保存してある email が一致しているかどうか確認

• AuthAPI::Facebook.email == Authenticate.email

4. true であればログイン成功

---

Facebook認証を使う理由

• 審査プロセスがあるため Facebook サインアップはできない。
  • なぜなら、Facebookサインップして情報を引き抜いたのに審査に通らずにログインできないという状況はユーザーにとって「なんかFacebook情報を引き抜かれただけなのでは...?」と不審感を抱かせてしまうため
• 最初からユーザー情報であるユーザーの名前やプロフィール画像をとっておけば、ユーザーによる文字入力や画像アップロードの手間を省けるため

懸念

• サインアップ時に入力していただいたメールアドレスとFacebookに登録しているメールアドレスが異なる場合にログインができない。
  • 現状この問題はサインアップ時に「Facebookで登録しているメールアドレスを入力ください」のような文言を書く or 問い合わせで対応

[yutokyokutyo]

• イベント一覧ページはホームページのホームで表示されるようにする。
  • ただしログイン済みのユーザーでないとイベント参加はできない
  • ログインしていないユーザーも閲覧は可能
  • 参加者一覧に表示する予定だったユーザーの画像は見られたくない人もいそうなのでログインしていない人は画像は見れないようにするといいかな。
• イベント作成もログインしていないとできない

[yutokyokutyo]

自分が参加しているイベント1週間前、前日、当日にはメールでイベント内容について送信
スマホのpush機能使いたい

• 現状は必要ないことが分かった。後々あるといいね案件。
  • なぜなら、初回イベント参加時に全体周知に使っているLINE@アカウントとのともだち登録フローが組み込まれているため
  • 通知に関してはアプリケーションを介さなくても、最低限現状のフローでまかなえているのでOK!

[yutokyokutyo]

設計相談メモ

• アプリケーションの作成はmodelが肝！modelがパリッと決まると他のViewやController部分も上手くいくのでまずはmodelの設計からやろう〜
• 登場人物をまず決める。リソース名、テーブル名、カラム名。
• 一旦手が止まっちゃうと慣性の法則で開発も動き始めるのが難しくなる。
• 本開発のメインディッシュであるイベントから作り始める！旨味のあるものからやっていくと他のものも楽しくなって結果的に早くていいものが作れる。
• 小さくゴール設定をして進めていくとよさそう。ゴールがないと走り続けることになっちゃったり見失っちゃったりしてしまうし、小さくゴールをきるとモチベーションが回復するのでオヌヌメ。よってPRベースで進めていこう。
• ユーザーサインアップ・ログインは結構難しそう
  • いろんな切り口からたくさん案を出してメリデメを整理
  • 日本語で事細かに 誰が何をする のステップを順に書いてみる
  • その中で要件を詰めていったりしてみる
    • 最終的に関わる人全員が幸せになるバランスの取れた案に寄せると良さそう
    • そのためにももう少しユーザーやシステム管理者とお話の機会を設けた方が良さそう。楽しそう！
• テストは網羅的にやらなくてもよさそう
  • Webアプリケーションの場合、フォームの実装をユーザーの満足度が100%で正しい実装とすることは難関。
  • 例えば、開始時刻と終了時刻の整合性が取れなかったり半角数字で書いてもらいたいところを全角で書かれてしまったりとか。諸々問題が出て来る。
  • そのような問題を起こる前に回避させるためにバリデーションやテストで担保するのが良さそう。
  • 今回の場合はイベント登録時にはテストがあると良さそう。

[yutokyokutyo]

主な登場人物

• Users
• Events
• Relationships

Users

• id
• name
• email
• description
• created_at
• updated_at
• activated
• activated_at
• activation_digest
• remember_digest
• password_digest
• reset_digest
• reset_sent_at

Events

• id
• titile
• sub_title
• created_at
• updated_at
• location
  • 経緯度? 住所?
• image
• date
• start_time
• end_time

Relationships

• id
• 誰が何のイベントに参加しているのか
• 誰が何のイベントを作ったのか
• created_at
• updated_at

[komukomo]

Relationships "誰が何のイベントを作ったのか" 🤔

[yutokyokutyo]

背景

• フォームは何も文字を入れないで送信するとDBには空文字が入るようになっている。
• そこでデータの存在の表現を「あり or 空文字」で表現することとした。

問題

• エンドユーザーにとってはデータの存在は「あり or なし」で判別できれば良いのだが、開発者にとっては「あり or NULL or 空文字」で判別しなくてはならない。
• 前提条件として、データが存在しないことを「空文字」か「NULL」かのどちらか一つに寄せると良さそうとまで考えられたのは良かったけど、問題は寄せる選択を「空文字」に置いてしまったことだった。
• データが空文字という状態は健全ではない。
  • なぜなら、ないというステータスを作りたいのに 空の状態がある というステータスになってしまい明示的でないため
    • 分かりにくいし気持ち悪い。恐らく将来的にアプリケーション側で複雑化する
  • なぜなら、DB内の処理は「あり or NULL」の方が「あり or 空文字」よりも早いため
    • 例として、ダンボールの中に入っているお菓子の数を数える場合に、 前者はダンボールの数を数えるだけでOKだが、後者は全てのダンボールの箱を開けてお菓子の存在を確認しなくてはいけない

解決

• テーブルは「あり or 空文字」ではなく「あり or NULL」をデフォルト設定とする。
• フォームを空で送信された場合の対処は、アプリケーション側で空で送信されないような対応を施す。

---

• 前提条件
  • 初めのモデル設計の制約を疎かにするとアプリケーション側で後々何回も条件分岐を書くことになり複雑化する
  • 逆によく考慮された前提条件がある場合は、アプリケーション側ではシンプルで綺麗な実装が可能となる。(属人化もしなさそう)
  • 極端な例として、アンケートで意見がない人を集計するときに なし という項目にチェックをいれた人と 特になし と答えた人を加算して集計しなくてはいけない状況はつくるべきではない
  • この状況は あり と なし の2択しか選べないように初めから制約を作っておくべき
• NULL制約
  • NULL制約を設定した場合、NULLをINSERTすると処理に失敗するようになる
  • 用途としては絶対に値が入るものに対して制約をかけることが多い。
  • Twitterのように投稿に紐づくuser_id が必ず存在するようなカラムに対して制約をかける
• 今は開発フェイスなのでまだ良いが、運用フェイズになってしまうとテーブルの構造はコロコロ変えられるものではない。ので今が大事！
• 設計は状況に応じて主観をどこにおくかを考えると上手くいく。インターフェイスを俯瞰して見れると間違いが少なくなりそう。

https://speakerdeck.com/twada/php-conference-2016