読者です 読者をやめる 読者になる 読者になる

Re: Slackのスレッド機能をどう使うか

hkdnet.hatenablog.com

結論

  • スレッド使うのやめよう
  • スレッドで発言するならチャンネルに表示しよう

理由

比較したときにデメリットのが大きいと思う。

デメリット

  • 他の人がスレに発言があったかどうかわからない
  • 何してるのか見える、何に困ってるのかわかるという分報のメリットが消える

メリット

  • 見た目スッキリ

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

というわけで改めて。

  • スレッド使うのやめよう
  • スレッドで発言するならチャンネルに表示しよう

いずれアンサーエントリ書いてみたいという気持ちはあったがまさか自己言及で実現するとは思わなかった

*1:たぶん。違ったらすみません

*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分ってさすがに謎。

RubyPHPはお仕事ですね。Rustはたしか4月頭あたりに入門して、httpライブラリ使わないでcurlみたいなの書くぞーって書いて、今度はHTTPSだ!っていうところでSSLめんどくさくて死んでるとこ。放置中。

記憶から

前半のことはこっちに書きました。

hkdnet.hatenablog.com

4月はなんかどーも全体的にやる気がなくて、お仕事もプライベートもあんまりちゃんとしてませんでした。
なんでだろって考えたときにまあいろいろ理由はあるんだけど、これは整理してあとで書くかもしれません。書かないかもしれません。

後半の目立ったイベントは、西日暮里.rbでのLTくらいだけどこれも訳あって資料非公開なので特に書くことがありません。他の人のLTは楽しかったです。ReactとGraphQLの流れを感じました。

ほんとに書くことないけどそういう月があってもいいんじゃないでしょうか。予言ですが4月末にゼルダを買ったため5月はめちゃくちゃ活動量が減る予定です。

足首をひねった

近況

足首をひねった。
月曜日に西日暮里.rbに参加した帰路、夜道で飛び出してきたタクシーにびっくり仰天、咄嗟に華麗なジャンプをしてかわしたもののあまりにも華麗すぎて酔った足がついていかず、結果として左足首が犠牲になった。
あー、これはたぶんヤバいやつですねと思って足の具合をみているうちにタクシーは走り去っていった。つらい
経過としてはとりあえず湿布貼って固定しておけばいいんでしょみたいな感じで対応中。昔何回もやったのでこのへんは慣れている

2017年4月12日

最近ブログ書いてなかったから適当につらつら書く

pero

blog.kazuhooku.com

最近よく使うやつ。上の記事ではリリースされてない感じですがもう 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 とかあってめんどくさ!!!ってなって投げてる。
これのあとに GitHubAPI 叩くコード書いてるあたりでエラーの扱い方をようやく学んだ。面白い。

Rust 自体の感想としては、オブジェクトがメモリ上でどういう風になってるのかを意識させられる感じがある。そこがつらくておもしろい。
「全然わからない。俺達は雰囲気で C++ を書いている」という感じがあったけど Rust は 「雰囲気ですら書けていない」という感じ。コンパイル通らんし。

コンパイラが出すメッセージがかなり親切で「もしかしてこうじゃない?」って言ってくるあたりほんと賢い。
コンパイラに叱ってもらって関係ありそうな節を Rust book で読んでというトライアンドエラーをしている。叱責駆動の勉強。

ほんとに親切なんだけど一方でわかってんならよしなにやってくれという気持ちもあってそういうところは人間が機械に傅いている感じがあって趣がある。また数年後にはこのあたりが解決される新言語あるいは新バージョンが出るのだろうか。

curl 代替を書いているときにヘッダーも書いて1行あけてボディなくて、でなんか読み出しできねぇ!みたいなことがあってなんでだろーって感じだったんだけどボディが空のときに空行が必要だからでした。てへぺろ
あと RFC 読んでてはじめて HTTP は改行コードが CRLF なことを知った

Rust に対する不満は VSCode の拡張でフォーマットかけると Vim モードが解除されるとこ。Rust の不満じゃなくて VSCode の不満ですね。

Rubocop

0.48の変更がめんどくてあげたくないという気持ちがある

ますとどん

酔った。たぶんもうやりません。


追記

JSON Schema

という感じ。

2017年3月振り返り

記録

total: 13720 minutes
Rank    Name    Minutes
1   Ruby    5424
2   YAML    1567
3   JavaScript  1319
4   JSX 461
5   PHP 460

minutesがやたら増えてんなと思った方はこちらの記事をご参照ください

hkdnet.hatenablog.com

雑感

記録から

えーと、Rubyistっぽいですね。はい。
YAMLとjsがなー。JavaScriptとJSXを合わせりゃ勝ってるんだけど。vimだとfiletypeみているのでこういうことがおきる。
wakaitime側の設定でfileytpeとかをサーバに送られた後に変換できるのでやってもいいかも。
今回の場合 language = JSX の場合に language = JavaScript とすればよさそう

えーと記録にないですがjupyter notebookでPython書いてます。

ゼロからはじめるデータサイエンス ―Pythonで学ぶ基本と実践

ゼロからはじめるデータサイエンス ―Pythonで学ぶ基本と実践

これwakatimeで記録できないんで結構めんどい……。

えーと曜日別で表示してみたんですけど曜日別のプログラミング時間がこちら。

f:id:hkdnet:20170402181239p:plain

金土日が少ないですね。金曜日はなんで少ないんでしょうか。どう考えても飲み過ぎですね。もっと進捗しろ

phpjson-schemaでリクエストを検証するあたりをちょろちょろ書いてた。たのしい

記憶から

  • SQLアンチパターン読了した
  • 言語のしくみ読了した
  • hkdnet.netで
    • https化した
    • 曜日別グラフ作った
    • 活動量とれてない問題に対応した
      • タイムアウト時間の延長
      • 日次でチェックしてとれてないときはslack通知
    • HTTPリクエスト時に日付をTZつきでやりとりするようにした
      • っていうか最初からやっとけ感ある
    • 月次サマリ出すようにした
  • gomodoroつくった
  • マイクロサービス群の結合テスト実施するためのなんやかんやをした
    • 特定レポジトリになんかイベントがあると、その時点での該当レポジトリ群をとってきてdocker imageつくってデプロイしてDB叩く感じの
    • 仕事でやったので非公開です……
  • 週報はじめた
    • 後述
  • はじめてでかめのp-rをレビューしてる
    • でかいと疲れるのでなんかいい方法ないかなーとすごく悩んでいる
  • electronアプリに手を出し始めた
    • これ↓に出る予定です

nishinipporirb.doorkeeper.jp

友人がpodcastをはじめた。↓
メインパーソナリティのガミさんってほうが友人です。

楽しくて仕方がないラジオ

楽しくて仕方がないラジオ

  • shiganaiRadio
  • テクノロジー
  • ¥0

僕が言い始めた週報の話がしがないラジオep.3aで言及されてます。よければどーぞ。

fish移行した

以下雑な手順

  1. brew install fish
  2. cp ~/.zshrc ~/.config/fish/fish.config
  3. ひたすらfish化する
  4. このへんでfishにはいる
  5. fishermanをinstall
  6. 適当にfisher installする
  7. /etc/shells に追記
  8. chsh -s fish_path

ひたすらfish化でやったのででかめのトピックは以下。

export FOO=BAR -> set -x FOO BAR

anyenvがなんかダメだったのでがんばった。

  1. anyenv init - は実は後ろに引数としてshell名をとれる。なければ $SHELL を見る。そのためfish移行時にはfishと明記しておかないとエラーがでまくる。せっかくなのでzshrcにも書くことにした
  2. anyenv init - fish | source でいいはずなのだがなんかうまくいかなかったのでanyenv自体をupdate
  3. それでもダメだったので、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で教えてくれるスクリプトを書いてます。

f:id:hkdnet:20170315010110p:plain

というわけで過去記事を書き直しておきました。