今すぐ 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 に設定されてるジャケットまで引っ張ってこれると最高っぽい。そんなところか。

つくば市に転入した

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

横浜市を転出し、つくば市に転入した。とはいえ、2014年からつくばに居住していたため、引っ越しはしていない。

横浜市には2004年8月から2014年3月の10年間近く住み、つくば市に引っ越した後も住民票を残していた。しかし、運転免許証などでつくば市に住んでいることの証明ができず、多少苦労していたため、学群を卒業したのを契機に住所を移した。

住民票を出してみたら「世帯主」の欄に自分の名前があり、妙な気持ち。記念に横浜市の住民票の除票の出してもらった。

転入に伴い、つくば市の住所が記載されているマイナンバー通知カードを発行する必要があったようだが、以前のマイナンバー通知カードを返納しなくてはならないようで、ここで引っかかった。現在は有効なマイナンバー（通知）カードがないという状態。

育った家族の世帯を離れるのは寂しい思いもあるが、新たな世帯主として心機一転やっていこうと思う。

ブログ再建した

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

いつもの発作が出て、ブログを新規に作り直すこととなった。

旧石器時代は FC2 ブログ、弥生の頃はWordPress blog.osyoyu.com 、そして近代に入ってからははてなブログ osyoyu.hatenablog.com を運用していたが、Web で食っていくならブログぐらいは自作してあるべきだな、との思いのもと、このたび Rails で再建を執り行った。

今さら Rails かよ、2018年だぞ、という内なる声はあったものの、今の自分が手癖でブログをぱっと作れるのは Rails だけだという現実もあり、とにかくササッと作って拡張していきます、ということにした。

てわけで、よろしくね〜