Bug Shooting Challenge レポート
株式会社ミクシィの主催するBug Shooting Challengeに参加してきました。ブログを書くところまでが遠足とのことなので、今日の反省をば。
Bug Shooting Challengeとは、サポートスタッフを通して知らされる顧客からのバグや不具合の報告を、調査し解決するというプログラミングイベントです。僕は前回のgit challengeにも参加して非常に楽しかった思い出があるので、今回も期待値高めでした。
申し込み時に課されたcurlやRailsの問題、当日までの準備として、docker, docker-composeのインストール、Git, Githubを使った課題の提出、そして、バグシューティングをはじめる前に解説されたサイド技術の数々など、Webエンジニアとして最低限知るべき総合的な内容が詰まっているイベントだなと競技前から感じられました。
特にインフラ系をほぼ触ったことがなかった僕にとって今日紹介されたサイド技術の数々はとても興味深いものでした。復習がてら少しまとめてみます。
1. Apache Hadoop
=> 分散ファイルシステム、および分散処理基盤。安価なハードウェアで分散処理ができるので、スケールアウトを低コストでできる。また、生のログなど、ファイルベースの構造化されていないデータを扱える。
2. Apache Hive
=>Hadoopで動作するデータウェアハウスと呼ばれるシステムHiveQLというSQL-likeなクエリ言語でHadoopの分散処理を記述可能。
3. Amazon EMR(Elastic MapReduce)
=> Hadoopクラスタの運用を面倒見てくれるマネージドサービス。S3上のインスタンスに対して、EC2インスタンスのクラスタで分散処理を実行できる。
4. Redshift
=> 分析用途に適した列志向のデータベース
そんな中今回使用されていたメインの技術はRuby on Railsです。
これは僕が初めて触れたWebアプリケーションフレームワークで、かつ最も長く付き合ってきた技術なので、まあそれなりにできるのではないかと思っていたのですが、あまりうまくいきませんでした。
というのも、バグを起こしているコードやその原因の特定までは明確に手順を踏んで到達できるのですが、そこからどのように解決するのかについての手数が少なく、時間内にあまり納得のいく解答を思いつかなかったからです。
おそらく、デバッグの方法はそれなりに言語化できるのに対し、修正の方法はあまり言語化ができず何をしたらいいのかが曖昧で、解決方法はいくつか思いつくものの、もっといい手段がある気がするという漠然とした考えに陥ってしまうという感じでしょうか。
思い返してみれば、普段の業務でも問題が生じた時に思いついたこといくつか試して終わっていた、なんてことがよくある気がします。そうしているうちに知識の偏りができてしまい、長時間触っているにも関わらず技術に対する深いレベルでの理解が足りず...という事になってしまったのだろうと大反省中です。
まだまだ勉強しないと!!
この記事が気に入ったらサポートをしてみませんか?