komagataのブログ

KRAYの@amachinさんにこう言われたので書きます。

うまいやり方を知りたいです。 ”ペアプロは疲れるけれど、コツが分かってくると、うまいやり方をすればとても有用だと知りました。” https://t.co/Ao7lVvmD8y

— amachin (@amachin) 2015, 11月 30

実ペアプロ時間1年未満の僕がコツなんて言うのはおこがましいですが、ペアプロオンリーでやっているMediweb社さんのやり方の受け売りです。

１台のPCを共有しない

ペアプログラミングは１台のPCを使って交代しながらやるものですが、エディタの違いとか環境の違いをあわせるのはクッソストレスが溜まるのでやりません。EmacserとVimmerは一生わかりあえません。

かわりにラップトップを持ち寄って１台の外部ディスプレイを交代でつなぎます。（Thunderbolt Displayは電源も一緒になってておすすめです）

ペアの交代時にはWIPでpushしときます。

別プロジェクトの人とペアを作らない

別のプロジェクト同士でやってもあまり興味が持てないので初心者にはおすすめできない。まずは同一プロジェクトの人同士でやる。

ドライバーを長時間やらない

一定時間で交代する。１時間がおすすめ。タスク毎交代だと他人事になりやすい。

残業しない

ペアプロは疲れます。残業はもってのほか。はじめは休憩を多めにとって6時間を目標にやるとよい。

昼を食べ過ぎない

ナビゲーターが眠くなってしまう。

毎日ペアを変えない

前日仕掛中のタスクが気になるようだったら同じペアで続行してすっきりさせてもよい。

プログラミングに限らない

インフラやタスク整理もペアでやってよい。

まとめ

TDDが「テストファーストじゃなくてもテストは書く」というのが当たり前になったように、ペアプログラミングもコモディティ化してきたのでエクストリームじゃないやり方に一般化してくのは自然なんじゃないかと思います。

本来のエクストリームプログラミングのプラクティスとしてのペアプログラミングに対してペアプロって感じで気張らず当たり前のこととしてやっていきたい。

今年前半はMediWebさんにいって製品コードは全てペアプロで書くという環境でやっていました。

ペアプロは疲れるけれど、コツが分かってくると、うまいやり方をすればとても有用だと知りました。

今年後半はAQさんとリモートオンリーで仕事をしました。

リモートの快適さに酔いしれました。

今やっているプロジェクトではペアプロやったりリモートで画面共有したりしてます。

ペアプロはプロジェクトリーダーにこそ有用

メンバーとしての利点はいろいろ語られていますが、自分がリーダーのプロジェクトで感じたのがプロジェクトを把握するのにペアプロはとてつもなく手っ取り早いということです。

リモートワークのリーダーにとっての不安ってプロジェクトやメンバーの把握が難しい点だと思いますが、リモートペアプロならカバーできるように思います。

リモートペアプロオンリーチーム

開発の全てをリモートペアプロオンリーでやるチームを作ったらどうかなと思いました。小さい会社やフリーランスでチームを組んで、僕らはリモートペアプロオンリーでやりますよとうたう。

Android WatchのSamsung Gear Liveを買って約１年。充電ドックにハマるための突起部分が折れてしまって充電できなくなったので修理に出しました。

Android Watchを半年毎日使ってみた感想 - komagata

購入から1年と1週間ぐらい経っていたらしく、見事保証期間外。

「修理に16,000円ほどかかりますがよろしいですか？」

との電話が先ほどSumsungのサポートセンターからかかってきました。

確か22,000円ぐらいで買ったんだけどな…。

さようなら、俺のAndroid Watch生活 😢

今年後半お仕事させてもらっているAQで開催されたRide the Lightning vol.21に行ってきました。

ライド・ザ・ライトニング vol. 21 - Ride the Lightning | Doorkeeper

いつもはデザインとシステムの話半々のようなのですが、今回は機械学習特集といった感じです。（英語が20%ぐらいしか聞き取れてないので間違った理解してるかも）

Marion Bouguet: How to run data analysis when you have no idea where to start?

最初はMarionさんのData Analysisの入門的なお話。僕も開発に参加しているheyheyというSlack連動サービスのデータを元にしてデータから読み取れることを紹介してました。（heyheyはまだプライベートアルファ的な感じなので公開されたら改めて紹介したいです）

全体的に発言数は微増傾向だけど夏にプロジェクト忙しい時期があってみんなの発言が減ったとか、人によって平日発言が多い人とそうでない人がいるなど。

ツールなどの技術的な詳細は別途ちらっと資料をうつしていましたがあっちもよく見たかったですね。python系で知らないツールがいくつかありました。

Marionさん、heyheyではRailsとAngularJSのコーディングをやってたんですがAIやってた人だったとはしりませんでした 😮

Inbal Horev: Machine learning in ten minutes

二つ目はInbal Horevさんの機械学習の基本的な概念・考え方の話。きちんとやったら難しそうだなという雰囲気。応用例のBCI(Brain Computer Interface)の話が面白かったです。（脳波を読み取って機械学習でノイズを減らし、意味のあるデータを認識してノータッチで車椅子を動かす）

Shuhei Iitsuka: Machine Learning for Engaging Web Design

最後はGoogleで機械学習をやっているShuhei Iitsukaさんのお話。機械学習はアプリデベロッパーだけでなく、デザイナーやマーケッターにとっても役に立つ実例の紹介。

Webの人にとってA/Bテストが手っ取り早い実例で、自然言語解析や画像解析などに比べたら無茶苦茶パラメーターが限られてるので簡単っぽいです。

ふりかえって

GoogleからTensorFlowがオープンソースで公開されたばかりで一般プログラマーにとってもホットなジャンルですが非常に興味がわきました。

玄人Macデベロッパーである@hiroshi3110さんに聞かれました。

@komagata https://t.co/kFCyM0CALn https://t.co/oFYawZwb5V 同僚にこういうの欲しいよねという話をしようと思ったらいくつかエラーが出てるのに気がついてしまいました。

— hiroshi (@hiroshi3110) 2015, 11月 26

@hiroshi3110 活用を進めてたら結局自作のダッシュボードに移行してしまいました・・・https://t.co/gzm3sTUEzw

— Masaki Komagata (@komagata) 2015, 11月 26

@komagata なるほど、僕も片手間にこういうほしいなと思って探してもいいのがないので、 React でつくるといいかなと思って放置していたので、どういう構成になってるのかブログに書いてもらえるとうれしいです！

— hiroshi (@hiroshi3110) 2015, 11月 26

せっかくなので怖話のダッシュボードの実装についてご紹介。

ダッシュボード | 怖話（こわばな）

Team Dashboardから自作へ

以前ブログに書いたTeam Dashboardはもう使ってません。今は怖話内の１ページとして作っています。

Team Dashboardで目標数字をチームで共有する - komagata

最初は表示するだけで満足してたんですが、スクラムでスプリント毎に数値ベースの仮説検証をしはじめたら痒いところに手が届かなくなり、自前実装になりました。

ダッシュボードはフレームワークやSaaSがたくさんありますがロードアベレージや通信量などインフラ向け作られているのが多くてマッチしなかったです。

使っているツール

ただのRailsのページなのでjQueryです。チャートはChart.jsを使っています。（Highchartsを使いたかったけどオープンソースのがいいので）

今のところデータソースは下記です。

• Google Analytics API
• 怖話のDB
• 自前のGoogle検索結果収集サービス
• App Annie API

Google Analytics（以下GA）で取れないものをほかで補う形です。（Google AnalyticsとApp Annieが提携したので取れるかも？）

自前のGoogle検索結果収集サービス

他のサイトでも使いたいのでHerokuにアプリとして置いてます。その過程で下記gemを作りました。

Googleでの検索順位を取る - komagata

Herokuのアプリは上記を使ってMongoLabに1日1回保存してるだけです。JSON APIはMongoLabが提供してるので自分で書く必要なし。便利。

DistimoからApp Annieへ

アプリダウンロード数はDistimo APIを使ってましたが、App Annieへ吸収され消滅しました。

iPhone・Androidアプリのダウンロード数をTeam Dashboardで出す - komagata

アカウントとデータはサービス側で移行してくれたのですが、APIは別なのでがんばって書き換えました。（報われない系仕事）

Google Analytics最強伝説

ほとんどのイベントトラッキングはGAさえあれば可能で、性能・価格的にも最強ってわかっちゃいるけど真正面から取り組むことを避けていました。

難しいんですよね。GA。何冊書籍読んでもよくわかりませんでした。

プログラマーにおすすめなのは一度GAのAPIを使って自前でダッシュボード作ってみることです。そうするとGAの仕組みがスッキリ理解できます。

「GAサイトにある画面のどれでも自前で再現できるぞ！」

となるので、Webの数値への苦手感がなくなります。

TL;DR

HerokuでPull Request毎にステージング環境が勝手にできるようになりました。

Review Apps

Review Apps自体はHeroku Buttonから続くWebアプリデプロイの自動化の流れの成果の内の一つとです。もともとPipelinesを自分で色々やればできたろうとは思いますが、管理画面だけでPR毎の自動環境構築ができるのはクッソ便利です。

Sendagaya.rb #127で下記の発表をさせていただきました。

Sendagaya.rb #127に行ってきました - komagata

Review Appsで無限ステージング環境 // Speaker Deck

スライドみればわかりますが、githubとconnectして、環境変数・addon選んでapp.json生成して、PR作れば勝手にステージング環境ができます。PRがmergeされれば消えます。

AWS + dockerとかで作ると結構大変な環境がポンッとできるのは魅力ですが問題もあります。

Review Apps化への障壁

まずapp.jsonのpostdeployで指定する1コマンドで初期化できるようにしておく必要があります。railsだったらrake db:setup指定しろって書いてあります。

新規アプリだったらいいですが、皆さんの仕事のコード、ちゃんとseed動きますか？

また、PRの分だけ有料add-onの料金がかかってしまいます。freeプランや一番low costなプランを選べって書いてありますが、一番low costプランが$20とかだとちょっと躊躇しちゃうかも。

さらに、外部共有サービス（共有というと大体がストレージですが）を使っている場合は環境が無数にできることに対応しておく必要があります。

例えば、 Blabo!では画像をS3にアップしていて、環境毎にblabo, blabo-stagingというようにbucketを分けていましたが、環境毎にbucketを作るというような設計はうまくないのでサブディレクトリにするとか工夫が必要です。

実際僕もCDN（CloudFront）とかどうしようとか困ってますね。

12factorを徹底せよ

しかしどれもHerokuの提唱してる12factor appを徹底していれば避けられるものばかりです。12factor度が甘かった部分を反省しているところです。

Review Appsを考慮した設計を

とはいえ有料add-onとかどうにもならない部分もあります。個人的にはAWSでなくHerokuを選んだ時点でadd-on対応してないものを使わない（add-onになってれば環境毎にアカウントが勝手にできるので）。freeプランの無いadd-onは使わないというしばりで設計するのが良いのでは無いかと思います。

フィーチャーブランチの是非

基本Review Appsを絶賛していますが、そもそもフィーチャーブランチは悪手ではないのか？という問題もあります。

フィーチャブランチ

フィーチャーブランチは意味的衝突に弱いので、フィーチャートグルや抽象化ブランチを使って１つのメインブランチにコミットすべきという意見です。

この辺も議論が進むといいですね。

まとめ

Review Appsはクッソ便利。だが設計に注意が必要。

Sendagaya.rbに初めて行ってきました。

Sendagaya.rb #127 - Sendagaya.rb | Doorkeeper

僕はHerokuのReview Appsについてお話しさせていただきました。それについての詳細は別エントリーにて。

Heroku Review Appsで無限ステージング環境 - komagata

また、@cesareさんによるRailsでデータ分析するときのハマりどころの発表があり、ある程度の規模のデータ分析の大変さが面白かったです。

bricolageとRedShiftの組み合わせはこういうことが必要になった時、覚えておくととっても助かりそうです。

今回は発表２つで終わりましたが、Sendagaya.rbは普段はもうちょっともくもくタイムとかがある雰囲気でした。

大江戸ruby会議でも思いましたが、最近は知り合いとばっかり仕事してたので会ったことのないrubyistを新しく知り合うのは新鮮でいいですね。

ちなみに株式会社Blaboではrails/フロントエンドエンジニアを超募集しています。

未来のBlabo!をつくる仲間、募集します。 - 株式会社Blabo

@machida さんが三軒茶屋に引っ越して自転車通勤になったので、今まで玄関に停めていたスタイルは通用しなくなったのでMINOURAのバイクタワーを買いました。

狭いオフィスで圧迫感がありますが、パーテーションとして機能しております。

オフィスに@machida さん用のThunderbolt Displayを買い足しました。

快適！

ちなみに２台ともヤフオクで買いました。5〜6万って感じです。中古のアーロンチェアと同じぐらいですね。

なんで今頃Thunderbolt Displayなのかというと、次のモデルは4K or 5Kになって、データ帯域的にThunderbolt3対応が必要なのでそれが出て、更にMacBookも買い換える必要があるので、MacBookを買い換えてからでいいかなと思ったからです。

5KでThunderbolt3対応のUSB TypeCとかで出たら嬉しいですね。高そうだけど・・・。

大江戸ruby会議05に行ってきました。

各種発表の詳細は下記を。

もう確認した？「大江戸Ruby会議05」全公開スライドまとめ | TechStars Blog

みんな色々作ってるなー。俺もやんなきゃなぁと感じました。

最近俺は動いてるけど、ぐちゃぐちゃになってるrailsコードを「普通っぽくする」とか、作法が分からない人に「普通っぽい書き方・設計」を伝えるというようなことばかりやっていて、新しいもの作ってない。

大江戸ruby会議に行ってみたらバンバン作ってる人がいっぱいいて、俺がやってる「普通っぽくする」ってなんだそりゃって改めて思いました。

「weirdだろうがmessyだろうが、ガンガン作りたい！」

と強く思いました。

素晴らしい懇親会でじゃんけんでAsakusa.rb Tシャツいただきました。

TMIXサイコー！