@kyanny's blog

My thoughts, my life. Views/opinions are my own.

Clarks Natalie

二十代の頃からクラークスのワラビー・ナタリーに憧れていた。けど、欲しい時にカネは無かったりして、買うこともないまま、欲しかったことをすっかり忘れていた。洋服のコーディネートに疎いので、スニーカー以外の靴を手持ちの服(ほぼジーンズのみ)に合わせられる自信が無かったというのもある。

ここ数年、靴は吉祥寺の TOPtoTOP で買っている。年に一回、二足か三足くらい買う。今年もそんな季節になったので行ったら、クラークスのナタリーが売っていて、ついに手に入れる日がやってきた。

ありがちな写真。

昔(から)憧れてて、といってもいい加減なもので、憧れていた靴の名前もろくに思い出せなかった(なぜかメレルのウッドストックを先に思い出し、クラークスのワラビーとナタリーの違いも知らなかった)

履きやすくて、大満足。定番のスエードのやつが最初は欲しかったけど、奥さんがレザーの方がいいよというので、奥さんのセンスに間違いはなかろう(俺より確実に良いことが実証済み)と、レザーを買ったが、やはり正解だった。店員もレザーは珍しいとかなんとかいって勧めてた。

ここ数年スニーカーといえば mobus をよく履いていて、それも買った。白にドイツ国旗の配色のラインが入っているやつ。

こっちはまだ履いてない。雪もだいぶとけてなくなってきたので、汚さなくて済みそうだから、今週どこかでおろしたい。

Slack のリマインダーのメッセージ本文を展開して一覧表示する Slack アプリを作った

Slack のリマインダー機能はもっぱら「メッセージにリマインダーを設定」する方法で使っている。書式が難しい /remind コマンドよりずっと使いやすい。自分自身への DM にリマインドしたい内容を走り書きして、そのメッセージにリマインダーを設定したりする。パブリックチャンネルに誰かが書いたメッセージにリマインダーを設定したりもする。

たくさんのメッセージにリマインダーを設定していると /remind list コマンドで一覧表示したときどれがどれだかわからくなって不便。

f:id:a666666:20180130041128p:plain

そこでメッセージ本文を展開して一覧表示する Slack アプリを作った。 /expanded-reminders というコマンドで呼び出せるようにした。やってみたらこれがなかなか便利。 Complete ボタンもつけてみた。

f:id:a666666:20180130041220p:plain

やりたいことがはっきりしていたので、Slack API のドキュメントをあちこち読みながらとにかく動くものを完成させることを最優先に、二日くらいで作りきった。コードはかなりやっつけ仕事だけど、飽きてモチベーションが消える前にちゃんと欲しいものが手元で動いてる状態まで持っていけた。

github.com

アプリ本体のサーバーは Heroku で動かしている。最初は ENV に access token をセットしていたけど、せっかくなのでアプリを配布して(再)インストールしやすくする方法を調べて access token は oauth2 のプロトコルにのっとって取得する形にしてみた。でも、サーバー側の実装が不特定多数の人に配布して利用してもらえるようにはなっていないので、 ENV で十分というか、むしろ ENV のほうがよかったのかもしれない。

ENV でちょっと不安だったのは、 Slack アプリを作成すると生成される Tokens for Your Workspace というやつの権限がどうなっているかよくわからなくて、自分以外の人がこの Slack アプリをインストールしたときに、すでに俺が自分で Tokens for Your Workspace を ENV にセットしているサーバーが共用されることになるので、俺の権限でリマインダーの中身を見られたら嫌だなぁ、という点。 oauth2 のフローで access token を取得してサーバー側に永続化すると明らかに俺の権限の access token が保存されるのでよりまずいんだけど、なので現状のサーバー側の実装では二回目以降の oauth2 認証時には access token を上書き保存しないようにしたりしている(このへんがやっつけ仕事の最たるもの)

Slack の API について学んだこと

  • Slash Commands を使うためには呼び出す API サーバを指定するが、この API サーバのレスポンスを JSON で返すと Interactive Components も出せる
  • Interactive Components の action button を使う際に Slash Commands と別のエンドポイントを指定する場合は、 action を POST する URL のレスポンスに Slash Commands で呼び出されたときのレスポンスを同じもの(ただし action の実行後の状態のデータ)を返すのがよい
    • Interactive Components でリマインダーの Complete ボタンを表示する場合、そのリマインダーだけ Complete になったので「未完了のリマインダー」の一覧を JSON で返してやると、 Slack の画面上では Complete を押したリマインダーだけがその場で消えたような見た目・振る舞いになる
  • 単一のメッセージの内容を取得するには conversations.history method | Slack のみを使えばよいが、 permissions は channels:history, im:history など個別に許可しないといけない
  • Slack アプリ内におけるメッセージの permalink は https://quipper.slack.com/archives/D18T55D5F/p1517205394000105 のような形式だが、 archives/ の後ろがチャンネルIDで、その後ろのpに続く数字がタイムスタンプ。しかし conversations.hisory メソッドの ts 引数に渡すときは 1000000 で割ってやる必要がある
  • permalink 内のタイムスタンプがどんぴしゃりのはずなのになぜか一個古いメッセージにヒットしてしまうことがあって、 +0.000001 秒足して回避したりした。なぜだ
  • スレッド内の返信メッセージの本文を得るのはやっかいで、まず permalink の形式が異なる https://quipper.slack.com/archives/C0TLNNUV6/p1514366729000098?thread_ts=1514280850.000103&cid=C0TLNNUV6 その上で conversations.replies メソッドを使う必要があるし、 permalink 内に二つあるタイムスタンプも正しく使い分けないといけない。詳しくは https://github.com/kyanny/slack-app-expanded-reminders/blob/master/app.rb#L21-L25 参照
  • Slack API は本家ドキュメントがしっかりしているけど英語しかないし、挙動がいまいちよくわからないことがある。ぐぐっても込み入った情報はあんまり多くないので、トライアンドエラーでがんばるしかない

「VP of Engineering Meetup by CA #2」に参加した

社内でも話題に挙がっているし、登壇者の方々と以前お話する機会があり、改めて話を聞きたいと思ったので参加した。

懇親会で個別に質問した内容も含め、メモ

  • 自分たちがサバイバルフェーズにいるということを認めたくない人もいると思うが、徹底させるにはやはりある種軍隊式のトップダウンのマネジメントをするしかないのか?
    • サバイバルフェーズの場合、とにかくこれと決めてやりきる、引っ張るのが大事。1on1とか、いわゆるふつうのマネジメントはその後のフェーズで活きてくる。
  • 「メンバーが自走してくれなくて…」というのは、情報共有ができていないということ。知っている情報以上に目線は上がらない。経営情報など。
    • いまの自社に最も足りないのはこれなのでは?と思った。実際、何かにつけ「情報共有されてない、不透明だ」という声が挙がることが増えている。実はサインはとっくに出ていて、適切なアクションをとれていなかっただけなのか?
      • 一方で、シェアされてる情報に隅々まで目を通しているか?というと、そうともいえないような…そんな余裕はない、というのも一理ある、が、共有されている情報への感度は高くなく、共有されないことに対してはネガティブな反応が挙がる、という状態だとしたら、何が問題なのか…
  • エンジニアリング部門からビジネス部門などへ「要求」する前にまず自分たちが責任を果たしていなければいけない、とはいうものの、身辺を整理する余裕もない場合、どうやって負のスパイラルを断ち切ればよいか?
    • まず、本当に余裕がないのかシビアに見極めるのも大事。その上で、「我が振り直せ」も完璧である必要はなく、少しずつでいい。「ちゃんとやってくれている」と伝われば相手もわかってくれる。ギブアンドテイク。

「腹をくくる」という話があった。ここ数ヶ月、そのことについて自問し続けてきて、ようやく「やはり俺はマネジメントはするものされるもの好きではない」という本音と向き合えた。

それでもやはり受け入れるべきなのか?と、まだ不安というか未練というか、踏ん切りがつかない、「腹をくくる」ことができない感じもしていたが、腹をくくった人たちの話を聞いて、「やはり俺は彼らのように腹をくくってマネジメントにコミットすることはできそうもない」と思った。

だから俺は、うまくいくかわからないけど、「マネジメントするものされるもの好きじゃない俺自身が幸せでいられる環境」を作ることにコミットする。それを実現するために必要なあらゆることをする、そこに腹をくくる。

池上彰の宗教がわかれば世界が見える

オーディオブックを聴いた。初めて読了?したオーディオブック。FeBeを使った。

圧倒的にキリスト教が面白かった。断片的には知っていたことも、体系だって知れるとなおよくわかる。知るとなおさら、なんで世界中の人がキリスト教を信仰しているのか不思議で、興味が増す。

通勤時の徒歩移動中を中心に、本当に隙間時間で少しずつ聴いた。読書と同じで、毎日少しずつでもいいから続けると慣れてくる。読書以上に、間隔が空くと内容を忘れるような気がする。ターミナル駅で乗り換える時、電車降りる前に再生し始めると効率がいい。

あと、目が疲れてるときにもオーディオブックは良い。目だけでなく頭が疲れてるときも、悪くない。ただし再生速度を速くするとCPUを使うので、疲れてるときには向かない。1.2倍速でのんびりじっくり聴くのが自分には合っていそう。

池上彰の宗教がわかれば世界が見える (文春新書)

池上彰の宗教がわかれば世界が見える (文春新書)

FeBeのアフィリエイトというのがあるので試してみようかと思ったが、近々リニューアルに伴い廃止されるようだ。

GitHubの通知その後

ごめん。俺が間違っていた。GitHubの通知をGmailで読むのは良いアイデアではありませんでした。特にGmailのタブをPinして開きっぱなしにしている場合は。

通知が目に入ってきづらくなったおかげで、自分がいかに通知に気を取られていたか思い知った。通知センターに新着メールの通知を表示しているわけでもないのに。

GitHubのNotificationsページにユーザースタイルシートとユーザースクリプトでカスタマイズを施している。

gist.github.com

Open notification link to new tab by keyboard for GitHub

まとまった時間を通知読みにあてて、まとめて処理する感じ。通知を読む==PRをレビューしたり、イシューにコメントしたり。これらは自分の現在のメインタスクとは少し違う。メインタスクの話はSlackチャンネルでして、個人のタスク管理に使ってるTrelloボードにイシューごとのカードを作って、個人の作業メモを残したり細かい進捗管理をしている。この話は別で詳しく書きたい。

具体的な操作のスクリーンキャスト。キーストロークをディスプレイに表示するソフトがうまく動かなかったけど、jkで移動してvで個別に新しいタブで開く、Shift+vで全部新しいタブで開く。

アニメGIFを撮ったけど、ファイルサイズが大きすぎたのか、はてなブログにアップロードできなかったので、アニメGIFを再生中のブラウザをQuickTimie Playerで撮影して動画をYouTubeにアップロードするという手間のかかることをした。