Slackのstarとmute、joinの使い方

最近チャネルが増えてSlackを見るのが大変だったので改善した。社内で投稿したものだが、設定を変えてから快適になったので紹介する。

変更前のチャネルの管理方針

重要っぽいかそうでないかでなんとなく分けていた。大事っぽかったらstarで、大事じゃないけど居ないと不審に思われそうなチャネルをmuteにして仕方なく居残るみたいな設定。

• star : 重要そうなチャネル
• starもmuteもしない : そんなに重要じゃない普通のチャネル
• mute : 一応、入ってるよってことを他の人にアピールはしたいチャネル
• leaveする : 抜けても他の人から怒られなさそうなチャネル

この方針で使っていて、未読が大量に溜まって読みきれないというe-mailのメーラーと似たような状況が起こっていた。それと、muteの設定で入っている部屋をまったく開かないので、もはやなんのために入っているのかわからない状態だった。

方針を明確にしてチャネルを整理

情報を得る、という観点でまったく別の角度から整理した。

まず、前提としてチームの Preferences の Advanced の設定で “My unread, along with everything I’ve starred.” に変更しておく。 この設定にしておくことが今回の方針で肝 になる。

チャネルの設定は、以下の定義に照らし合わせて機械的に決める。

• star : 発言することが多いチャネル
  • 次点として、過去ログを頻繁に読むチャネル
• starもmuteもしない : 全部の発言を読むチャネル
• mute : たまに発言を読むチャネル (特に、今、動きがあるかを知りたい)
• leaveする : 1つも発言を読む必要のないチャネル

この設定にしたおかげで、未読が溜まりすぎて読まずに既読にするといったことは無くなった。また、muteのチャネルも頻繁に覗くようになった。

どうしてこう決めたかの解説

まず、チャネルにstarをつけると常にリストに出るようになる。特に発言数の少ないチャンネルの場合、"My unread, along with everything I’ve starred.“ の状態ではstarしてなければリストから消えることが多く、チャンネルリストから検索しないと発言できない。ので、starにしておくと捗る。過去ログを読むことに関しても同じ観点での判断。

逆に発言をしないチャネルは読むだけなので、starにする必要はない。新しい発言があれば勝手にチャネルリストに上がってくる。そうすると、既読の管理や All unreads タブで見えるかどうかが次の判断材料となる。既読が管理されているということはすべての発言を読む気があるという意味。

muteにすると、発言があった場合に白字ではないが灰色の字でチャネルリストに上がってくる。動きがあるかを知りたいだけであればこれで十分である。その代わり、 チャンネルリストを目視する時に灰色のチャネルの存在も無視しないように注意する 、という習慣が必要となる。muteのチャネルが未読でリストに上がってくるときの色は非常に暗く目が勝手に無視してしまいがちなので、これは意識的にやらなければならない。

ということで、情報収集ツールとして「チーム全体がどういう動きをしているのかをなんとなく知りたい」という観点だと、muteでjoinするチャネルが増えるのかなと思ってる。滅多に読まなくてもちょっとでも発言を読む可能性があるのであれば leave するのはもったいない。

VS 2017でrustを使う

Surface Studio に rust をインストールしようと思ったんだけど、 Microsoft Visual C++ Build Tools 2015 が要るらしい。せっかくなので Visual Studio 2017 使おうと思って探したんだけど、パッケージングの仕方が変わってるぽい。

まず、 このエントリ の説明に沿ってbuild tool相当のコンポーネントをインストール。

でもって、 https://github.com/rust-lang/rust/issues/38584#issuecomment-285879556 で言われているように "x64 Native Tools" 経由でプロンプトを立ち上げて、そこで rustup-init.exe を実行したらインストールすることができた。もちろん、 rustc コマンドなどを叩くときも "x64 Native Tools" 経由で叩かなければならない。

rustup-init.exe や rustc が VS 2017 へ対応されるまでのワークアラウンド、だと思う。

Alternative preludes

Alternative preludes – Haskell – Aelve Guide

Preludeの代替品の評価。どれも一長一短感ある。

自分のモチベーションはpartial functionよりも Text なんだけど、 Text にまとめたいと思いつつも、結局パッケージを使う以上は現状では String からは逃れられない運命であって、それならそんなにパフォーマンスに寄与しない短い String はそのままでもいいのではってなる。結果、でかい文字列だけ text パッケージで扱えばいいので Prelude でも十分ていう。

textlint の導入

textlintで日本語の自動校正サービスを作ってみた！ | それいけ！フロントエンド

以前面倒だと思ってやってなかった textlint だけど、こちらのエントリの通りやったらさくっと動いた。

ざっくり手順。 npm の作法を知らないのが怖いところだけど、まあ、オプションまで含めてそのまま実行したら動いているので、多分大丈夫。

$ curl -L git.io/nodebrew | perl - setup
$ echo 'export PATH=$HOME/.nodebrew/current/bin:$PATH' >> ~/.bashrc
$ exec $SHELL -l
$ nodebrew install-binary v7.7.3
$ nodebrew use v7.7.3
$ npm init --yes
$ npm install --save textlint
$ npm install --save textlint-rule-preset-ja-technical-writing spellcheck-tech-word-textlint-rule
$ vi .textlintrc
$ vi package.json
$ npm run -s lint    # 直前に package.json に登録した内容

package.json はこんなの。

{
  ...
  "scripts": {
    "lint": "textlint */*.md",
    "lintfix": "textlint --fix */*.md",  
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "dependencies": {
    "spellcheck-tech-word-textlint-rule": "^3.0.0",
    "textlint": "^7.3.0",
    "textlint-rule-preset-ja-technical-writing": "^0.1.3"
  },
  ...
}

.textlintrc はこんなの。

{
    "plugins": [
        "textlint-rule-preset-ja-technical-writing",
        "spellcheck-tech-word-textlint-rule"
    ],
    "rules": {
        "l-writing/sentence-length": false,
    "textlint-rule-preset-ja-technical-writing/sentence-length": false
    },
}

動くようになったので、後は好みの挙動にカスタマイズすればかなり便利に使えそうかな。

Server::Starter を利用できるサーバの実装

http://qiita.com/hiratara/items/2dacf8470c378b130d5c に書いたとおり。

下回りが苦手なので色々調べたのだけど、今回もGREEの https://github.com/gree/haskell-prefork なるリポジトリが役に立った。 fork するだけじゃんと思って中を読むと、環境変数仕掛けた上で createProcess 使って自分自身を再度立ち上げる と言った涙ぐましい実装をしていたりする。古い unix パッケージの forkProcess のマルチコアで動いているとフォークできないみたいな制約を嫌ったのか、もしくは別のハマりどころがあってこんな実装をしているのか。

今回一番ハマったのが O_NONBLOCK にしないといけないってことだったのだけど、先のGREEのパッケージの例だと元のファイルディスクリプタも Haskell で作っているので問題にならなかったのね、きっと。ちなみにその問題は、 waiのこのissued を見て解決した。

以前 Test::TCP 的なもの探したときもGREEの https://github.com/gree/haskell-test-sandbox に当たった記憶がある。GREEすごい。

wai-graceful

wai-graceful の仕組みを眺めた。

warp 側に手を入れずにどうしてるのかと思ったら forkIO してサーバスレッドを別で立てといた上で、シグナル受け取ってからリクエスト捌き終わるまでメインスレッド残すのね。リクエストの処理が強制終了されることがないものの、シャットダウン中もリクエスト受け続けて 503 返し続けるのはどうなんだろ。リクエストを待ち続けていいのかも気になる・・・まあgracefulだからタイムアウトさせなくていいってのはあるかも。

そもそも warp ってシグナルどう扱ってるんだろ。

Windows 上での getChar のための no-buffering-workaround パッケージ

hiratara.hatenadiary.jp

エンターキーを押さないとキー入力を受け付けてくれない。大昔からチケットが上がっていて、

今日気がついたのだけど、Hackageにいい感じのパッケージが上がってる。

no-buffering-workaround: Workaround for GHC bug #2189.

使い方は initGetCharNoBuffering を呼んで ((ただし、こいつはNOP。UNIX環境だと NoBuffering を呼んでくれるので、その代わりに使っておくと良い)) 、 getChar の代わりに getCharNoBuffering を使うだけ。お手軽。

ただし、こいつで作った実行ファイルは msys2 上からはまともに動かない。PowerShellから叩くと、いい感じに動いた。