2014-04-06

Hubotを導入したらレビューの敷居が下がった話

dev

ウチの会社ではHipchatとGitHubを開発のコミュニケーションの中心にしている。
だんだん人も増えてくると、以前よりプルリクの数がそれだけ増えて、レビューで1日終わってしまう人がでてきた。

昔から仕様を知っている人にレビューが投げられがちで集中しやすいとかは他の会社でもよくある話しだと思う。
レビューは自分のタスクと同様に大事だけど、それで自分のタスクが全くできなくなったり、新しく入ってきた人がレビューする機会を失うのはあまりよくない。

というのもあって、Hubotを立ててみてプルリクのレビュアーをランダムで振れるようにしてみた。
Hubotというのはご存知Hipchatのbotとして動くプログラムで、botにコマンドを指定してリモート実行させたり、特定の文字列に反応させたりということがHipchat上でできる。
CoffeeScriptでスクリプト書けるのでとてもお手軽。

sushiという名前のHubotを立てて、GitHubのプルリクのURLをbotに投げるとランダムでレビューお願いします！とメンションを飛ばすようにしてみた。

xxx   | @sushi https://github.com/AAA/BBB/pull/999
sushi | @yyy オナシャス！ https://github.com/AAA/BBB/pull/999

GitHubから流れてくるログから自動でメンションを飛ばさないのは、大きな機能追加などは特定の人にレビューしてもらいたいことがあるので、そこは自分で打つ。assignまで自動でできる美しいんだけどそこまではまだ出来てない。
誰にレビューしてもらおうかなと考える必要もないし、レビューの偏りも結構解消されていい感じになった。
スタートアップはどんどん人が増えるので、新しく入った人にもレビューが振られることで早くプロジェクトになじめるとかそういうのは大きいと思う。

何より、みんなが楽しんでレビューを振れるようになったのがよかった。
pushされたブランチを見て、「俺に来るな、来るなよー・・来たーマジかorz・・」とか振られる側もドキドキできて楽しい。

ランダムレビュー以外にも、みんなの名前打ったりするとその人のおもしろ発言が流れたり楽しい感じになってる。

これまで自分のローカルで動かしてたのでw ちょっと旅行に行ったときは動いてなくて寂しかったと言ってもらえたのは嬉しかった。
普段の開発フローに定着できたので、ちゃんと運用していこうと思う。

方針を決めて守ったり対面のミーティングでなんとかしていけることもあるけど、動く仕組みを作ることで一段上の解決ができることもあるよなーと1つ勉強になりました。

2014-02-23

WEB+DB PRESS Vol.79にAngularJSの記事を書きました

javascript angularjs

2/22発売のWEB+DB PRESS Vol.79のJavaScript連載で「AngularJS」をテーマに記事を書きました。

こんな感じのことを書いてます。

AngularJSについて
AngularJSの主な機能
- 2wayバインディング
- スコープ
- モジュール
- コントローラ
- Dependency Injection (DI)
- サービス
- ディレクティブ
AngularJSアプリケーションのファイル構成

AngularJSを使って本格的にアプリケーションを作っていくのに最低限必要な要素について解説しています。
AngularJS触ってみようかなーとか、とりあえずHelloWorldしてみたけどどういう機能があるのかいまいち分からないなー。
といった人のお役に立てれば幸いです。

以下、短いですけど執筆後記です。

2年間続いた「JavaScript活用最前線 -大規模開発の現場から-」は今号で最終回となります。
ちょうど2年ほど前に、現場で使えるJavaScriptネタで連載を書かないかという話をいただいて、最初は僕とid:ama-chの2人で書く予定だったのですが、僕が転職することになったため、急遽同期のid:teppeisにお願いすることになったという経緯があります。
記事のやり取りをしていたサイボウズLiveを見ていて、申し訳ないなという気持ちもあったり。
そんな中、連載が2年目に入ったのと、ちょうど今の会社に転職して個人で執筆できるようになったのもあって、2年目の連載は3人でローテーションして書いてきました。
業務をこなしながら8ページ分の記事を書くのは、業務のタイミング次第では本当に大変でしたが、非常にいい経験ができたと思っています。
id:teppeis、id:ama-ch、2年間お疲れさまでした！

2014-02-01

iOSアプリの全てのビューコントローラーにGoogleAnalyticsを一括で設定する

ios

今作っているアプリで、改善のためにどれくらい画面が使われているか知りたかったので、GoogleAnalyticsを入れたときのメモ。

GoogleAnalyticsはご存知みんな知っているアクセス解析ツール。
iOS用にもSDKが公開されていて、CocoaPodsを使っていればpod installで簡単に入れられる。

pod 'GoogleAnalytics-iOS-SDK', '~> 3.0'

画面の閲覧回数を取るためには、2つやり方がある。

1つは、GAITrackedViewControllerクラスを継承したUIViewControllerを作る。
viewDidLoadなどでscreenNameに画面名をセットしておくと、viewDidAppearで自動でトラッキングリクエストが送信される。

@interface SampleViewController : GAITrackedViewController
@end

@implementation SampleViewController

- (void)viewDidLoad
{
    self.screenName = @"画面名";
}

end

もう1つは、ビューコントローラーのviewDidLoadかviewDidAppearで、GAITrackerクラスを使って画面名を送ってやるやり方。
こっちはWebブラウザ版の使い方に近い。
UITableViewControllerなどUIViewControllerのサブクラスを使っている場合は、こっちでやるしかない。

- (void)viewDidAppear
{
    [super viewDidAppear];

    id tracker = [[GAI sharedInstance] defaultTracker];
    [tracker set:kGAIScreenName value:@"画面名"];
    [tracker send:[[GAIDictionaryBuilder createAppView] build]];
}

つまり、UITableViewControllerをふんだんに使っていたり、UIViewControllerを継承したベースクラスを作っていると、1つ1つのビューに同じ処理を書かないといけない。
これは絶対入れるの忘れそうなのでなんとかしたい。。。と思って調べてみた。

Objective-CにはMethod Swizzlingという、すでに実装されているクラスのメソッドを自前のメソッドに入れ替えるやり方が用意されているらしい。
"objc/runtime.h"が提供している、method_exchangeImplementations関数を使えばクラスメソッドの入れ替えが可能になる。

これを使ってUIViewControllerのメソッドを入れ替えれば各画面ごとにアナリティクス処理を書かずに済みそう。
つまり、UIViewControllerのカテゴリ拡張を作って、viewDidAppearをGATrackerの処理を追加してものに入れ替える関数を用意する。
画面名には「NSStringFromClass([self class])」でクラス名を自動でセットしてやる。

#import <objc/runtime.h>

@implementation UIViewController (GAInject)

- (void)replacedViewDidAppear:(BOOL)animated
{
    // 元のメソッド（名前は既に置き換わっているので注意）を呼び出す
    [self replacedViewDidAppear:animated];
              
    [[GAI sharedInstance].defaultTracker set:kGAIScreenName value:NSStringFromClass([self class])];
    [[GAI sharedInstance].defaultTracker send:[[GAIDictionaryBuilder createAppView] build]];
}

+ (void)exchangeMethod
{
    [self exchangeInstanceMethodFrom:@selector(viewDidAppear:) to:@selector(replacedViewDidAppear:)];
}

/**
 メソッドの入れ替え
  */
+ (void)exchangeInstanceMethodFrom:(SEL)from to:(SEL)to
{
    Method fromMethod = class_getInstanceMethod(self, from);
    Method toMethod   = class_getInstanceMethod(self, to);
    method_exchangeImplementations(fromMethod, toMethod);
}

@end

AppDelegateでこいつを呼び出してUIViewControllerのviewDidAppear関数を入れ替える。

#import "UIViewController+GAInject.h"

@implementation SampleAppDelegate

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    // UIViewControllerのメソッド差し替え
    [UIViewController exchangeMethod];
}

@end

これで、UIViewControllerを継承しているUITableViewControllerや自作ビューコントローラーでも、自動でトラッキング処理が走るようになります。
method_exchangeimplementations、Rubyのalias_method感覚で使えるヒッジョーに面白い仕組みですが、そのクラスと子クラスすべての挙動が変わるので使いどころには要注意ですね。

2014-01-19

Macの環境構築にhomebrew-cask+Brewfile便利

dev

先週 Macbook Air を新しいマシンにリプレースした際に、環境構築どうしようかなーと思って、homebrew-caskを使ってみたらかなり捗った。

Mac上の環境構築でよく聞くのは、GitHubが公開しているBoxenだと思うけど、PuppetのDSL覚えるの面倒くさいし、パッケージ情報をメンテナンスするのも結構ヘビーだったりする。
対してhomebrew-caskは、Homebrewの仕組みを拡張して、GUIアプリも入れられるようにして、全部brewコマンドで管理できるようにしようぜという思想で作られている。

1つずつコマンド打って全部入れていってもいいんだけど、最近のHomebrewはBrewfileを使ってパッケージ管理できるので一発で入れられて便利。

# Make sure using latest Homebrew
update

# Update already-installed formula
upgrade

# Add Repository
tap phinze/homebrew-cask || true
tap homebrew/binary || true

# Packages for development
install zsh
install git
install vim

# Packages for brew-cask
install brew-cask

# .dmg from brew-cask
cask install google-chrome
cask install virtualbox
cask install vagrant

# Remove outdated versions
cleanup

こんな感じのBrewfileがあるディレクトリで、ターミナルから「brew bundle」と打つと、書いたとおりにソフトウェアがインストールされる。
アップデートも「brew update」でよしなにやってくれる。

BrewfileをGithubかなにかで管理しておけば、新しいマシンが来たときは「brew bundle」を実行するだけだし、新しく環境作り直す場合もbrewコマンドで消すかHomebrewのディレクトリをまるごと削除するだけでいいので簡単。

デフォルトの設定だとインストール先は「/opt/homebrew-cask/Caskroom」になり、「~/Applications」にシンボリックリンクを貼る模様。
これを変えたい場合は、「HOMEBREW_CASK_OPTS」という環境変数に指定すれば変更できる。
自分はhomebrew本体と同様にCaskroomを「/usr/local」下に置きたかったのと、シンボリックリンクは「/Applications」に貼りたかったので変更した。

export HOMEBREW_CASK_OPTS="--appdir=/Applications --caskroom=/usr/local/Caskroom"

ちなみに自分はAlfredをランチャーアプリとして使っていて、homebrew-caskで入れたアプリはシンボリックリンクなので検索対象になってくれなかった。
ただ、対応策としてサブコマンドがちゃんと用意されていて、そいつを実行すると検索対象に含まれるようになった。

$ brew cask alfred
$ brew cask alfred link # CaskroomをAlfredの検索パスに追加

2014-01-12

AngularJSのディレクティブの仕組みを追ってみた

javascript angularjs

追ってみたシリーズ第3回目。

AngularJSのディレクティブ、名前は聞いたことあるけどあれでしょ？自前の「ng-hoge」を作るための仕組みでしょ？
だいたいそんな感じですが、どうやって実現しているのか。

ディレクティブの役割

ディレクティブはHTMLビューを書き出すためだけのものじゃない。
「ng-controller」や「ng-model」など、HTMLに対して処理をバインド/注入する機能もディレクティブで出来ている。
AngularJSが持つ組み込みのディレクティブだけでもこれだけの数がある。

まさしくAngularJSのベースとなっている仕組みがDirectiveというわけか。

追ってみる

ベースとなるngDirective関数を見ると、"link"と"restrict"プロパティを持ったオブジェクトを返す関数を作っていることが分かる。

function ngDirective(directive) {
  if (isFunction(directive)) {
    directive = {
      link: directive
    };
  }
  directive.restrict = directive.restrict || 'AC';
  return valueFn(directive);
}

これだけじゃよく分からないので、「ng-model」ディレクティブを見てみる。

var ngModelDirective = function() {
  return {
    require: ['ngModel', '^?form'],
    controller: NgModelController,
    link: function(scope, element, attr, ctrls) {
      // notify others, especially parent forms

      var modelCtrl = ctrls[0],
          formCtrl = ctrls[1] || nullFormCtrl;

      formCtrl.$addControl(modelCtrl);

      scope.$on('$destroy', function() {
        formCtrl.$removeControl(modelCtrl);
      });
    }
  };
};

「AngularJSの2way bindingの仕組みを追ってみた」で追っていた初期化処理（bootstrap関数）でcollectDirective関数が呼ばれ、スコープが管理するHTML内で「ng-model」が定義されていると、AngularJS内で「ngModel」をキーをしてマッピングされているngModelDirectiveが実行される。
ここで返されたオブジェクトがディレクティブとなる。
compileプロパティを持たず、linkプロパティを持っている場合は、linkプロパティを返す関数がcompileプロパティとしてディレクティブにセットされる。

このとき、ディレクティブに自動でセットされるプロパティは以下のものになる。

compile（ディレクティブの実行内容）
priority（DOMに複数のディレクティブが定義されている場合の優先順位）
index（DOMに対して何番目に定義されたディレクティブか）
name（ディレクティブにつけられている名前）
require（依存関係を持つディレクティブ）
restrict（ディレクティブの適用条件。"A"なら属性名、"E"なら要素名、"AE"ならどちらにもマッチ）

そして返されたディレクティブは、要素のcompileプロセスにおいて、applyDirectivesToNode関数で要素に対して「POST LINKING」というリンク関数としてセットされる。
リンク関数には「PRE LINKING」「POST LINKING」があるが、これは子要素に対してリンク関数を実行する前に実行するか後に実行するかというフェーズがある。
「PRE LINKING」にするか「POST LINKING」にするかは、ディレクティブを定義する際のcomlileプロパティに"pre"か"post"を指定すれば選択可能。

compile: function compile(scope, element, attr) {
  return {
    pre: function preLink(scope, iElement, iAttrs, controller) { ... },
    post: function postLink(scope, iElement, iAttrs, controller) { ... }
  }
  // or
  return function postLink( ... ) { ... }
}

この後、nodeLinkFnというクロージャ関数でリンク関数としてディレクティブのcompileに指定した処理がようやく実行される。このとき、ディレクティブにcontrollerプロパティが指定されていれば、コントローラーがインスタンス化され、自分が所属するスコープ内の検索対象として使われる（requireで"^"がついていない場合）。
見つかったコントローラーは、コンパイル時の指定関数の第4引数に配列でセットされ渡される。

ディレクティブでできること

自分が定義した要素名が使えるようになり、その要素に対する初期処理をAngularJS内のフェーズごとに書ける
既存の要素に対し、初期処理をAngularJS内のフェーズごとに書ける
特定の要素、属性を持つスコープやコントローラーに対し、処理を外側から追加することができる

このスコープやコントローラーに処理を追加できるのがキモだと思われます。
独自にAngularJSに機能を追加するプラグインやライブラリを書く場合、「PRE LINKING」で所属するスコープに関数を生やしたり、コントローラーに新たに処理をバインドしたりといったことはディレクティブを使うとよさそうです。

今回はディレクティブの外部テンプレート機能については触れていないので、それはまた次に調べる。

yo_waka's blog

418 I'm a teapot