日々精進

aikoと旅行とプログラミング

Bug Shooting Challenge #1 参加記 #mixi_BSC

IMG_7722.JPG (1.7 MB)

今回, 株式会社ミクシィさん(以下ミクシィ)開催のBugShootingChallengeに参加してきた。記念すべき第一回大会の参加となる。

BugShootingChallengeとは

名前のとおりではあるのだけど, Bugを潰そうぜ!というコンテストで, 真面目なものを引用すると,

 BSCはもともとCREグループが新卒エンジニア向けに行なっていた不具合調査研修をベースとしています。不具合調査研修については下記の記事にその様子が掲載されておりますので興味を持たれましたらぜひご一読ください。BSCではイベントを楽しんでもらうための工夫として、バグを仕込んだゲームサーバを用意いたしました。イベント当日は2人1組となって、このゲームサーバのログから不具合の原因を特定し、ソースコードの修正まで行なっていただきます。(引用元:https://medium.com/mixi-developers/intro-bsc-40ee02fc675d

らしい. あまりにも名前の通りなのだけど, バグを直して優勝しようということである.

参加記

午前

  • 起床チャレンジに成功する
  • すごい余裕を持って渋谷に着く
  • 渋谷開発し過ぎでは?
  • ミクシィまでは徒歩10min位かかるので余裕を持ってきたほうが良さそう
  • Registrationに成功する
  • ハッシュタグが #mixi_BSC なんだけど, 俺しかつぶやいてない
  • ホスピタリティが最高(無限に飲み物が得られる) f:id:bath_poo:20181117222756j:plain
  • 座学が始まる
  • 不具合調査の必要性
  • CREの話
  • 「心の準備はいいですか?」って聞かれるも, 全然良くなかった
  • まさかのストーリーが存在
    • 上司が冷たすぎる
  • 技術説明がはじまる
    • RubyやらRailsやらDockerやらをつかいます
      • Matzと写真を取る社員さん
      • Rubyのおはなし
        • Rubyは頑張ってください」というアナウンスと共に, 20分で始めるRubyへのリンクが貼られていた
      • Gitの説明
        • 人の気持ちを学んできたLinux Torvalsのお話
        • git challengeの紹介
      • Docker
        • VMとコンテナの違いみたいな
        • Docker Install Battleが始まる
        • 違うランタイムのあれが動くんだなあ
    • SQLのお話
      • SQL on Hadoop with Apache Hive
      • データってどんどん増える(ログとか、スナップショットとか)
      • そこでHadoopですよ
      • 分散処理基盤ですね?
      • 低コストでスケールアウト可能
      • ファイルベースなので生ログも行けるぞ
      • HiveはHiveQLっていう言語でいい感じに分散処理を書ける(SQL like)
      • Amazon EMR(S3のデータに対してEC2インスタンスクラスタで分散処理が可能)
      • Hadoop + EMRのハンズオンが始まる(!!)
      • 全然やったことないけどSQLっぽい感じでかける
  • ランチだ!!!
  • 隣の人のキーボードで遊ぶ IMG_7726.JPG (1.9 MB)
    • ちょっと欲しくなった

午後

  • いよいよ開始
  • ディスプレイ配布される
  • とりあえずslコマンドを使う
  • チームメイトのデスクトップが無限にきれい
  • docker-compose upチャレンジ
  • ローカルでGrafana動いていたせいでポートが競合して😇
  • なんとか環境ができあがる

    1問目

  • 頭が取れた
    • 何もできませんでした
  • 思ったより時間がなかったので, 回答を満足にかけなかった

2問目

  • ログとにらめっこをする
  • 違和感を感じる
    • 結果これが正解だった
  • これも時間が足りずまともにレポートを書けなかった

3問目

  • 実際にありそうなバグ(システムの穴)だった
  • コードをひたすら追っかける
  • 明らかにおかしい箇所があったので治す
    • 修正方法としては正解だった
  • どういう理由でそのバグが悪用されているかを調べる
  • ありがとうRubyMine
  • やはり時間が足りずまともにレポートを書けなかった

解説パート

  • git challengeのように全部が終わってからまとめて解説ではなくて, 1問目が終わったあとに解説, 2と3問目が終わったあとに解説という感じだった
  • それぞれ特性が違う問題で, 非常にやりごたえのある問題だった
  • 2, 3問目に関しては狙いをつけていたところが正解でちょっと嬉しかった
  • 完全にチームメイトのおかげという感じだった
  • 問題を解いたあとの僕

懇親会

  • はい料理が最高 IMG_7728.JPG (1.9 MB)
  • サーモン IMG_7729.JPG (1.7 MB)
  • 一番手前のやつは、友達も俺もよくわからん…って言いながら食べてた IMG_7730.JPG (1.6 MB)
  • 普段の256倍ぐらい人とコミュニケーションを取る
  • 久しぶりにあった社員さんとかとお話をする
    • データ分析基盤の話をした
  • みんな大体就活のお話をしている
    • 大学にはそんな人はいないので, 就活シーズンなんだなあとぼけーっと思う
  • DBに関するLTのようなものが始まる
  • 最後はソファーのとこにあつまって記念撮影(ISUni suwatte shashinwo toru CONtest)

感想

今回がはじめての開催となったBug Shooting Challenge. 結論から言えば非常に面白かった. 実際の現場でも起こりうる内容で, それの調査を行い修正だけではなくその根拠となるものの提示まで含めて採点対象だったので, より実務に即したコンテストだったように思う.

問題の配布や回答はGitHubを通して行われた. 特に回答は, その問題に対しての修正をPull Requestで提出することで採点(人力)されるという仕組みだった. PullRequestではこのバグが何故起こったのかを詳細に説明する必要がある. MVPになったチームのPull Requestを見たが, 非常に丁寧かつわかりやすい説明がなされていて流石だなと思うなどした.

今回はRailsを使ったアプリケーションだったので, もちろんRailsについての知識はたくさんあるに越したことはない. 更に言うと, 大規模なプリケーションを作成・運用していく上で必要な知識も得ることができる大変よいコンテストだった.

今回のように, ユーザーからの問い合わせを受けて調査する業務というのは日常的に行われていると思う. コンテストが終わってから社員の方に聞いてみたが, 実際の現場では長いものでは数日かかるようなものもあるという. 今回はコンテストだったのでそこまで重たいものはなかったが, 実際は粘り強く調べていく力も必要なのだと思った. また, コンテストはコンテストで程よい難易度に調整する必要があるので, 社員の方の準備には本当に感謝という気持ちです.

というわけで, 今後もきっとこのコンテストは続いていくと思うので, 是非多くの人に参加してもらいたいと強く思った(ミクシィさんはgit challengeとかTDD challengeとかいろいろおもしろいイベントをやっているので, 他のイベントも是非チェックしてみてください)