学んだことを記録する

普段の生活の中で、なんとなく気になって調べたりして、ちょっとのめり込んで少し詳しくなって、結局忘れてあとでまた気になって調べ直す、ということが非常に多い気がしている。

忘れてしまうこと自体が悪いことだとは別に感じていないんだけども、自分がどんなことを調べて生きていたのかを記録すると面白いのかもな、とふと思ったので、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並行ぐらいならばさほど混乱せずに追える人が多いと思う
    • スレッドが生みだす弊害よりと比べると、多少の混乱のほうがよほど受け入れられる

XXX is typing... for a long time

オリジナル: http://text.osyoyu.com/articles/6

チャットにおいて意思決定を行うことはままあることだ。そんなとき、タイピングが遅い人が全体の律速になっている、と感じたことはないだろうか？

Slack を始めとする多くのチャットツールには、発言フィールドの下に XXX is typing... と、今誰かが何らかを入力していることを示す機能がある。なんらかの意見がまとまりかかっているとき、結論を出す前に、入力中の人が発言を完了するのを待つのはよくあることだ。口頭での会話で、今まさに話している人を遮って結論を出してしまうことはしないのと同じことだ。

ところが、その XXX is typing... がなかなか消えないこともよくある。あるいは、タイピングの手を止めて消えたと思ったらまたすぐに点灯しなおす…… なんてこともあるだろう。入力している当の本人以外は今か今かとずっとチャットの画面を眺めているわけだが、なかなか発言は登場しない。飯どこ行きますか、みたいな話題でこれが起きると、重要性が低く即時性が高い話題であるだけに少しイライラしてしまう。

投下されるのが長大なメッセージ (*1) でなければ、これは単純にタイピングスピードが遅いことが原因であることが多く、正直どうにも根本的な解決が図りづらい。「速くタイピングしてくれ」と言えば速くなるわけでもないし、そもそも「あなたが遅くてみんな待たされてるよ」を遠回しにでも意味することはなかなか言いづらいわけだ。

まぁ、だからこそチャットツールの側でなんらかの解決を図ってほしい気持ちがあって、たとえば入力中のメッセージの文字数が出るだけでだいぶ「待たされてる感」は緩和される気がする。読み込み速度の向上に一切寄与しないプログレスバーがあるだけで心理的な安心感が得られるのと同じ理屈だ。

欲を言えば入力中の未送信メッセージもリアルタイムでチャットログに出てほしいところだが、そうなるとタイピングが遅い人が入力中のメッセージの一部を見て速い人が先回りする、という現象が起きることは想像に難くないので、なかなか導入するのは難しいだろう。実験的には面白いと思うけど。

どうなんですかねー

*1: 「私も駅前の大戸屋でいいと思います。ミーティングが終わった後に行くので、みなさんで先に行っていてください」というぐらいでも僕は長く感じるのだけれど、それは別の話だ

コンパウンドとガラコ

オリジナル: http://text.osyoyu.com/articles/5

ブーブーのワイパーをブレードごと交換し、フロントガラスにコンパウンドをかけ、ガラコを塗ってあげた。

ワイパーゴムは最後の交換が2016/5/4とほぼ2年前で、動かすたびにゴッ…… ゴッ…… と音を立てており、またフロントガラスも全く水を弾かなくなっていたため、小雨でも劣化したワイパーをコンスタントに動かし続けなければならない悲しい状況だったが、今回まとめてなんとかした。

ワイパーはなんとほぼ無音になり、洗車機に入れても乾燥後には拭けるほどの水滴も残らない良い感じになった。今すぐ雨の中でドライブしたい。

今回使った製品はこれ

このブログに写真を上げる機能を実装していないので写真はありません。

AtCoder やってる

オリジナル: http://text.osyoyu.com/articles/4

急に思い立って AtCoder やってる。ずっと前からアカウントは持ってて、初めてのサブミットは 天下一プログラマーコンテスト2012 予選A だったっぽい、ほんとに AtCoder できたての頃だ。

まあ実は2010年ぐらいから JOI の予選に出てみたり、AOJ やってみたり、蟻本を買ってみたり（今でもアリの問題しか理解していない）、CODE FESTIVAL みたいなコンテストにも参加してみたり、あるいは2015年のICPCの国内予選にも出てみていたりしていたが、特に結果にも実力にも結びついていなかったので、今回もまっさらな気持ちでやってる状態。DP どころか、深さ優先探索を書くのも微妙におぼつかない感じ。

あまり気負わず、一日に ABC を1セット解くぐらいの気持ちでやっている。あまりアルゴリズムやデータ構造の知識を要求されないこともあって、慣れてきた最近は D 問題まで自力で解けるようになってきている気がする（まだ8セットだけど）。

正の得点が取れたサブミットはこんな感じで仲間内の Slack に流すようにしてみた。

↑ ところでこの画像のサブミットは多分競技プログラミングをやっていて、初めて「このデータ構造を使えばいいのか！」とひらめいた問題（だと思う）で、解けた時かなり嬉しかった。累積和を使えばいい、と分かっただけなんだけど、これは楽しいですね。

主な言語に Java を使っているのも楽しく感じている一因なんだろうか。C++ よりも全然楽しく書ける。JVM の起動がめっちゃ遅いけど。Java も初めてなのでわりとググりながらやってる。

今のレートは 353 (灰色) だけど、近い内に 1200 (水色) ぐらいまで行けるといいな。

アルバムアートワークを探すやつ

オリジナル: http://text.osyoyu.com/articles/3

CD をリッピングした後の難儀な作業として、アルバムアートワークの設定というものがある。オリジナルのデータに近く、解像度の大きいものが欲しいわけだが、これを提供しているところはなかなかない。例えば Amazon はだいたい 350x350 程度で、これはスマートフォンの小さな画面で見るにしてもちょっと小さすぎるサイズだ。

そんな中 iTunes Store はなかなか良い仕事をしていて、提供しているアルバム数も多く、また画像 URL の解像度部分に任意のサイズをしていすることができ、適当に 100000x100000 みたいな値を渡してやると可能な限り大きな画像を返してくれる。

というわけで、 アルバムアートワークを探すやつ という iTunes Store から高解像度なアルバムアートワークを手軽に持ってこれるやつを作った。

アプリは React で書いて、Firebase Hosting にデプロイした。Firebase のドキュメントを眺めていたら使ってみたい便利そうな機能が多かったためこの構成にしたが、よく考えたらこのアプリに合うものが本当になかったのでとりあえずログインボタンだけ設置した状態。ログインしても何も起こらない。検索履歴とかを Cloud Firestore とかに入れても良いけど、その機能いる?

それよりもアニメイトオンラインショップなどの他のデータソースへの対応を進めたい。iTunes Store と違って API はなく、もちろん CORS の設定もないので、適当なプロキシーを Sinatra とかでシャッと書くと良さそう。

同人 CD にも対応できるともっとよくて、Tokusetsu みたいな同人サイトテンプレートや、そこからリンクされている SoundCloud にある XFD に設定されてるジャケットまで引っ張ってこれると最高っぽい。そんなところか。