mixi bug shooting challenge #2 に参加してきた結果
「帰宅してブログを書くまでがBSCです」というコンセプトの元ブログを綴っています。（帰宅して2日目になるのですが許してください・・）
mixiさん主催のBug shooting challnege#2に参加してきました！今日は、始めて公に公開する予定のはてなブログを書いています。いつもこのブログには、言語仕様の理解をするためのラフなアウトプットツールとしてしか使っていなかったので、今回の記事をきっかけにもう少しはてなブログにも力を入れていこうかなと感じている次第です。
Bug Shooting Challengeとは
このワークショップでは、我々参加者が「釜飯ストライク」（モン◯ト的なゲームアプリ）というこのワークショップのために用意されたゲームアプリのバグを解決していく流れになっています。設定としては、カスタマーサポートを通してユーザーから来たお問い合わせを元に、そのお問い合わせで受け付けた事象について調査して、バグを発見→修正していくという流れになっています。
使用技術
・Ruby
→結構普段から使っている言語なので、割と楽しみにしていた。
→Webアプリ開発経験もあったので、こちらもRuby同様楽しみにしていた。
・Git
→基本的なコマンドの理解や、基礎概念的なところは理解している（つもり。。）
・Docker
→Dockerfileを読んでいる感じ、ベースイメージにLinux、RDBMSにはMysqlといった開発環境でした。
→また、最近ホスト環境と異なるアーキテクチャのコンテナ起動が可能になったらしく気になっています。。。
・Docker-compose
→docker-compose.ymlには、Redis、memchachedといったキャッシュサーバが定義されていた。（どちらか選択する形で、普段は使われている→役割としては一緒）
→Redisやmemchachedは、インメモリとして保存されるNosql。MongoDBの使用経験はあったので、なるほどNosqlでキーバリューで保存されるんだなといったレベルの理解。
Redisやmemchacedについてはこちらのリンクをご参照ください。（非常に参考になった）
ログ管理
この辺は、経験皆無でまた始めて触るものばかりでかなり勉強になったし、早く実務で使ってみたいなとか感じている。
→Googleが開発した分散処理が可能なデータ処理基盤（下記のリンクが参考になった）
・Apache Hive
→データウェアハウスでHiveQLというSQLlikeな記述で操作する事ができる。
・Amazon EMR
→hadoopクラスタのマネジメントが可能なマネージドサービス。
→S3上のデータを扱う。（下記のリンクが非常に参考になった）
分散処理して大量のデータ処理する基盤を作っていく、また運用していくみたいな流れは、現在多くの企業で取り入れられていますが、その周辺知識としては、下記のリンクが参考になると思います。（この記事は非常に簡潔にまとまっているのでおすすめです。）
午前中は、基本的に上記技術の簡単な解説と、環境構築で終了しました。知らない技術もあったので、楽しく学ぶことができました。
昼ご飯
なぜ今回のバグ解決に使うアプリの名前が「釜飯ストライク」と考えていましたが、昼食で釜飯が出てきてなるほどなぁ・・とw
昼からの流れ
昼からは、いよいよバグ解決に臨みました。合計で3問出されて、問題が進むにつれてどれも特定しづらいものでした。（諸事情あり問題の内容は公開できませんがw）
ちなみに、今回のワークショップは、2組みでチームを組んで、正当率の高さや、
正確なプルリクが出されているかなどで争う大会のようなものでした。
参加する中で意識したこと
・当たり前ではあるが、パートナーのエンジニアさんとしっかりコミュニケーションを取る。
・午前中からコミュニケーションを取っている中で、かなり経験年数に差があることを実感したので、なるべく自分のわかっていない点や、理解できなかった点は積極的に質問して教えてもらう。（理解できるまで教えてもらう）
・ユーザーのお問い合わせ内容に対して、また発生しているバグに対して、主観的にならず、客観的に処理できるよう、様々な判断材料を用意して、深く考慮する。（むやみに手を動かさずじっくり考えて手を動かす）
・発生したバグはどのような形で解決できるかを示す。修正しようとするバグに対して、根拠を示す。
今回のワークショップで学べた事
・サーバログや、フロントの挙動、ソースコード、DBの中身、様々な客観的事実を判断材料としつつ、どの部分に修正を加えるべきかを深く考慮する必要がある。
・主観的な判断はダメ。
・バグや、悪意のある第三者からの攻撃により被害を受けたユーザーにどういった対処を行なっていくべきかを考えて、実装する手法と共に提案をする。
・今回の使用された、技術やアーキテクチャの理解が大まかにできた。
・他人の書いたソースコードを早く正確に読む力の重要性について知ることができた。
総合MVPを取りました！！
パートナーの方が非常に経験豊富な事もありMVPを頂けました。
ソースコードの読む速さと、客観的な判断が重要でしたね。
バグ特定の考え方が学べたので、非常に楽しかったし、充実していた有意義な1日でした。
今回一緒に取り組んで頂いたパートナー
ぶち太郎というツイネは、Twitterを教えあった時に密かに笑ってましたw
PROPSの事も知ってくれていて嬉しかったです。
freeeeさんでのエンジニアインターン経験もあり、かなり優秀な方でした。
今回はありがとう！
