ISUCON10の予選に参加しました(そして無事予選敗退しました)

｢ISUCON参加したことないんで参加してみたいんすよね〜｣という友人と一緒に, ｢イスイスユカイ｣で出場しました. Go実装で結果は1695点, 無事に予選落ち. 例年, ISUCONに出る時はだいたい昼過ぎくらいに何もわからなくなって, 終盤は｢もうだめぽ...｣となり, 何も出来ずにお通夜状態になっていることが多かったのですが, 今年はなんとか最後まで戦意喪失せずに走り切ることができました(が, 予選は敗退しました).

最後まで走りきれたのもそうですが, Goで意外と(予想以上に)スルスルと読めた/実装出来たことも良かったですね. まあ, もっと複雑なアプリケーションになってくると苦戦するのでしょうが, 今回のISUCON10の予選くらいの規模感であれば普通にやっていける, と知れたのはほんのちょっと自信になりました.

やったこと

DB分割, schema変更, 後はnginxの設定書き換えたりとかをやりました. うち, 自分が手を動かしたのが以下2つ.

DB分割

｢なんかこれ, estate(物件)とchair(椅子)でJOINしているクエリなさそうじゃん?｣と気づいたので, 適当にコードを書き換えて, ホストのうち1台をproxy/appに, 1台を物件用/1台を椅子用のDBサーバにする, という構成に変更しました. 2台のサーバをMySQL用にするのはチームメンバーにおまかせ. やってみたら思ったよりスコアが上がって, みんなで｢ウケるw｣という感じになっていました.

schema変更

なぞって検索する機能で, 緯度経度を使っていたので, そのあたりの処理をGeometry型のカラムを追加してMySQLでいい感じにできないか? ということで, fixtureの変更とGoの実装をやりました.

あとは, ある物件について椅子が入るか? というのを判定する処理がだいぶ複雑だったので, door_long, door_shortカラムを追加して, イッパツで引けるようにしたりしました. 椅子のwidth/depthについて, 短い方が物件のdoor_short/長い方が物件のdoor_longより小さかったら入る, という感じでスマートに実装できます.

fixtureの修正は, 思考停止しておもむろにPerlのスクリプトを書き始めて(Go実装でやっているのに!!!)ガッとやったのですが, 感想戦で｢初期データを突っ込んで, MySQLにカラム追加して, よしなにデータ書き込んで, dumpした｣という話を聞いて｢それでよかったわ...｣と思ったりしました.

感想

最初にも書きましたが, 今回は最後の1時間前まで予選通過ギリギリラインに踏みとどまれたのが良かったですね(しかし, そこからのラストスパートが全然出来なかったので, そこは完全に実力不足). 今回は事前に(1回だけど)過去問で練習したので, やっぱり場数踏んでおくの大事だなと思ったので, もし来年もあるのならもうちっとちゃんと練習してから望みたいですね... 特にMySQLやnginxなど, ミドルウェアのチューニングが弱すぎるので, 感覚つかんでおけると良さそうと思いました. あとは, 今回はISUCON初メンバーと一緒にやった, という所で, 一応(毎回予選敗退ではあるものの)経験者である自分がいい感じにリードする必要がある, と思うのですがそういった所あまり配慮出来なかったのも反省点です... 申し訳ない.

あと, ポータル周りは毎回進化していて凄い! と思うのですが, 今回は特に, めちゃくちゃいい感じで大変感動しました. 質問をポータルで完結出来るのは大変体験が良かったです. 途中, 1台サーバーが動かなくなってみんなで青ざめたのですが, ｢動かないんスけど...｣という問い合わせを投げたらシュッと対応してもらえて助かったりしていました. あと, ベンチマークも実行したらじわじわスコアが上昇していくのが見えて, これがまた脳汁が出てきて... 最高...

例年, 運営非常に大変と思いますが, その甲斐もあってありがたい事に今回もとても楽しませて頂きました. 最後まで頑張れると感想戦も楽しいんだな, ということをようやく知ることが出来ました(?). 学びも多かったので, もし来年も開催されるなら次はちょっと力を入れつつ, 絶対参加したい!!! と思いました. 運営の皆様, 参加者の皆様, お疲れ様でした!!!

最近読んだ本

最近ちょっと仕事が忙しく, 疲弊気味だったので, ｢業務に活きそう重点｣ではなく｢面白そう重点｣で, Kindle Unlimitedで配信されている本をいろいろ読んでいました. 軽く感想を書きます.

情報なき国家の悲劇 大本営参謀の情報戦記

情報なき国家の悲劇　大本営参謀の情報戦記 (文春文庫)

第二次世界大戦において, 陸軍の情報参謀を務め, 後に陸上自衛隊の陸将補になった堀栄三氏の著書. 第二次世界大戦において, 突然情報参謀に任じられた筆者が, 如何にして情報分析に従事し, 米軍の侵攻パターンを予測するに至ったかについて振り返っている本です. 単純に読み物としても面白いし(戦後の, ドイツ駐在武官としてキューバ危機に対峙した時のエピソードが面白かった), 今に当てはめれば｢内情が見えない競合他社の情報分析｣と言えるので, そういった視点でも示唆がある本だと思いました.

血と汗とピクセル: 大ヒットゲーム開発者たちの激戦記

血と汗とピクセル: 大ヒットゲーム開発者たちの激戦記

｢ディアブロⅢ｣, ｢アンチャーテッド4｣など, 著名なゲームの開発の様子を関係者のインタビューを元に綴った1冊です. 個人的には数年前にハマって遊びまくった｢スターデューバレー｣も取り上げられていたのが良かったです. ゲーム開発も, 自分が従事するウェブサービス開発のようにエンジニア/プログラマーの働きが必要不可欠な職種だけれど, その働き方, 取り組み方などは違っている部分もあって, ｢そういう世界なのか...｣と感じることが出来ました. ｢スターデューバレー｣のように1人で作ったゲームもあれば, 大人数のチームで作ったゲーム, 成功したパターン, うまくいかなかったパターンなど, いろいろな事例が取り上げられていて, 日本の作品は1つもないけれど, ｢ゲーム業界の内情｣というか, その雰囲気を知ることが出来る良い本だと思いました. ゲーム好きには確実にオススメ出来る1冊だと思います.

他...

絶滅できない動物たち――自然と科学の間で繰り広げられる大いなるジレンマ

現代語訳　信長公記 (新人物文庫)

皇国の守護者（全）　１～９＋外伝集 (中公文庫)

...なんというか, かなり雑多に読んでいますね. 引き続き, ちまちま積ん読を消化していきたいと思います.

最近読んだ本たち

転生したらスプレッドシートだった件

転生したらスプレッドシートだった件

カクヨムから生まれた初の技術評論社の書籍, ｢転生したらスプレッドシートだった件｣を読みました. 著者は id:minemuracoffee 先生.

仕事でExcelやGoogle Spreadsheetをバリバリ使いこなしているぜ! という方には物足りない内容かもしれませんが, これから使い始める人, 或いは適当に(他の人が作ったシートを参考にしながら...)使っている人にとってはためになる知見が得られそうと思います. ラノベ形式なのでサクサク読める点もありがたいです. ラノベ形式なので(?), 登場人物たちが関数を技名のように呼ぶわけですが, カタカナで呼ぶのは最初｢なんとなくダサい感じがあるな...｣と思ったりしていました. しかし, よくよく考えると｢この関数を口頭で説明するときにはこう呼べばいい｣というのがわかって逆に便利(?)だ, という事に途中で気付きました.

...あと,お恥ずかしい話ですが, これまで例えば｢A2以降全て｣みたいな指定をするときに, A2:A1000 みたいなのをたくさん書いてましたが, これA2:Aとすると良い, というのはこの本で知りました...

個人的には, 索引というか, ｢この機能はこの章で取り扱っています｣という一覧があれば良かったかな, という気はしています. まあ, 自分の場合は電子書籍版(Kindle)で購入したので, それで検索したら良いのでは? という気はしますが...

外資系コンサルが教える 読書を仕事につなげる技術

外資系コンサルが教える　読書を仕事につなげる技術

同僚の, どなたかのブログで紹介されていて, 面白そう! と思ったところ, Kindle Unlimitedで読めたのでサクッと読んだ本.

著者は外資系コンサルの方なので, 書かれている内容が自分たちのようなエンジニアにそのまま流用出来るか... というとそうではないのですが, その元となる考え方とかは参考になりそう, と思いました.

例えば, ビジネス書において｢ビジネス書は狭く深く読む｣/｢教養書は広く浅く読む｣と良い, と紹介されていますが, これをエンジニアに例えるなら｢ビジネス書｣は言語やアーキテクチャの解説書籍(例えば, ｢初めてのPerl｣や｢エリック・エヴァンスのドメイン駆動設計｣など)は狭く深く, ｢教養書｣は例えば｢WEB+DB PRESS｣や｢Software Design｣などの雑誌, 或いは｢リーダブルコード｣など特定のテーマに沿った本として捉えて, こういったものは広く深く読むと良い... のかな? とか考えることができました.

後は, 割と本を読む時はなるべく全部読もうとするのですが, ｢2割だけ読めばいい｣と書かれていたのも印象深かったです. この辺りは, ビジネス書や教養書だけでなく, エンジニア向けの本でもそうだと思っていて, なんとなくわかっているつもりでも実践出来ていないのですよね...

ちなみに, ｢うまく2割を読む方法｣としては, ｢目次を見る→総括, 結論といった章があれば読む→これを踏まえて面白そうな章の冒頭を読む｣と進み, ピンと来なかったら手を出さない... という方法が紹介されています. 本, 買うと｢もったいない｣という気持ちで読み進めようとしてしまうので(いつも積んでるのに...), こういう考え方は試してみたいと思いました.

既に読書習慣が構築できていて, うまく本を通してインプットが出来ている人からすれば｢そうっッスね｣という内容かもしれませんが, そうでない人にとってはいろいろ気付きがある本なのかな, と思いました. そのまま真似をするのではなく, これを参考に仮説を立てて, いろいろ試してみる... という感じで今後の読書に取り組んでいけたらいいなー, と思いました.

他にも...

戦略思考コンプリートブック

人生は、運よりも実力よりも「勘違いさせる力」で決まっている

ざっくり分かるファイナンス～経営センスを磨くための財務～ (光文社新書)

クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?

反応しない練習 あらゆる悩みが消えていくブッダの超・合理的な「考え方」

去年から今年にかけて, 上記を含めていろいろ本を読んでいたのですが, 感想をまとめるのを忘れてしまっています. 読みながら/読んだ後すぐに感想とか書かないと, どんどん揮発してしまうので気をつけたいですね. せっかくなので折を見て読み返してみたいと思っています.

小ネタ: PerlのDateTime::Durationで日数の差を出すのはdays... ではなくdelta_days

小ネタです. Perlにおいて時間を扱うライブラリの1つにDateTimeがあります.

metacpan.org

DateTimeには, DateTime::Durationというパッケージがあり, これはある時間Aとある時間Bの間の"期間"を表すものです.

metacpan.org

さて, 今次のようなコードで2020年7月22日と, 2020年7月1日の間の期間(DateTime::Duration)を取得したとします.

my $dt1 = DateTime->new(
    year  => 2020,
    month => 7,
    day   => 22,
);
my $dt2 = DateTime->new(
    year  => 2020,
    month => 6,
    day   => 5,
);

my $d = $dt1->subtract_datetime($dt2);

...なんとなく, ｢じゃあ, ここから日数の差を出すならdaysか...?｣と思ってdaysメソッドを使うと, 次のような結果になります.

print $d->days; # => 3

結論から言うと, DateTime::Durationのdaysや, months/weeksなどのメソッドは, ｢より大きな単位に変換した後の余り｣を出すようになっています.

These methods return numbers indicating how many of the given unit the object represents, after having done a conversion to any larger units. For example, days are first converted to weeks, and then the remainder is returned. These numbers are always positive.

つまりこの｢3｣という数字は, 実際の日数の差17から, より大きな単位である週(= 7日)に変換した余りを表す, ということです: 17 - 14 = 3

実際に, 先の$dt1, $dt2の差となる日数を取得するには, 次のようにdelta_daysを使う必要があります.

print $d->delta_days; # => 17

更に余談ですが, DateTime::Durationにおいてdelta_系のメソッドはdelta_months, delta_days, delta_minutes, delta_seconds, delta_nanosecondsのみが提供されており, delta_hoursは存在しない点には注意しましょう(1敗).

｢Search Inside Yourself─仕事と人生を飛躍させるグーグルのマインド｣を読んだ

サーチ・インサイド・ユアセルフ ― 仕事と人生を飛躍させるグーグルのマインドフルネス実践法

ちょっと最近, 精神的な面(?)のコントロールが上手く出来ていなくて, そういったことを相談した時に紹介してもらいました. タイトルにもあるように, Googleで実践されている｢マインドフルネス｣のプログラムをまとめた本です. そのためのエクササイズとして｢瞑想｣が取り入れられていて, 瞑想というと｢なんとなく胡散臭そう...｣という印象を持つかもしれませんが, 学術的研究やその成果に基づいて説明が書かれているので, そういった意味での説得力がちゃんとある本だなと思いました.

本によると, EQ(Emotional Intelligence Quotient, 日本語では｢こころの知能指数｣と表現されている)というものが注目されていて, EQの恩恵としては職務遂行能力の向上やリーダーシップなどがあるそうです. そして昨今の研究により, EQは大人になってからも育てることができるということが判明していて, そのため欧米では社会人向けに, このEQを伸ばすためのセミナーなども開催されているそうです. 本書では, このEQを育てる入り口として, マインドフルネスを用いています.

最初は, ｢マインドフルネス瞑想｣という1人で行う瞑想からスタートして, 自分自身, 他の誰か, そしてチームへと, マインドフルネスを広げていくような形で構成されています. 基本的には, 序盤の｢マインドフルネス瞑想｣に基づいてエクササイズの紹介が続いていくので, 都合の良い所だけをつまみ食いするのではなく, 最初から(エクササイズも実践しつつ)読んでいくのが良いのかな, と思います. 今の自分のような, 少し自分自身のメンタルコントロールに苦戦しているという人は, 序盤だけ読んでエクササイズを実践してみる... という形でも良いのかもしれません.

あと, この本を読んでいて思ったのは, 自分自身もこれまで, 無意識のうちに本書で紹介されている｢瞑想｣のようなモノをしていたのかな...? ということです. 具体的には旅行で, 旅行中に交通機関に乗っている時や, 目的地に向かって歩いている時は, 結構瞑想に近い(?)状態になっていた気がするのですよね... なんというか, 良い意味で心をリラックスさせて, 気持ちを切り替える機会になっていたというか. 実際本書にも, ｢歩く瞑想｣というエクササイズが紹介されていますし... そういう意味では, 毎日の通勤時間もそういった効果があったのかもしれません.

昨今の新型コロナウイルスの影響で, 旅行(移動)が困難になっていて, そういう時間(機会)を作れなくなっている... というのは, 最近の精神的なトラブルの要因の1つ, なのかもしれません. あとは, ｢ずっと自宅で作業している｣ということもマイナスに働いているのかな, という気がしています.

ここ数ヶ月, 自宅 = 職場という状況になりつつあるのですが, そういった日々が続くと, どうしても自宅にいるだけで, 常に仕事に関する事が頭の中をよぎってしまう感じがするのですよね... なので, 仕事中はもちろんの事, そうでない時ですら, 仕事はうまくこなせているか? 同僚とうまくコミュニケーション出来ているか? そして期待に答えられているだろうか...? ということを, ずっと延々と考えてしまっている気がします.

こういった状況(?)に銀の弾丸が存在しないのは十分承知しているのですが, とは言え｢もしかして...?｣というヒントを得た気持ちになりました. 1日数十分の｢マインドフルネス瞑想｣であれば, やってみて, うまく行かなかったとしても悔いは残らない(?)と思ったので, ひとまず試してみようかな, と思っています. 暫くして, また効果などブログに書けたらいいな, と思っています.