_ HipChat のRubyクライアントをプロキシ経由で使えるようにした。

Atlassianが提供するコミュニケーションツールHipChatは他のプロダクト同様にAPIを提供していて、rubyのクライアントhipchat-rbがある。 ところが、こいつがプロキシをまったく考慮していないため、なかなか辛い。ということで、プロキシに対応させて、プルリクエストを送った。

fluent-plugin-hipchatというのがあるので、これと組み合わせて幸せになれそう。

参考

• HipChat
• hipchat-rb#40
• fluent-plugin-hipchat

_ GitHub実践入門に倣って実践したこと

去る7月13日に、Github実践入門 の著者である大塚さんをお招きして、pull requestを使った開発についてお話していただいた。

その時、git flow でプロジェクトのリポジトリを運用していて、リリースブランチが、デプロイが面倒だったりなんだりで、なかなか出せずに溜まりに溜まっていた。

ウェブサービスなら、github flowの方が良いし、そうあるべき。

といった話があったので、もっとシンプルに、早く出せるフローにしたいと思ったので、この時聞いた話の中でいくつか実践してみた。

フィーチャーブランチは作ったら、すぐpull requestを出す。

以前は実装完了後のレビューのために、pull requestを使っていた。 それを、まだ完了していない段階で出すようにしてみた。 やってみると、長期的な開発のものから、短期的なものまで色々あり、どれを優先的に見ればいいのかわかりづらかったので、(WIP) や(In Reviewing) とpull requestのタイトルに勝手に追加して回った*1。

これからやることについてpull requestを出しておけば、どんな変更が入る（入りそう）なのかを周知できるし、開始時点でレビューできるので設計時点で指摘できる。pull requestを出した方も、最後に差し戻しをくらうよりかは早めの方が助かるだろう。

レビューで、良いところも書く。

レビューで特に問題を見つけられない場合がある。 実装の規模が小さかったりすり、ちょっとしたタイポなんかだと、指摘事項が出づらい。 そんな時には、レビューで見つけて良かったことや、感謝の気持ちを書くようにした。

言葉で書くだけだと照れくさいので、紹介してもらったLGTMというChrome拡張や、MISAWA::MD を使って楽しい雰囲気を添えている。

ただ「ありがとう！」とか「いいね！」と言うよりも、 とするだけで、雰囲気が変わる*2のがいい。

効果として、何よりも、pull requestのコメントが活発になってきたのが大きい。 コメントのバリエーションが増えたし、ポジティブだし、面白い画像を貼っても良いということでハードルが下がったことが要因だと思う。 それによって、単にpull requestの内容についてだけでなく、コードの書き方とかフレームワークの機能の質問とか、知識共有の場にもなってきてるように感じる。

デプロイを1行のコマンドにした。

github flow とは直接関係無いが、github flowの理想的な状態には自動化されたデプロイによって早く最新の状態をリリースできることが必要不可欠と思い、まずはデプロイツールの見直しをした。

それまでは、複数の一連のコマンドを叩くとデプロイできる状態だった。 これはこれで便利だったんだけども、全体の見直しと、Capistranoのバージョンアップも兼ねて、cap production deploy 一発で出せるようにした。

気軽に各環境にデプロイできるようになったことで、UIや全体の使用感を含めたレビューもやりやすくなった。 それまでは、ソースコードレベルでのレビューになってしまうので、出してみて、「あ、これはわかりづらい…」と気づくことが多かったが、それを事前に気づけるようになった。 また、チーム内のレビューだけでなく、次期リリース予定の機能をリクエストしてくれたユーザーに試してもらったり、など聞きにいけたりと当初想定していなかった利点も出てきた。

最後に

やったことは、デプロイ以外は、特に新しいツールが必要なわけではないが、非常に効果が多きかった。

自分が最終的なリリースについて管理しているので、デプロイの安心感を感じる。 それぞれの機能をチームメンバー全員で作っているという連帯感を感じる。 ユーザーに事前に評価してもらえたり、自分たちが新しい要求に対して、特段の理由も無く対応できるという安心感を感じる。

今回やったことが、成果物の品質や性能というだけでなく、チームの自信に繋がっているように感じている。

参考

【楽天ブックスならいつでも送料無料】GitHub実践入門 ～Pull Requestによる開発の変革 [ 大塚... 価格：2,786円（税込、送料込）

_ キャリアログミートアップに行ってきた。 #careerlog

• 未来のキャリアを考えよう！オフィスを出て、先輩の話を聞きに行こう。 〜キャリアログ・ミートアップ〜 - キャリアログ | Doorkeeper

社内外でキャリアパスについて明言した勉強会に行ったことが無かったのだけれど、ちょうど自分が知っている方が登壇するということで行ってきた。 増田さんは自分よりも経歴が長く、なおかつ現場で開発を続けていらっしゃるということで、自分としては理想の将来像であるし、小芝さんは自分と年が近いこともあって、経歴は違うけれども、直近の将来のイメージとして参考になりそうだと思ったというのが、参加のきっかけだった。

増田さんの話は、21世紀の職人の話。 これからもエンジニアとしてのキャリアを進もうという人に向けて、今後のエンジニアに求められること、そもそもエンジニアとしてはどうあるべきかという話だった。20世紀の産業で求められていたのが自動化、機械化、均質化で、どのようなスキルを持ったエンジニアでも同じモノを同じように作れる仕組みであったし、それが現実にあった。けれど、21世紀になって、ソフトウェア産業では、均質化ではなく、より人間らしい開発が望まれる。人間らしいというのは、単に技術のみ追求するのではなく、人間らしい生き方を求めるために、人としての意思疎通をし、お互いに尊敬しあうことと言っていた。たしかGoogleでの働き方にも同じようなことが言われていた気がする。 また、機械的にソフトウェアが生み出されるようなだけでは、本当の価値は生まれることはなく、人だからこそ生み出せる価値があるというのは、自分も同じようなことをずっと思っていたので共感できた。最終的に、人に使ってもらうものだから、人の気持ちや感性に共感して作り込めるエンジニアが求められるのだろう。 職人気質について、単に自己満足のために技術を研鑽するのではなく、経済効率を良くするために道具や工法を改善していくというのは、自分にはあまりできてないことに思えた。特に、経済効率を良くするというのは、よく忘れがちなので、気をつけないと。

小芝さんの「やってみなはれ」の考え方は、自分から機会を作るために必要な考えに思えた。 何かお願いごとなどされた時は、

1. 失敗した時のリスクを考える。失敗しても、笑い話になるか、謝って済むか、あとで辞めれるかを考える。
2. どれか満たせるなら、「やってみなはれ」発動

という単純明快な考え方だった。しかしながら、転職においては金銭的なリスクを考慮する必要がある。例えば、最悪の場合は次の職が見つからないなどで無職状態が続くことを想定しなければならないので、その期間を凌げるのかといったことや、単純に収入が減ることだってありえる。また、過去の選択ミスで失敗したとしても、その時には戻れないし、気にしてもしょうがないので考えない。こういうマインドであれば、サンクコストに対する対策っぽくて前向きに進めそう。

別に転職することが目的というモチベーションで参加した訳ではないんですが、機会を得るにはどうするか、長期的な目線でのエンジニア像みたいなのを知れました。

ギルドワークスさん、増田さん、小芝さん、ヒューマンリソシアさん、ありがとうございましたー！

参考

• キャリアログ | ヒューマンリソシア
• Shibuya CDC |

_ デスクの上の新旧交代

誕生日プレゼントとして、KensingtonのワイヤレストラックボールとHHKB Proのキートップ墨とカラーキートップをいただいたので、早速入れ替えてみた。USBケーブルの煩わしたがなくなった。特に、キートップも、思った以上に打鍵感が変わったので驚きだった。長く使っていると表面がツルツルしてきていたことに気づいた。新品のキートップだと滑りがなく、打ち込みやすい*1。

【新品/取寄品】Kensington マウス Expert Mouse Wireless Trackball K72359JP 価格：12455円（税込、送料別) (2018/8/3時点)

キートップセット(墨)PD-KB400KTB(PFU製)

カラーキートップセットPD-KB400KT01(PFU製)