Rubykaigi Reception
- 1. 昼の仕事の要領で 段取り進めた 会議の裏方 RubyKaigi2009実行委員 受付/オペレーション担当 こしば としあき
- 2.
- 3. most important ギークじゃ なくても 尻込み不要
- 4.
- 5. about me TOSHIAKI koshiba こしばとしあき twitter:bash0C7 hatena:bash0C7
- 6. about me • RubyKaigi2009実行委員 – 受付/オペレーション担当 • RubyKaigi2009 LT – 「ローカル環境向けKey-Valueストアの紹介」 • 東京Ruby会議01 スピーカー – 「オフィスで踏み出すRubyの世界」
- 7. about me よろしく お願いします
- 8.
- 9. outline • RubyKaigi2009の「受付」 1. requirement 2. ext-design 3. int-design 4. implement 5. test 6. production
- 10.
- 11.
- 12.
- 13.
- 14.
- 15. 受付業務 外部設計 2009/06/13
- 16. 業務構造 ①一般・認証キュー ②一般・認証受付 ③名札 取り 特別・認証キュー 特別・認証受付
- 17. ①一般・認証キュー 一般・ 一般・認証キュー 認証 受付 １階~階段に並んでもらう？ ・将棋倒し防止のため流量制御必須 ・ピーク時は１階を蛇行 ・広さはどれぐらい？
- 18. ②一般・認証受付 一般・認 名札 一般・認証受付 証キュー 取り • 受付トランザクション流入数：1~5位 • 「みどりの窓口」パターン • 台帳は全員が同じものを持つ – ○：スケーリングと縮退が楽 – ×：チケット複製をすぐには発見できない – △：全文検索に時間が掛かる – ×：業務後バッチで統合（いつやろうか）
- 19. 認証時の参加者の流れ 受付 ①認証待ち ②空いたら受付 要員 受付 要員 受付 要員 ③名札へ
- 20. スループットを上げたい • 仮定：１受付要員：1分：3人 –5受付要員時：20分：300人 • 20分待ちで第１回一般チケットの人さばける • 台帳検索速度が多分ボトルネック – 探しやすいインデックス – めくりやすいインデックス • 大き目なインデックスシール • PC投入 – todo：何にインデックスを張るかを決める
- 21. 認証 • 通常系 –参加者からの「提示物」で台帳サーチ • 「提示物」 – チケット画面 – PayPalメール – PayPalで使ったメールアドレス • サーチキー：メールアドレス？ – 認証：ハッシュ値突き合わせ？ • todo：例外処理 – 提示物が無い時 – 台帳に無い時
- 22.
- 23. todoまとめ 1. 台帳のサーチ/インデックスキーを何にするか – メールアドレス以外にいいのがあるか？ 2. どんな属性を使って認証するか – ハッシュ値利用？ – メールアドレスがあればいい？ 3. 認証時の例外処理 – 対応手順を決める必要がある。まず案出し。 4. スピーカー、スポンサー、プレス等の受付要員数 – 1人で足りる？ スポンサー専用受付ある方がいい？ 5. 台帳統合バッチを実施するタイミング – どうにかします 6. どこに何列で並んでもらおうか 7. 名札はどこに置く？
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41.
- 42.
- 43.
- 44. challenge •主なもの 1.受付に閉じない 2. より広く見る 3. ノウハウまとめ
- 45.
- 46.
- 47.
- 48. Thank you for listening. ご清聴ありがとうございました