valid,invalid

関心を持てる事柄について

"kill N + 1 queries" Tシャツ作った

絶対に殺すという強く熱い"想い"を"カタチ"に。

仕上がり予想図

f:id:ohbarye:20170910153032p:plain

ロゴ

白黒両方作って試してみた。

f:id:ohbarye:20170910153028p:plain

反転していると見づらい。

f:id:ohbarye:20170910153035p:plain


加工代や送料込みで4,000円弱かかった。前は2,000円ぐらいで作れた気がしたのだが気のせいか?

(追記) 9/16に届いた。

automaildoc gem でメール一覧と文面を自動生成する

RSpec からメール一覧を自動生成する gem を書いてみた。

github.com

使い方

gem を install したのちコマンドラインから AUTOMAILDOC=1 rspec を走らせるとメールを一覧表示するHTMLを生成する。

https://user-images.githubusercontent.com/1811616/29994112-c6dacbc6-9002-11e7-812f-a346d415d6c4.gif

名前も設計もほとんど autodoc を参考にしている。

背景・課題

「法務・ブランドチェックが入るのでメールを確認したい」

「新たに送信するメールの文面考えるので類似メールの文面見られますか?」

「この前もらったメール文面のプレミアムユーザー版だとどうなりますか?」

プロダクトマネージャーやビジネスサイド、カスタマーサポートなどのステークホルダーからのこうした問合せには、開発者がコードや I18n の翻訳ファイルを見たりしつつ都度回答してきた。

しかしA/BテストやCS要望のために少なくない頻度で内容がアップデートされたり、日々の開発で気づかないうちにメールが増えたり減ったりするし、同じメールでもコンテキストに応じて変わる内容を追従できていなかったりと諸々問題がありそうだった。

この課題に対する解決策として同僚の yuya-takeyama さんが autodoc みたいに RSpec から自動生成したら便利なのではというアイディアを出し、tanaka51 さんが 20 percent policy 的な時間でプロトタイプを作ってくれていた。7月に tanaka51 さんが退職されて以降この課題が放置されていたのだが再度「メール一覧見たい」という要望を受けた際にこれを思い出してガッと gem 化してみた。

HTMLメールがきちんと表示されない問題があるが近日中に直す。version 0.1.3 で表示されるようにした。

現状

会社のレポジトリに automaildoc を突っ込んで「こんなのできますがどうですかね」と [RFC] ラベル付き pull request を投げてみたところ「やってみましょう」と即マージされた。ありがたい。

課題

生成されたHTMLをどう共有するか

秘匿性の高いものはまた別のやり方が必要だが、/doc/mails/toc.htmlGitHub pages で公開するのが最も簡単そう。

定期的に更新する仕組み

全部コマンドラインで完結するので Jenkins などで定期的に生成して pull request を自動で push すると良さそう。

個々の開発をフックにするなら Git hook が使えそう。pre-commit hook で変更されたファイルをチェックし、 mail spec や翻訳ファイルに変更があれば rspec を走らせてドキュメントを自動生成する…と書いていて思ったが結構面倒くさそう。

mail ごとの rspec を書かないといけない

ツールに合わせた開発はしたくない。が、request spec と違って mail spec 自体に込み入ったロジックや fixture を用意するケースはほとんどなく、もともとさらっと書いてあれば導入の費用対効果は悪く無さそう。

感想

運用やめたら「automaildoc やめた」という記事を書きます。

Gem の install / uninstall フックの使い方

Git hook を手軽に管理できる huskyRuby 版が欲しいかもと思い最近 rusky という gem を作っている。

github.com

gem install 時に Git hook スクリプトを自動生成し、uninstall 時には勝手に消してくれる感じにしたい。そんなわけで gem のインストールフックの使い方を学んだ。

知ったこと

走らせたいフックを rubygems_plugin.rb というファイルに定義する。rubygems_plugin の話は Plugins - RubyGems Guides あたりに書いてある。

# lib/rubygems_plugin.rb
require 'rubygems'

Gem.post_install do |installer|
  # whatever you want
end

Gem.pre_install do |uninstaller|
  # whatever you want
end

使えるフックは module Gem - Documentation for Ruby 2.4.0 あたりを参考にする。

これらのフックを gem_name.gemspec ファイルに書いても動くようだが、一部環境では動かないようだ。

ハマっていた問題

こんな Gemfile を書いて色々テストしていた。

# test-repo/Gemfile
source 'https://rubygems.org'

# it doesn't work
gem 'rusky'

# it works
# gem 'rusky', path: '/Users/ohbarye/.ghq/github.com/ohbarye/rusky'

# it works
# gem 'rusky', github: 'ohbarye/rusky'

同僚の松島さんに使用例を教えてもらった

見比べて何が足りないかと思えば rubygems_plugin.rb 内で require 'rubygems' していなかったのが原因らしかった。足して見たところうまく動いた。とはいえ、うーん、require しないとこのへんで定義してるメソッドが読まれない?Gem class のこととかよくわかっていない。また、なぜ path や github オプションの指定ではうまく動くのかもわかっていないので時間あるときにコードを追いたい。

現状

手元のテスト用レポジトリでは上記のどの Gemfile の書き方でもうまく動いているようだ。

8月はOSS活動をそれなりに頑張った

過去に作った kpt-bot を omoiyari.fm で紹介いただいたのをきっかけにモチベーションが上がり、8月はOSS活動を普段より頑張ってみることにした。

lean-agile.fm

目標

  • 週1で何らかの OSS プロダクトに Pull Request を投げる
  • 20 stars ぐらい集めるような"何か"を作る
  • 毎日コードを書く

進捗

Pull Requests

8月に出した Pull Requestsは8本で、数で言えば達成できたが内容はドキュメント更新ばかりでやや物足りない。普段から息を吸うように活動してる人はやはり尊敬する…。

作ったもの

github.com

ohbarye.hatenablog.jp

20 stars 届かず無念。とはいえ仕事でも役に立つものが出来てよかった。

毎日コードを書く

Write Code Every Day... とは違うルールだけどアクティビティ上は達成できたようだ。

その他

8月中に完成しなかったけどもちょっとした gem を作ってみたり。

感想

ちょっとした修正は GitHub の Web UI 上で完結するので便利だなァと今更思うなどした。

コントリビュートできないかと粗探しをした結果、副次的にライブラリのコードをよく読むようになった。

オープンソースの粗探し(?)に慣れると業務で触るコードも粗だらけに見えてきて最近は前よりボーイスカウト的な行動もするようになった…かもしれない。

最近の英語学習と、コミュニケーションについて思ったこと

会社では以前より遥かに使う機会が増えており、プレッシャーを感じる…。

リーディング / ライティング

以前は突然 Slack でダイレクトメッセージが来ると心臓が高なったりしたが、最近は流石に即興対応できるようになってきた。

GitHub issues でのやりとりはだいぶ前に慣れたが相変わらず語彙が少ない(Grammarly を有料契約しているので英作文の傾向や語彙数が週次で定量的に把握できる)。ネイティブの同僚のコメントなどから諸々の表現を盗みつつ改善していきたい。

知っているとちょっとかっこいい小手先のテクニックみたいなのは全然学んでいないし使っていない。

リスニング

相変わらず自信が持てないので、重要な 1 on 1 の会話をするときはこんな感じでしのいでいる。

  • 初めにゆっくり話すよう頼む
  • 何回も聞き返す
  • 相手の言葉をそのまま言い返して合っているか確認する

ランチのようなランダムチャットは何が飛んで来るかわからないぶん仕事よりも難易度が高いのだが、自分から話題を振ることでいきなりコンテキストを掴むというスキルを手に入れた。

スピーキング

発音はアメリカ英語に近づけるよう努力している。これはかっこ良さとかでなく聞き手に楽をさせるためだ。

てきとうな例だけど sea と she の発音はアメリカ英語では明らかに違う([s][ʃ])のに sea をカタカナで「シー」と発音すると、聞き手の英語話者は「どっちのことを言っているんだろう」と思う。カタカナの「シ」だと [ʃ] に近いから she だと思うかもしれないし、相手は日本人だからこの音を区別できていないのだろうと思うかもしれない。

いずれにせよ聞き手に負担をかけたまま放置するのはコミュニケーションの悪手だと自分は考えている。伝わればいいとか何も言わないよりとにかく話すのが大事と言ってカタカナ英語を推す言説も聞くが、これはやりたくない。(無論「正しい英語」なんてものは存在しないので自分がどういう英語コミュニケーションをしたいか、というだけの話)

完璧は目指していないのでそんなに力を入れて練習してはいないが、単語の意味を調べる時についでに発音記号を見るとか、基本の発音をすべて知っておくぐらいのことはしている。基本の発音の練習はもっと必要。

この辺の考え方や練習の仕方は英語耳にだいぶ影響を受けた。

amzn.to

レビュー待ちの Pull Request 一覧を Slack に定期的に通知する

review 待ちの Pull Request 一覧を Slack に定期的に通知する仕組みを作ってみた。

完成品

以下の画像は朝11時 JST に自分のチームのレビュー待ちリストを表示している様。Slack の絵文字で「いまレビューしてますよ〜」「merged!」みたいな表現をするのはエンジニアしぐさだ。

f:id:ohbarye:20170826221056p:plain

private repo だと味気ない(かつ業務情報なのでモザイクだらけだ)が、public repo の PR だと Slack が自動的に展開してくれるのでよりファビュラスに見える。

2017-08-11 11 15 31

仕組み

3行で書くと…

  • review-waiting-list-bot という Slack bot が Heroku にデプロイされている*1
  • メンションされると GitHub API を叩いてプルリクエストを収集し、まとめて Slack に post する
  • 定期的に実行する仕組みは Slack のリマインダーを使う

review-waiting-list-bot

github.com

Node.js 製の Slack botフレームワークには前回作った KPT-bot 同様、 Botkit を使っている。

async / await を試してみたかったので Node version 8 にした。残念ながら Botkit が Promise に対応しておらずコールバックを色々書くハメになる*2のだが、GitHubAPI をコールするところはうまくまとめられる。

bot をコールする際に author, owner, repo を指定することができる。-repo のような表記で除外条件(exclusive)を指定することもできる。詳細は README#Usage を参照。

Slack Reminder

bot 側で定期的に post する仕組みも作れるのだがやらなかった。設定を持たないといけなくなる=ステートレスでなくなるし、Slack に慣れているチームなら reminder 機能を充分に使いこなしてくれるからだ。

ちなみに、毎朝11時にリマインドする場合は以下のようなコマンドになる。タイムゾーンはリマインダ作成者の設定に依存するようなので注意。

/remind #channel-name "@review-bot ls author:org/my-team owner:org -repo:design" every weekday at 11am

詳細は Set a reminder – Slack Help Center 参照。

反応

開発者間のミーティングで紹介↓した後、

f:id:ohbarye:20170826225525p:plain

社内の幾つかのチームで使ってくれているようだ。Slack で定期的に呼んでいるチームもあれば daily meeting の最後に手動で呼び出して情報を同期しているチームもある。

フィリピンの同僚から Pull Request を貰ったり、チームでなく個人の活動を拾い上げたりもした。

f:id:ohbarye:20170826224603p:plain

所感

開発者だけでなく Product Manager にも喜ばれたのが意外だった。開発の進捗を把握する一助になるとか。

なんにせよ思ったより使われて良かった*3というのと、社内にユーザーがいるとフィードバックがすぐに貰えてドーパミンが出ますね。

*1:free dyno でも worker プロセスが眠らずに働いているのでいつでもメンションに反応する

*2:https://github.com/howdyai/botkit/pull/278 で試みられたがずっと放置された末に author の心が折れたようだ

*3:前作の KPT-bot が思ったほど奮わなかったのでひとしお

Rails の form 内で disabled された submit ボタンを再度 enable する

form を submit する時に disabled されるボタンを re-enable するには $.rails.enableFormElements($form) を使う。

二重サブミット防止

まず、data 属性に disable_with を設定するとクリック時にボタンが disabled になり、二重 submit 防止になる。ラベルも disabled_with で指定したメッセージに置き換わる。

<%= form_for @user do |f| %>
  <%= f.submit 'Submit', data: { disable_with: 'Submitting...' } %>
<% end %>

re-enable

submit 後に画面ごとリロードするような処理ならよいのだが、submit イベントをオリジナルの処理でハンドリングしたときは disabled されたボタンを自前で元に戻してやらないといけない。

$.rails.enableFormElements($form) がそれをやってくれる。

$form = $($.rails.formSubmitSelector)

$form.on 'submit', (e) =>
  e.preventDefault()

  $.post(url, data)
    .done(navigateToNextPage)
    .fail (xhr) =>
      showAlert(xhr)
      $.rails.enableFormElements($form)