最近、表題のフレーズが頭を巡っております。
僕は最近どこにいってもそんな仕事ばかりしてる気がします。railsでできたシステムは沢山あり、技術的負債の返済は誰かがやらなければならないと思います。
しかし僕の本当の気持ちは、
「既に動いてるrailsアプリをnormalizeするより、汚くてもいいから新しい動くものを作ってケツは他人に拭かせたい。」
テキストにしてみたら思ったよりゲスなフレーズになりました・・・。
RailsでDBのデータ変更はどこに書く？ - komagataのブログ
ブクマ・閲覧が多いようなので僕の結論書いときます。
- データ変更はrakeのタスクとして書く。
- migrationには書かない。
- 初期データはseedに書く。
例えば、運営側しか触らないCategoryが増えたとしたら、seedに追記し、rakeタスクとしてcategory追加するタスクを書き、デプロイ時に実行します。このrakeタスクは一回実行するだけなのでしばらく立ったらリポジトリからも消しちゃいますね。
DBの状態が秘伝のタレ化しないようにseed整備は大事。
実データ（ほとんど本番と同じ）で開発すべきというのは別の話題。
railsらしいやり方、turbolinksともマッチするjavascriptの書き方ができるturboctrlというgemをリリースしました。
これは何？
/posts/1にアクセスしたらapp/assets/javascripts/controllers/posts_controller.js.coffeeにあるPostsControllerクラスのshowメソッドが呼ばれるというものです。
# app/assets/javascripts/controllers/posts_controller.js.coffee:
class @PostsController
show: ->
console.log "Hey!"
なぜ作ったのか
「さっさとwebアプリを書きたい。」
「RailsのRailから外れる面倒なことはしたくない。」
「Railsはjsの書き方についてRailがなさすぎる。」
「Railsっぽいままjsを書きたい」
「Sprockets捨てるとかではなく、既存の仕組みのまま行きたい」
というのがモチベーションです。
「coffeeの1ファイルに1クラスだけ書く」というルールすら共有されてないと行くプロジェクト行くプロジェクトで辛いんですよね。
class @Foosprocketsを使う以上、上記のようなクラスの書き方しますよってとこも共通認識にしたい。
ご意見、ご要望、Issue、PR歓迎です。
うまいやり方を知りたいです。 ”ペアプロは疲れるけれど、コツが分かってくると、うまいやり方をすればとても有用だと知りました。” 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を作りました。
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/フロントエンドエンジニアを超募集しています。