rubyISUCON4の本戦に@cnosukeさんと@k0kubunさんの3人で、「railsへの執着はもはや煩悩」というチームで出てきました。動画広告の配信だし、多分ベンチマークから攻撃のようなアクセスをされるだろうと思い、3台与えられたサーバ全部に対してアクセスさせるようにしました。Killerにunicornだのvarnishだのを殺されて辛い感じでした。反省とかISUCONの敵であるbenchmarkerの挙動をもっとちゃんと把握しておくべきでした。Nexus"とかいろんな端末のUAがあって「なんかbenchmarkerめちゃ凝ってるぽいなー」とは思ったのですが、まさかブラウザの挙動を模してキャッシュ機能とかまで備えているとは考えられませんでした。́ω`)(でも競技時間が8時間しかないので焦ってしまう...)おわり今年で学生は終わりなので最後の学生枠だったのですが、本戦まで行けて(一応)最終結果をFailせずに終われたのはよかったです。来年も出場したいので、社会人枠で戦えるようにちゃんと勉強していきます。ISUCONは競技中はずっと緊張感があり、とても楽しかったです。運営をしてくださった皆様に感謝しております。本当にありがとうございました。ruby去年のISUCON3にも参加してダメだったんですが、今年はISUCON夏期講習に参加してから、ISUCON4の予選に参加しました。学生枠「railsへの執着はもはや煩悩の域であり、開発者一同は瞑想したほうがいいと思います。」というチーム名で、id:cnosukeさんとid:k0kubunさんの3人で出場しました。ISUCON公式Blogちなみに、使った言語はRubyでした。開発環境まわりでやったこと各自で自分専用のインスタンスを立ち上げるm3.xlargeインスタンスが$0.4/1hくらいだったので、各自でインスタンス立ち上げてそこで開発/ベンチマークが終わったら、GitHubにプルリ投げて本番用インスタンスでベンチマーク走らせるってフローでやってました。GitHubのプライベートリポジトリを立ててそこでプルリ投げ合いながら開発することにしました。事前に3人で集まって練習した時は1つのインスタンスを3人で触っていたので、どこを変更したのかよくわからなくなってました。この方法で割と安全に開発が進められたと思いました。実装まわりでやったことerbをslimに置き換えた事前にISUCON2の問題を練習していたときに、erbよりもslimのほうが速かったのでそうしました。'/'はnginxで静的HTMLを返すようにしたトップページもslimで描画でしていたのですが、出力HTMLは変わってなかったのでnginxで生HTMLを返すようにしました。これと、他の2人がやってくれたvanishやMySQLのインデックスなどでだいたいスコアが8000点前後でした。反省点プルリ体制にしてたのに自分がミスったプルリを投げるときは手元で動かしたベンチマークの結果も一緒に貼って、ちゃんとベンチマークが落ちないことを確かめていたのですが、自分が/reportをいじった時のプルリでベンチマークが落ちていたのにメッセージに気づくことができなかったです。́Д`)ルール(というかツール)をちゃんと把握しておくべきだったベンチを走らせるときに、編集したinit.shが何故か適用されていなくて困惑してたら、土壇場になって--helpつけたらちゃんとオプションがあることに気づきました。学生枠4位通過で、本戦に参加できることになりました!!!やった!!!運営をしてくださった方々にはとてもお世話になりました。)ので、今年こそ予選突破するため(?)に夏期講習に参加してみました。会場は、LINE社のセミナールーム的な部屋でした。入り口がめっちゃ緑色だったり窓口?がすごく綺麗でした。お話LINE社の採用の話とか、ISUCONについてなどのお話がありました。次に過去問にチャレンジがあったのですが、その途中でもヒントとかテクニックの解説を聞けました。Nagano過去問にチャレンジISUCON3の予選問題に似ている感じの過去問を、その場で解くこともしました。自分ができたこと(&スコアに反映できたっぽいこと)は、apacheをnginxに置き換えるunicornのワーカ数を変えるmysqlにindexを貼るWebアプリ(sinatra)の実装を修正する使っていないところでSELECTを呼んでいたのを消すアイテム数を表示するためにCOUNTを呼んでいたのをMAX(id)に置き換えるくらいでした。途中途中で解説があって、めちゃ面白そうな話っぽかったのですが自分の作業が中途半端だったせいで話半分にしか聞けませんでした、残念。初期状態では1700点くらいのスコアが最終的に2500点位になったのですが、中の人は9000点超(!?)したなどを聞いてびっくりしてました。渋谷ヒカリエの裏らへんにあった、オサレなとこで懇親会までありました。久しぶりにピザとか食べまくりました。他にも、LINE社の中の方のお話を色々聞けて楽しかったです。コンストラクタの代わりにstaticファクトリーメソッドを検討する普通にクラスのインスタンスを生成するならばコンストラクタを使用するけれど、コンストラクタよりもstaticファクトリーメソッドを使ったほうが良いケースがある。staticファクトリーメソッドの利点staticファクトリーメソッドは、コンストラクタと違って名前を持っているため、仮引数の名前とかコメントだけに頼らずにわかりやすい。}staticファクトリーメソッドなら、新たなオブジェクトを生成することが必要ない。immutableなオブジェクトを生成したいときにも良いパフォーマンスが大幅に向上することもコンストラクタと異なり、メソッドの戻り値型の任意のサブタイプのオブジェクトも戻り値に使える。パラメータ化された型のインスタンス生成の面倒さを低減できる。7からはダイアモンド構文があるので、staticファクトリーメソッドじゃなくていいかも。protectedのコンストラクタを持たないクラスのサブクラスを作れない。他の普通のstaticメソッドと区別がつきづらい。of:getInstancenewInstancegetTypenewTypenewInstance()ってのはよく見る気がするし、メソッドチェーンぽくインスタンス生成できるのは良さげだと思った。コンストラクタパラメータに直面した時にはビルダーを検討するテレスコーピングコンストラクタ・パターンだと、引数の種類が多すぎると対処するのが大変。Beansパターンだと、生成の過程で不整合な状態ができてしまうことがある。Facts.builder(100).fat(50).build();ビルダーパターンはいい感じだけど、記述量が結構増えてしまうので引数が多い状況に使うのが良さそうテレスコーピングコンストラクタ・パターンやJavaBeansパターンよりはかなり安全。staticファクトリーメソッドは、たまに作っていたけど役割とか利点を理解していたわけではなかったので勉強になった。ビルダーパターンはRubyとかPythonのメソッドチェーンみたいに書けて、個人的にはめちゃ良いと思った。18.04で動かして、macOS上のCLionからデバッグする。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。