恐れ、または『天気の子』
最近、他人の言葉に押し流されないように必死だ。
感想を言語化するという行為は、他者の言葉に押し流される恐れとの戦いだ。 たまたま見た他者の言葉を自分の感情として発信してしまうのが怖い。そのことに気づかないのはもっと怖い。
他者の言葉を自己の感情だと勘違いしてしまうぐらいならば、いっそのこと口を噤んでいたほうがマシだという気持ちすらある。 あるいは「良かった」と言う一言にすべてを凝縮したつもりになって満足し、意味のないこの4文字をTwitterに流して忘れ去るのもそういった恐れに対する防衛機制の一種なのかもしれない。
いつまでもそれを繰り返したくはない。マルコフ連鎖と同等の知性には落ちたくない。 この恐れこそが、他者の言葉に押し流されまいとさせるのだろう。
『天気の子』は、そんな恐怖が大きい作品だった。 公開直後、多くの人が Twitter で「ゼロ年代のセカイ系を彷彿させる」「これこそ新海誠だ」との感想をたびたび見た。 己もこれら言葉に染まってしまうのではないか、そういう恐れである。
恐れは、言語化によって対峙できる。 今回の場合は、"自分が「セカイ系」や「新海誠」に特別な思い入れがなく、むしろそれらをよく知らない" という自覚によるものだと整理できた。 Wikipedia やニコニコ大百科の「セカイ系」のページを見ると、その定義や作品例がずらりと並んでいる。 その中には自分がよく知っているものもいくつかある。 しかし、そのいくつかの作品を同一のジャンルとして捉えたことはなく、「セカイ系」の概念は己の中で内面化されていない。
こんな自分が、うっかり「『天気の子』、完全にゼロ年代のエロゲのトゥルーエンドルートだった」なんて口走ってみようものなら、それは完全に自己を捨て、他者の言葉で飾ってみせようとする姿そのものだ。 それは避けたい。死んでも嫌だ。そうは言いつつも、第二の恐れが顔をのぞかせる。
それは、「知らないことを認める」ことを極端に怖がる気持ちだ。 知らないことについて、知らないことを認めるぐらいならば、その場でインターネットでパッと調べて、あるいは調べなくても少しばかり分かっているふりをする。 そんな欺瞞を繰り返してきた。
この「知らないことを認めたくない」第二の恐れは、第一の恐れとの天秤の関係にある。 『天気の子』の例で言えば、とりあえず知ったかぶって「完全にエロゲーのトゥルーエンドだった、新海誠やってくれたな……」と言うことだってできる。 そうすることによって、「知らないことを認める」恐怖からは逃れることができる。
それではいけない。 知らないことは知らないと認めなくてはならない。
だから、今日は他者の言葉を借りるのではなく、己が素直に感じたことを書いてみようと思う。
『天気の子』を見た時もっとも感じたのは、「東京へのコンプレックス」だ。
横浜生まれ・横浜育ち、実家は横浜の中心部まで10分もかからない、という環境で育った自分は、横浜に誇りを持っている。 心の底から最高の都市だと思っている。「横浜なんて実はだいたい山だよ」なんて、言わせたいやつには言わせとけばいい。 選民思想と揶揄されようとも、自己紹介するときに「横浜の人って絶対神奈川出身って言わないよね」と言われようとも、この気持ちは本物だ。
『天気の子』は、東京を舞台とした作品だ。新海誠の手によって東京の中心部は極めて詳細に描かれる。 ドコモタワーを頂上とした新宿、丁寧に描かれた田端駅。 10代の彼らが見る東京を、見事に描き出している。
いや、本当にそうだろうか？ 俺は「分からない」。この映画の中で描き出されている東京が、現実のそれとどれほど同期しているのか。判断がつかない。 なぜか？ それは俺が中高の時代を東京ではなく、横浜で過ごしたからだ。 東京…… いや、"東京" とはなんだろうか？ 距離にすれば25kmもない場所でで10代を過ごしておきながら、やはりそれでも東京のことは分からない。 渋谷や新宿に通う中高時代だったら違ったかもしれない。俺はそうではなかった。一番詳しいのは横浜西口五番街のことだ。
横浜は大好きだ。横浜は大好きだが、東京も大好きだ。首都高、東京タワー、丸の内。すべてが調和することなく、それぞれの美しさを誇っている。 数え切れないほど夜通し首都高でドライブしているし、夜闇にまばゆく光る東京タワーに何度も見とれている。 それでも、東京のことを知っているという自信はまったくない。
東京でバイトをはじめてもう5年になる。秋葉原、渋谷、恵比寿で働いた。新宿だって多少は分かる。いや、それさえも強がりだろうか？ 大ガードが何度も描き出されるのを見て、親近感を覚えたつもりになったかもしれない。 しかし、物語の重要な舞台である代々木や池袋、田端については、本当に何も分からない。多分下りたこともない。池袋にラブホ街なんてあったんだ。
東京で『天気の子』を見た多くの人も、そうなのかもしれない。 だが…… だが、俺は知りたい。東京について、もっと知りたい。 『天気の子』を、見たことがあるかもしれない風景の集合ではなく、身近なところで起きた物語として見たい。 帆高が東京を駆け抜ける時。夏美のバイクで逃走劇を繰り広げる時。 「東京のことを、俺は結局何も知らない」という気持ちが刺激された映画であった。
来年からはいよいよ東京に引っ越す予定だ。 仮に1年後の俺が『天気の子』を見たとしたら、何を感じるだろうか？ まだ東京のことなんて何も分かっていないだろうか？ あるいは、まるで地元の出来事のように感じるだろうか？ それはまだ、分からない。
ISUCON 9: チーム「ソレイユ」の5年目、はじめての予選通過
ISUCON 9 予選にチーム「ソレイユ」 (@osyoyu, @KOBA789, @s4ichi) で参加し、28位で予選初突破を果たしました。 このメンバーで ISUCON 5 から予選への挑戦を続けていて、参加5回目にしてようやく本選への切符を手にした形です。
4度も予選敗退を繰り返しているうちに、ISUCON の本選に出場したいという気持ちは強くなるばかり。 時間の経過とともにメンバーのそれぞれが日常で取り組んでいる課題や業務の領域が ISUCON で扱われるそれに近づいているのにもかかわらず、思うような成績を残せないことに対する焦りを感じることもありました (ISUCON 7: 42位, ISUCON 8: 45位) 。 我々にとっては予選こそが ISUCON であるという状況は長く、本選は手の届かない夢の舞台、という感じです。 文章にしちゃうとちょっと格好悪いね。
そんなわけで、チームとして初めて予選を突破できたのは、大げさなようですが、悲願の達成そのもの、というわけです（他の2人も似たような思いをもっていると信じています）。 正直、どんな気持ちでいればいいのかまだよく分かっていないですが、とにかく楽しみな気持ちでいっぱいです。
さて、そんなことを書きつつ、5年前の我々はひどいものでした。
N+1 クエリを解消できないどころか SQL もろくに書けない、キャッシュと称してグローバル変数 $cache を導入する、途中で仮眠を開始する、競技終盤で飛び出す「で、Ruby ってどうやってデプロイするんだっけ？」*1。
こんな有様でも面白くて仕方ないんだから、ISUCON っていうのは本当に凄いですね。
転機は2017年、KOBA789 の就職とともにあったように思います。 メンバーの1人が学生でなくなったことで学生枠での出場権利こそ失ったものの、これはマイナスどころか圧倒的なプラスでした。
DWH チームで SQL をバリバリ書くようになった彼が N+1 クエリを手際よく倒していく様は、その前の年の状況を踏まえるとまさに感激もの。 時期を同じくして我々も同じ会社にアルバイトとして入社し、production レベルのコードやインフラを見る機会が一気に増え、それぞれの実力を伸ばしていきました。
しかし、ISUCON の参加者も年々増え、問題の難易度も上がり、逃げ続ける予選突破ラインを成長で追う我々、という構図がありました。 ISUCON 7 や 8 では top tier どころか 2nd tier にも入れないもどかしさを感じるようになり、次こそは……！ という悔しさは強まる一方。
こんな道を歩んできたチームなので、過去最大の規模であった ISUCON 9 において本選に行けるチームにまで育ったことを誇りに思います。 来月の本番では存在感を示せるチームでありたいものです。
さて、悔しさとか言いつつ、我々は昨年度までは事前準備をせず、実力ってやつに任せてとりあえず殴ってみるタイプのチームでした。 業務や研究を通じての成長でとりあえずぶつかってみる、というほうが適切でしょうか。
実力だけで予選を通過できたらそりゃ格好良いけど、そろそろ本選に出てみたいよね、真面目に準備すれば予選ぐらいは余裕で突破できんじゃない？ やってみるか、との空気がチーム内でにわかに高まり、各種ツールを作り込み、過去問を使った素振りを行いました。 無事その成果が発揮されてホッとしている、というのが正直なところです。
本音のところでは、これだけやれば予選もけっこう余裕で通過できるんじゃない？ なんて話もしていたのですが、結局 10,090 点 / 28位 とかなりギリギリでした。 今年の問題は過去最大級によく作り込まれていて、必死になりながら楽しめました。運営の方、ありがとうございます。
というわけで、これが今のところの率直な気持ちです。本稿の残りは事前準備として作り込んだツールのまとめです。
ソレイユとして出場した過去5回の予選は本当に楽しい記憶ばかり。 このチームで本選を戦えることを僕は本当に嬉しく思っています。出るからには勝ちたい、とも。
優勝するぞ！ 対戦よろしくお願いします！
ここからは事前準備の自慢記事。 一部、というか半分以上は @s4ichi の参加記 と @KOBA789 の参加記 (予定) に詳しいので、そちらも参照。
< ここに KOBA789 パイセンの参加記が入る予定 >
作り込んだツールを整理するとだいたいこんな感じ。
isumon
各ホストのリソースからベンチマークに返っている HTTP ステータスコードの割合まで、全てが一目瞭然になっている Grafana ダッシュボード。名前の由来は 社内にある InfraMonitor 略して imon をもじった isu + monitor 。そのまますぎ？
s4ichi パイセンの記事 に様子が詳しく書かれている。
isukekka
ベンチマーカーによるリクエストを検知して、ベンチマーク中の alp や pt-query-digest を自動で取って GitHub Issue にしてくれるかっこいいやつ。
そのうち KOBA789 パイセンによる詳細な解説があがる予定。
isukit
Itamae でまとめあげられたプロビジョニングキット。 ISUCON 8 で OS が CentOS であることが告知されたとき、慣れない OS でハマって事故死するよりは、ということでちょっとしたものを準備した。 これが割と便利だったので、今回は Itamae でいい感じになった。 isumon の各種ダッシュボードを含め、Slack とか Issue で夢を語っていたら @s4ichi パイセンがどんどん実装してくれて最高だった。
dotisu / 通称「実家」
我々のチームはすべてのコードの編集を本番サーバーで行う (ISUCON 7, ISUCON 8) 。 この「サーバーサイドプログラミング」スタイルにおいては、快適なターミナル環境を整えることはチームの生産性、ひいてはスコアに直結する。 しかしながら、1台のサーバーを共有しているがため、張っている alias や $PS1 が衝突して困るという問題もまたあり、昨年までは自分が割を食うという形で解決した。多分。
今年は自分の zshrc に寄せたものを作って素振りに持ち込んだところ、まあまあ強めの反発を食らってしまった。残念。 しかし我々はエンジニアなので、エンジニアリング™で解決することができ、これがその結果当日持ち込まれた ~/.zshrc 。
if [[ -n ${WATASHI} ]]; then
source ${HOME}/dotisu/${WATASHI}.zshrc
fi
SSH 越しに WATASHI 環境変数を送ると自分の zshrc が読み込まれる、という体験は大変好評で、「実家」「これじゃないと作業できない」「これだよこれ」などの喜びの声が聞かれた。 UNIX ユーザーの概念は、まだない。
mamiya.sh （デプロイスクリプト）
ソレイユ的にはおなじみ、デプロイスクリプトであるところの mamiya.sh *2 。 1台目で実行すると、2, 3台目に rsync でいい感じにファイルを撒いてくれて、全台でsystemd restart も行ってくれる便利なやつである。
本番中に書いても別に良いのだけれど、やっぱり事前に作ったやつを持ち込むのが精神的にも時間的にも楽。 ISUCON 8 予選で使ったバージョンの出来がそれなりに良かったため、ほぼそのまま itamae に投入。
MySQL 8 へのアップグレード練習
GA を迎える前から ISUCON でなんとか使おうとして、ビルド失敗、datadir 読めない、アプリからつながらない、と様々な失敗で時間を溶かした苦い思い出しかない MySQL 8 氏。
通算3度目の挑戦では、今回は確実なアップグレードを果たすために my.cnf を整えて準備し、叩くだけで MySQL 8 が入る itamae の cookbook も持ち込んだ。
default-authentication-plugin = mysql_native_password はだいじ！
MySQL 5.x の purge や新しい libmysqlclient を使うように mysql2 gem を再ビルドする必要があるなど、地味なハマりポイントが多いので手順書としてまとめておいた。 結果としては本番中に10分足らずで 5.7 を置き換えることができ、大成功であった。 MySQL 8.0 にしたことがどれほどスコアに直接響いたのかは計測していないのでわからないが、RDBMS に詳しい氏である @KOBA789 が MySQL 8.0 を散々褒めていたので良かったのであろう。
本番中に行ったチューニングについては @s4ichi の参加記 に詳しいので、そちらを見てください。
これは画像。
*1:これだけ2度めの参加のときの出来事
SKK 試しています
随分と長い間使っていた Google 日本語入力*1が信じられないほど厳しい変換（具体的な例としては「こういうかんじかな」→「こういう漢字仮名」だったり、「これがていばんなのか」→「これが定番菜乃花」「これが定番７日」）をするようになってきてしまったので、重い腰を上げて IME の見直しをすることにした。
その前に、自分のパソコンを使った文字入力スキルについて簡単にまとめておく（この文章は SKK の練習のために書かれているので蛇足が多いです）。いわゆるタイピングゲームで測定できる入力速度はだいたい 10keys/s 前後で、入力速度が遅くて困る、と思ったことはあまりない。プログラミングにおいては「実際にキーを叩いている時間よりも考えている時間のほうが長いので、タイピングスキルはそこそこで問題ない」とする言説をよく見るけれども、あれは完全に間違いだと思っている。タイピングで使っている指の本数は両手の人差し指と中指だけなので、これを増やすことができればもう少し上の領域に踏み込むことができるかな、と考えることはある。ぐらい。
で、本題。SKK を昨晩から使いはじめて、そこそこの速度で文章を入力できるようになってきた。今までパソコンで日本語を入力するにあたって、送りがなの位置など考えながら手を動かしていたことなどないので、ちょっとした脳トレ感がある。多少気持ちよくなってきた段階。しかし、まだ IME に意識を寄せないといけないので、長文を書ける域には至っていない。人間は脳トレしながら長文を書くことはできないのだ。
今のところ困っている (慣れで解決できない) 問題としては、Shift+英数字で一時的に半角英数モードに入れないこと (これは MS-IME スタイルの挙動だ) 。例えば「これはGoogleです」ならば koreha[Shift+G]oogle[Enter]desu で入力できていたが、SKK では Shift は漢字の開始にあたっているので、どうにもならない気がしている。困っています。今のところはいちいち英数字モードに切り替えていますが、例えばこの記事のテキストならば一度も日本語モードを出ることなく入力できていたので、地味にストレスだ。
自己紹介むずかしい
最近 DMM 英会話というやつの体験をやって、あまりにも難しく感じたことがある。
それは自己紹介。
講師「私の名前は〜。仕事は○○なんだけど、好きな映画は□□で、趣味は休日にサッカーをすることで、友達とロックバンドをやってるよ。他にも……（30秒ぐらい続く）」
ぼく「どうも osyoyu といいます、えーっと大学院でパソコンの勉強してます、うーんパソコンが好きです」
講師「Oh, sounds good. (おわり)」
という展開がつらい。どうして人の自己紹介は魅力的に聞こえるものなのだろう。
相手の属性が事前にある程度明らかになっていればもう少し話しようはある。例えば、相手がソフトウェアエンジニアであることが事前に分かっている場合は、最近気になっている技術要素などから話を展開していくことができるし、うーんそうですね、他に例はあまりないな。
髪を切りに行くときもなんとなく自己紹介的ななにかをすることがあるけれども、そういうシーンでも言えることがなにもないので、髪を切りに行くとき用の架空の人格に関する設定を話すことで切り抜けている事が多い。自分のことではないので、するする言葉が出てくる（別にそんなにたくさん話すわけじゃないので、そんなにたくさん設定を用意する必要があるわけではないが）。
（ここまで書いて思ったけれども、ただ単に自己紹介の機会が少なくて練習が足りていないだけという気がしてきた。DMM 英会話の講師は30分に一度自己紹介をしているわけだし、その過程でどんどんこなれていくわけで、そりゃ自己紹介で負けるわけだわ）
まあ、いずれにせよ、汎用的に使える自己紹介文を準備して、来たる自己紹介の刻に備えたい。自分でそれをできていればなんの苦労もないので、なんか僕が使えそうな汎用自己紹介パーツがあったらみなさん教えてください、ということを言いたかっただけの記事でした。
学んだことを記録する
普段の生活の中で、なんとなく気になって調べたりして、ちょっとのめり込んで少し詳しくなって、結局忘れてあとでまた気になって調べ直す、ということが非常に多い気がしている。
忘れてしまうこと自体が悪いことだとは別に感じていないんだけども、自分がどんなことを調べて生きていたのかを記録すると面白いのかもな、とふと思ったので、Scrapbox にでも残してみることにした。
ということで、会場です https://scrapbox.io/osyoyu/
Scrapbox を自分用のメモとして運用しつつ、ある事柄について理解が進んできたらブログなどに文章としてアウトプットできるとプロセスとして良いのではないかな、と今のところ思っている。また、この記事のような感情的な内容は Scrapbox に記録することではなくて、最初から文章として出しちゃえばいいかな、という感じです。
この記事とは関係ありそうで関係のない最近の気持ちとしては、もっとこなれている英語の文章を書けるようになりたいという気持ちがあって、ある程度語彙のある技術的な内容については英語で書いてもよいのではないかな、ということがあります。ただ、無から文章を編み出すのは日本語でも結構難しいので、Scrapbox 的なのでネタを溜め込んでいけたら良いかな。関係ある追記になってしまいましたね。
ISUCON 8 出たそして負けた
ソレイユ (星宮いちご,霧矢あおい,紫吹蘭) (osyoyu, koba789, everysick) で ISUCON 8 に出た。
当日成果の出たアクションは霧矢あおいの中身である koba789 がまとめてくれているので、そっち参照。これは俺のエモ。 diary.hatenablog.jp
ソレイユ
この3人で出るのは4度目であり、今までの ISUCON の半分を戦ってきたことになる。ISUCON 5, 6 では散々なもので、誰もまともに SQL を書けず、グローバル変数に $cache を置いてみたり（POST が来たら全消し）、終了15分前に「で、Ubuntu に Ruby ってどうやってデプロイすんだっけ？」みたいな会話を交わしたりもした。
風向きが変わったのは昨年度の ISUCON 7 からで、突如チームとして機能するようになり、ペアプロをして事故なくコードを書き換えたり、アプリとインフラで作業を分担したりできるようになった。
これはなんとなく Git 使ってなんとなくマージ事故を起こして死ぬ、みたいなことをなくすようにしたのと、koba789 が退学就職し、業務で日々長大な分析 SQL を書くようになって、クエリのチューニングを一手に引き受けてくれるようになったことが大きいように感じている。
今回は osyoyu がインフラを引き受け、koba789 が SQL 書いて、everysick がバリバリ分析していく、という形だったと思う。コードは俺以外の2人がガンガン書いてて、俺は勝手に nginx や MySQL の設定をいじりながら、ペアプロと称して分かった顔をしながら眺める役をやっていた。3人で実装してもうまくマージできないことは既知の事実なので、これは結構良いやり方だと勝手に思っている。
27000
我々のスコアは結局 30000 の大台を超えられず、一番ハネた瞬間で 27000 前後止まりとなった。
今回は過去に参加した ISUCON と異なり、大きなやらかしがなかったという風に感じていて、そうなると何が足りないの? スピード以外なにもないよね、という話をした。実際今回は 17:35 頃になっても reservations 周りをロックフリーにするべく koba789 が奮闘していたが、間に合わず、終了10分後ぐらいに解を思いついていた様子だった。
この時間を稼ぎ出すことができればもっと上に行けると今は思っている。今年は必要なツールを全台に一発で Ansible で撒けるように用意しておいたが、まだ高速化の余地があったと（今年のインフラ担当としては）感じている。
（余談: apt 生まれ Ubuntu 育ちの我々としては、CentOS で ISUCON を戦うのは高地でサッカーをするようなもので、本番で消耗しないように Ansible Playbook を用意しておいたのだが、本番で時間を稼ぎ出すのに思い切り効いてしまったというのが実態。ちなみに Playbook を用意する過程で CentOS には慣れた）
Ruby, Go, MySQL 8
MariaDB の my.cnf でハマるのも避けたくて、今年も MySQL 8 を導入して今年も失敗した。昨年も 8.0 にチャレンジして無事環境を破壊したが、今年も無事 validate_password を踏み抜いて死亡した。結局 MySQL 5.7 に差し替えるまでの間、迷惑かけてみんなごめんな。
ところで、我々のチームは全員 Ruby のレベルはそれなりに高いはずで、小回りを効かせることもできるということで Ruby を選択し続けている（Go に浮気しかけた年も結局 Ruby に転向している）。しかし Go の初期実装のスコアの高さを見るとどうしても隣の芝が青く見えてくるのも事実で、スコアの団子を抜けるには Go 選んでもいいんじゃないかと思ったり思わなかったりもする。どうなんだろうね。全員 Go 書けるようになったわけだし。
総評
精進あるのみ
今すぐ Slack のスレッドを使うのをやめてほしい
オリジナル: http://text.osyoyu.com/articles/7
構造化されていないコミュニケーションである「口頭での会話」をテキスト化したものであるチャットに構造化の機能を持ち込むべきではない。
Slack のDM / グループDM / プライベートチャンネルは真に隠す必要がある情報を扱う場合以外で使うべきではない、という理解のもとで
- 一覧性に欠ける
- チャットを眺めているだけでは "N replies" と書いてある四角が見えるだけでどうにもならん
- 目の前で発生したスレッド以外発見できない
- ずっと Slack に張り付いていても、たまたま画面上に出ている範囲外で始まったスレッドを見つけられないのは異常
- この画面をスクロールせずに上の方にスレッドがあるのを発見できますか? 俺はできない
- この画像の場合は本当は上にスレッドなぞないが、ないことを確認するためにもスクロールしないといけないんですよ
- スレッド表示を閉じた後、発言が追加されたことを発見できない
- 一度発言していれば必ず通知が来るようになっているが、そうではないスレッドで唐突に重要な会話が発生していることを認知する方法はない
- 一度発言したスレッドで未来永劫通知が来るのもけっこう鬱陶しい
- 一度発言していれば必ず通知が来るようになっているが、そうではないスレッドで唐突に重要な会話が発生していることを認知する方法はない
- 発言の主のみに届けば良いという見方もあるかもしれないが、それは結局 DM と同じではないか
- Emoji reaction も全く同じ性質を持っているが、重要度が全く違うので問題だとは思わない
どうすればよいか
- 口頭での会話と同じように、「そういえばさっきの話だけど……」と断りを入れれば良い
- 言及先（返信したい）発言の permalink を自分の発言の最後にペッと貼り付けてあげれば Slack がいい感じに展開してくれるので、それで十分だと思う
- 古典的だが、 "僕はこう思います > (言及先の話題)" 的なやつでもいい
- 話題が同時並行となってしまうことはあるが、2並行ぐらいならばさほど混乱せずに追える人が多いと思う
- スレッドが生みだす弊害よりと比べると、多少の混乱のほうがよほど受け入れられる