Re: Slackのスレッド機能をどう使うか
結論
- スレッド使うのやめよう
- スレッドで発言するならチャンネルに表示しよう
理由
比較したときにデメリットのが大きいと思う。
デメリット
- 他の人がスレに発言があったかどうかわからない
- 何してるのか見える、何に困ってるのかわかるという分報のメリットが消える
メリット
- 見た目スッキリ
1タスク1スレッドくらいならまだいいのかもしれないが(この運用やってる人いないからわからんけどたぶん良くないとおもう。後述)、当初の目論見である「1日1スレッドで日報まとめるといいかも？」というのは完全に間違いだったと思う。
と、ここまでは分報的なスレッドの使い方の話。このことを考えてるときに思いついた意見も書いておく。今度はスレッド全体に一般化したときの話。
slackのよさの1つは、subscribable で self-controlable であることだと思う。チャンネル上での発言は基本的に全部通知がいく。受信者は自分にとって必要なチャンネルを選択し( subscribable )、自分にとって必要な通知レベルでそれを管理している( self-controlable )。特に前者の「受信者が情報を選択する」というのが大事でこれによって情報の透明性というか組織の情報共有のレベルがあがると思っている。
一方でスレは subscribable ではない。通知の有無は発言したことがあるかどうかで決まるし、そのレベルはチャンネルに依存する*1。乱立するから「あ、これウォッチしなきゃ」と思って :eyes: とか打つのもダルい。というかやったことない。スレ内発言をチャンネルに表示するかは発信者の裁量になっている。
つまり上で書いた subscribable + self-controlable であるというよさがなくなるのでスレが日常化するのはよくないと思う
例外的に使っていいのは、チャンネルに表示するとき。これは subscribable + self-controlable であるというよさをそこなわず、一方で必要な情報を1つの発言へのスレッドとして保存できる。slackは発言1つに対してURLがつくので元発言のURLでスレッド全体を指せる。これは素直に便利なので使うといいと思う*2
というわけで改めて。
- スレッド使うのやめよう
- スレッドで発言するならチャンネルに表示しよう
いずれアンサーエントリ書いてみたいという気持ちはあったがまさか自己言及で実現するとは思わなかった
2017年4月振り返り
記録
total: 11407 minutes Rank Name Minutes 1 Ruby 4781 2 PHP 1333 3 Rust 1134 4 YAML 991 5 Git 602
雑感
記録から
全体的に時間減ってますね。これは後述。
Gitってなんだろ、と不思議だったのだけどvimでgitのコミットメッセージ開くからそれかなあ……。
たしかvscodeとvimをいったりきたりしてるときに一回vscode側で「コミットメッセージ用のファイルが変わってるから云々」みたいなメッセージが出てコミットできなくなったときがあって、裏で生き続けたりしてたのではないかと予想。とはいえその場合はwakatimeがactiveでないと判断してそんなに長い時間計測しないと思うんだけどなあ……。600分ってさすがに謎。
RubyとPHPはお仕事ですね。Rustはたしか4月頭あたりに入門して、httpライブラリ使わないでcurlみたいなの書くぞーって書いて、今度はHTTPSだ！っていうところでSSLめんどくさくて死んでるとこ。放置中。
記憶から
前半のことはこっちに書きました。
4月はなんかどーも全体的にやる気がなくて、お仕事もプライベートもあんまりちゃんとしてませんでした。
なんでだろって考えたときにまあいろいろ理由はあるんだけど、これは整理してあとで書くかもしれません。書かないかもしれません。
後半の目立ったイベントは、西日暮里.rbでのLTくらいだけどこれも訳あって資料非公開なので特に書くことがありません。他の人のLTは楽しかったです。ReactとGraphQLの流れを感じました。
ほんとに書くことないけどそういう月があってもいいんじゃないでしょうか。予言ですが4月末にゼルダを買ったため5月はめちゃくちゃ活動量が減る予定です。
2017年4月12日
最近ブログ書いてなかったから適当につらつら書く
pero
最近よく使うやつ。上の記事ではリリースされてない感じですがもう brew から入る peco にも入ってます。
用途としてはざっと該当箇所のコードを読みたいときに適当に検索してる。
インクリメンタルサーチなのでファイル構成とかクラス構成を把握してないようなときに便利。あと Ruby で include, extend してるけど結局実装どこだよというときにもよい。
ラッパーは微妙に変えてる。 less じゃなくて vim のほうがいろいろなれてるので。うっかり編集しちゃうのはご愛嬌。
#! /bin/sh
exec ack "$@" . | peco --exec 'awk -F : '"'"'{print "+" $2 " " $1}'"'"' | xargs -o vim '
これの何がいいって、「メソッドAしらべる」→「どうも実際の処理はメソッドBっぽいな」っていうときにすぐ検索対象を変えられるとこ。めっちゃ便利。たぶん他の人はctagsとかつかってジャンプしてるのかしら
ack つかってるけど ack のオプション全然覚えてないから変えようか迷ってる。
とりあえず pero --ruby '.*' lib みたいな感じでつかってることが多いです。
hkdnet.netのアレ
go 部分と js 部分を完全に分割した。あと go から html とかサーブしてたのを nginx に変えた。そしたら go のバイナリと public ディレクトリ内をまるっと更新すればいいだけになったので ansible で置いて適当に supervisor を restart すればデプロイが完了する。楽。
api サーバとして動くコードと1日1回バッチ処理を行うコードがあったんだけどそれも完全に分割して2バイナリ生成するようにした。管理がめっちゃ楽になってよかった。
ただなんとなく ansible が好きになれないので mitamae とか使いたい感じがある。
技術書典2
湊川さんのところで店番してた。なかなかない経験で楽しかった。本もいくつか買ったけど積んでます。すみません
Rust
書いてる。これを読んでテンションがあがったあとに Rebuild.fm で typester さんが言及してたので。
六本木ではたらくソフトウェアエンジニアへのよくある質問とその答え (FAQ) (2015 - 2017) — hayato.io
なんか書くかーと思って自分で tcp コネクションを張って自分で http のプロトコル書いて読むやつ書いてる。まあ curl ですね。
適当に実装して HTTP はしゃべれてるっぽい気がするんだけど https は handshake とかあってめんどくさ！！！ってなって投げてる。
これのあとに GitHub の API 叩くコード書いてるあたりでエラーの扱い方をようやく学んだ。面白い。
Rust 自体の感想としては、オブジェクトがメモリ上でどういう風になってるのかを意識させられる感じがある。そこがつらくておもしろい。
「全然わからない。俺達は雰囲気で C++ を書いている」という感じがあったけど Rust は 「雰囲気ですら書けていない」という感じ。コンパイル通らんし。
コンパイラが出すメッセージがかなり親切で「もしかしてこうじゃない？」って言ってくるあたりほんと賢い。
コンパイラに叱ってもらって関係ありそうな節を Rust book で読んでというトライアンドエラーをしている。叱責駆動の勉強。
ほんとに親切なんだけど一方でわかってんならよしなにやってくれという気持ちもあってそういうところは人間が機械に傅いている感じがあって趣がある。また数年後にはこのあたりが解決される新言語あるいは新バージョンが出るのだろうか。
curl 代替を書いているときにヘッダーも書いて1行あけてボディなくて、でなんか読み出しできねぇ！みたいなことがあってなんでだろーって感じだったんだけどボディが空のときに空行が必要だからでした。てへぺろ
あと RFC 読んでてはじめて HTTP は改行コードが CRLF なことを知った
Rust に対する不満は VSCode の拡張でフォーマットかけると Vim モードが解除されるとこ。Rust の不満じゃなくて VSCode の不満ですね。
Rubocop
0.48の変更がめんどくてあげたくないという気持ちがある
ますとどん
酔った。たぶんもうやりません。
追記
JSON Schema
2システム間においてやりとりするデータをJSON Schemaで定義しているものとして、JSON Schemaにはarrayのorder定義がない(と思う)のだから送信側がsortするかどうかに関係なく受信側は自身でsortする責務がある
— はくどー (@HKDnet) 2017年4月6日
のだろうか
@HKDnet Arrayはもともと、というかこの文脈だとJSON specか、で明確に順序付けされたものとして定義されているので本来はarrayを作る側 (送信側) の責務でソートするのが基本とは思います。で、値の内容までvalidateするJSON Schemaなんだからそこにチェックを依存
— WAKASUGI 5T111111 (@5t111111) 2017年4月6日
@HKDnet できればいいなと思うのはPropertyOrderの提案が出てることからもわかるんですが、JSON Schemaに限らずソート順はバリデーションでやることじゃないだろというのもあるんですよね。これあんま言葉にできないけど。コールバック関数いるだろうしどう実装するの都合もありそう
— WAKASUGI 5T111111 (@5t111111) 2017年4月6日
@HKDnet その上で、送信側と受信側がソート順という関心事を共有する手段を用意するのはそれはそれでめんどいので、相手のことを知らなくても少なくとも自分でソートできるならやっちゃってもいいのでは、というのが自分の意見ですね。これは責任の所在を曖昧にするけど現実問題都合良さそうってくらいの感覚で
— WAKASUGI 5T111111 (@5t111111) 2017年4月6日
@5t111111 うーん、たしかにJSON Schemaの範囲じゃないから、ってのはわかるんですが、2システム間の約束を文書化し明示し共有しテストしたいからJSON Schemaを使ってるわけで。すると約束の範囲外は未定義だと思って実装するほうが重複してるけど頑健なのかなあ、という迷いがあります。
— はくどー (@HKDnet) 2017年4月6日
@5t111111 似たような結論になりましたねw
— はくどー (@HKDnet) 2017年4月6日
という感じ。
2017年3月振り返り
記録
total: 13720 minutes Rank Name Minutes 1 Ruby 5424 2 YAML 1567 3 JavaScript 1319 4 JSX 461 5 PHP 460
minutesがやたら増えてんなと思った方はこちらの記事をご参照ください
雑感
記録から
えーと、Rubyistっぽいですね。はい。
YAMLとjsがなー。JavaScriptとJSXを合わせりゃ勝ってるんだけど。vimだとfiletypeみているのでこういうことがおきる。
wakaitime側の設定でfileytpeとかをサーバに送られた後に変換できるのでやってもいいかも。
今回の場合 language = JSX の場合に language = JavaScript とすればよさそう
えーと記録にないですがjupyter notebookでPython書いてます。
ゼロからはじめるデータサイエンス ―Pythonで学ぶ基本と実践
- 作者: Joel Grus,菊池彰
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/01/25
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
これwakatimeで記録できないんで結構めんどい……。
えーと曜日別で表示してみたんですけど曜日別のプログラミング時間がこちら。
金土日が少ないですね。金曜日はなんで少ないんでしょうか。どう考えても飲み過ぎですね。もっと進捗しろ
phpはjson-schemaでリクエストを検証するあたりをちょろちょろ書いてた。たのしい
記憶から
- SQLアンチパターン読了した
- 言語のしくみ読了した
- hkdnet.netで
- gomodoroつくった
- マイクロサービス群の結合テスト実施するためのなんやかんやをした
- 特定レポジトリになんかイベントがあると、その時点での該当レポジトリ群をとってきてdocker imageつくってデプロイしてDB叩く感じの
- 仕事でやったので非公開です……
- 週報はじめた
- 後述
- はじめてでかめのp-rをレビューしてる
- でかいと疲れるのでなんかいい方法ないかなーとすごく悩んでいる
- electronアプリに手を出し始めた
- これ↓に出る予定です
友人がpodcastをはじめた。↓
メインパーソナリティのガミさんってほうが友人です。
僕が言い始めた週報の話がしがないラジオep.3aで言及されてます。よければどーぞ。
fish移行した
おさかなさん pic.twitter.com/5r2vYcyHoD
— はくどー (@HKDnet) 2017年3月22日
以下雑な手順
- brew install fish
- cp ~/.zshrc ~/.config/fish/fish.config
- ひたすらfish化する
- このへんでfishにはいる
- fishermanをinstall
- 適当にfisher installする
/etc/shellsに追記chsh -s fish_path
ひたすらfish化でやったのででかめのトピックは以下。
export FOO=BAR -> set -x FOO BAR
anyenvがなんかダメだったのでがんばった。
anyenv init -は実は後ろに引数としてshell名をとれる。なければ$SHELLを見る。そのためfish移行時にはfishと明記しておかないとエラーがでまくる。せっかくなのでzshrcにも書くことにしたanyenv init - fish | sourceでいいはずなのだがなんかうまくいかなかったのでanyenv自体をupdate- それでもダメだったので、
anyenv init - fishの出力をなんとなく目で見る。ndenvのpath設定あたりで文字列内展開の書き方が間違ってたっぽい。いろいろめんどくさくなってanyenv uninstall ndenvしとく。dockerもあるし、ローカルのnodeのバージョンがちゃんと管理できなくて困ることはあるまい……
プロンプト変えた。fishなのでさかな。right_promptは最初gitブランチを設定してたんだけど、右端まで空白入るのがウザくて切った。手癖で git s(= git status) 打つようになってるから見えなくても特に問題ない
pecoは下に入力欄がくるようにした。そっちのほうが目線移動が少ない、というのを誰かの設定でみた。確かに。
hubのaliasは別にいらないかなって思って切ったままにしている。hub browseくらいしか使ってないしhub browseって打つようにしている。
移行した感想としては、特に変わらなかった。ターミナルでその場でシェルスクリプティングをすることがあまりなく、あってもfor文程度なので特に利点がない。逆にREADMEとかにあるスクリプトをコピペで動かすことができないのでいまのところ不満度のほうが高い。あっさりまた乗り換えるかもしれない。次にやるとしてもzshではなくbashにしようと思っている
懺悔
えー、最近の振り返りで使ってたツールですが集計ミスが発覚しました。
各レコードに対してminutesっていうカラムがあるんでそれで集計してたんですけど、minutesってのが実は「経過分数」じゃなくて「時刻表示の分」だったんですよね。
60 seconds -> 1 minute 3660seconds -> 1hour 1minute ( not 61 minutes )
2月末に発覚したデータロストとかじゃないからまだよかった……(よくはない)
1月の振り返りの時点で「コーディング時間おもったより少ないですね。もっと頑張らなきゃなあ」みたいな感想もってるのが笑える。ちゃんと気づけよw
3000分で少ないなって思ってましたが8000分になりました。はい。
2月は12000分弱なので実際1月は少ないみたいです。データ何日分かロストしてるけど
データの整合性については、えー、恥ずかしながらSQLで全件抜いたあとにgoogle spreadsheetに頼りました。エクセルで育ったもんで……。
実際値を見ながら仮説をたててなんかするってときにSQLはちょっとやりにくくて集計データがのこるスプレッドシートのほうが断然楽ですね。
データロストの対応については、昨日の分のレコードが0件だったらslackで教えてくれるスクリプトを書いてます。
というわけで過去記事を書き直しておきました。
