いつも optparse-applicative ってどう使うんだっけって悩むのだけど、 philoponさんのエントリ を見ながらやるとトップダウンにコードを書けてすごくよかった。
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すごい。